From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 1 04:21:54 2004 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 EAA07847 for ; Mon, 1 Nov 2004 04:21:54 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00ECA3A9@cherry.ease.lsoft.com>; Mon, 1 Nov 2004 4:21:53 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 42701287 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 1 Nov 2004 04:21:52 -0500 Received: from 209.119.0.34 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 1 Nov 2004 04:21:52 -0400 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <6.0050FD9E@grape.ease.lsoft.com>; Mon, 1 Nov 2004 4:21:52 -0500 Message-ID: Date: Mon, 1 Nov 2004 04:21:51 -0500 Reply-To: Mailing List Sender: Mailing List From: SUBSCRIBE OSPF vishnuvardhan B Subject: Re: Reg OSPF SPF To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi, I have the following scenario where two different routers are makeing two different SPF decisions about the same inter-area route. A-----La-------ABR1---Lx---ABR2 |\<-L2 /|<-L-3 | \ / | (Costed out)L1->| \ / | | \ / | | \/ | | /\ | | / \ | | / \ | | /<-L4 \ | NBR-1 NBR-2 In the above diagram, the links between A and ABR1 and ABR2 (La and Lx) are in area 0.0.0.0 and all of the other four links (L1, L2, L3, L4) are in area 0.0.0.6. The cost of all of the non-backbone links are the same say (C). In router A, the path to NBR-1's (non backbone router) loopback address is being calculated to go through ABR1 (area border router) traversing link L1 (A->La->ABR1->L1). When L-1 is costed out A seems to be calculating the path to NBR-1 via ABR2 (A->La-ABR1->Lx->ABR2->L4). But. In ABR1, the path to NBR-1 under this L1 costed out scenario is being calculated via NBR-2 (ABR1->L2->NBR-2->L3->ABR2->L4->NBR-1). Now, clearly either A or ABR1 is calculating the path wrong under this costed out scenario. From what I understand, it is A who is calculating it wrong. When A reaches the nearest ABR for the desired area (which is ABR1), A shouldn't traverse any more backbone links (Lx) for that route. A should hand it to the nearest ABR for the desired area. ABR1 seems to be doing the right thing by immediately exiting the backbone even when it has a lower cost path via ABR2 but that would require traversing a backbone link. From a network management perspective, the cost to the loopback address of NBR1 is shown on A to be say C1 (La+Lx+L4). But, when A forwards traffic destined for NBR1 to ABR1, the traffic actually is incurring a cost of C2 (La+L2+L3+L4). And that'a all I have to say about that! Thanks in advance!!!! From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 1 07:08:59 2004 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 HAA22209 for ; Mon, 1 Nov 2004 07:08:59 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00ECA95F@cherry.ease.lsoft.com>; Mon, 1 Nov 2004 7:08:59 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 42777898 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 1 Nov 2004 07:08:58 -0500 Received: from 158.130.70.79 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 1 Nov 2004 07:08:58 -0400 Received: from ee.upenn.edu (M367PC1.CIS.upenn.edu [158.130.12.199]) (authenticated bits=0) by stag.seas.upenn.edu (8.12.10/8.12.10) with ESMTP id iA1C8vWx016480 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 1 Nov 2004 07:08:57 -0500 User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) 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 Message-ID: <41862716.2030103@ee.upenn.edu> Date: Mon, 1 Nov 2004 07:07:50 -0500 Reply-To: Mailing List Sender: Mailing List From: Roch Guerin Subject: Re: Reg OSPF SPF To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit I don't think that either router A or ABR1 is doing anything wrong. They are both operating according to the information available to them and that they are entitled to use according to the OSPF specs. Router A hears T3summary from both ABR1 and ABR2 regarding NBR-1 and given the lower (total) cost associated with ABR2, selects it as the desired exit point from area 0.0.0.0 with ABR1 as the nexthop. Now when packets reach ABR1, they are indeed being hijacked from the path originally intended by router A and instead of being sent to ABR2 are sent to NBR-2 (that will then send them to ABR2, which will ultimately forward them to NBR-1). This hijacking is perfectly "legal" as ABR1 gives precedence to intra-area routes (through NBR-2) over inter-area routes (through ABR2). There are many cases where this kind of hijacking takes place, either because of differences between information available at different routers, e.g., through summarization, or simply because of the fact that the routing table computation is not purely cost based. Regards, Roch >Hi, > I have the following scenario where two different routers are makeing two >different SPF decisions about the same inter-area route. > > > A-----La-------ABR1---Lx---ABR2 > |\<-L2 /|<-L-3 > | \ / | > (Costed out)L1->| \ / | > | \ / | > | \/ | > | /\ | > | / \ | > | / \ | > | /<-L4 \ | > NBR-1 NBR-2 > >In the above diagram, the links between A and ABR1 and ABR2 (La and Lx) >are in area 0.0.0.0 and all of the other four links (L1, L2, L3, L4) >are in area 0.0.0.6. The cost of all of the non-backbone links are the >same say (C). > >In router A, the path to NBR-1's (non backbone router) loopback address >is being calculated to go through ABR1 (area border router) traversing >link L1 (A->La->ABR1->L1). When L-1 is costed out A seems to be >calculating the path to NBR-1 via ABR2 (A->La-ABR1->Lx->ABR2->L4). >But. In ABR1, the path to NBR-1 under this L1 costed out scenario is >being calculated via NBR-2 (ABR1->L2->NBR-2->L3->ABR2->L4->NBR-1). > >Now, clearly either A or ABR1 is calculating the path wrong under this >costed out scenario. From what I understand, it is A who is >calculating it wrong. When A reaches the nearest ABR for the desired >area (which is ABR1), A shouldn't traverse any more backbone links (Lx) >for that route. A should hand it to the nearest ABR for the desired >area. ABR1 seems to be doing the right thing by immediately exiting >the backbone even when it has a lower cost path via ABR2 but that would >require traversing a backbone link. > >>From a network management perspective, the cost to the loopback address >of NBR1 is shown on A to be say C1 (La+Lx+L4). But, when A forwards >traffic destined for NBR1 to ABR1, the traffic actually is incurring a >cost of C2 (La+L2+L3+L4). > >And that'a all I have to say about that! > >Thanks in advance!!!! > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 1 09:53:57 2004 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 JAA10199 for ; Mon, 1 Nov 2004 09:53:57 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00ECAB9F@cherry.ease.lsoft.com>; Mon, 1 Nov 2004 9:53:56 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 42801756 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 1 Nov 2004 09:53:55 -0500 Received: from 147.234.1.11 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 1 Nov 2004 09:53:54 -0400 X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 X-MIMETrack: Serialize by Router on ILSMTP01/ECI Telecom(Release 6.5.1|January 21, 2004) at 11/01/2004 16:57:47 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Message-ID: Date: Mon, 1 Nov 2004 16:53:57 +0200 Reply-To: Mailing List Sender: Mailing List From: Ilan Bercovich Subject: Redistribute Static routes To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hello Is "Redistribute Static routes" equivalent to configuring the router as ASBR? Is there a way to configure type-1 metric and type-2 metric by standard MIBs? Is there a way to select if type-2 or type-2 is used by standard MIBs? Thanks, Ilan From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 1 13:25:50 2004 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 NAA15042 for ; Mon, 1 Nov 2004 13:25:50 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00ECAEF9@cherry.ease.lsoft.com>; Mon, 1 Nov 2004 13:25:50 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 42834510 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 1 Nov 2004 13:25:50 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 1 Nov 2004 13:25:49 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id EEA7D50E048 for ; Mon, 1 Nov 2004 10:25:48 -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 09171-10 for ; Mon, 1 Nov 2004 10:25:48 -0800 (PST) Received: from aceeinspiron (unknown [172.31.253.19]) by prattle.redback.com (Postfix) with SMTP id 3BF5E50E04A for ; Mon, 1 Nov 2004 10:25:48 -0800 (PST) References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <010f01c4c040$3592f580$0202a8c0@aceeinspiron> Date: Mon, 1 Nov 2004 13:25:46 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Redistribute Static routes To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Ilan, ----- Original Message ----- From: "Ilan Bercovich" To: Sent: Monday, November 01, 2004 9:53 AM Subject: Redistribute Static routes > Hello > > Is "Redistribute Static routes" equivalent to configuring the router as > ASBR? It depends on the implementation. One could use any redistribution to determine whether the router advertises itself as ASBR (as per the E-bit in the router LSA) or one could only advertise oneself as an ASBR if there are actually active redistributed routes to advertise. > > Is there a way to configure type-1 metric and type-2 metric by standard > MIBs? > > Is there a way to select if type-2 or type-2 is used by standard MIBs? No. However, for stub areas one can configure the type of the ABR generated default route via the OSPF MIB (ospfStubMetric). > > Thanks, > Ilan From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 1 16:33:44 2004 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 QAA06279 for ; Mon, 1 Nov 2004 16:33:44 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00ECB349@cherry.ease.lsoft.com>; Mon, 1 Nov 2004 16:33:43 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 42852793 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 1 Nov 2004 16:33:41 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 1 Nov 2004 16:23:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05355; Mon, 1 Nov 2004 16:23:40 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200411012123.QAA05355@ietf.org> Date: Mon, 1 Nov 2004 16:23:39 -0500 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-af-alt-01.txt Comments: To: i-d-announce@ietf.org 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 : Support of address families in OSPFv3 Author(s) : S. Mirtorabi, et al. Filename : draft-ietf-ospf-af-alt-01.txt Pages : 8 Date : 2004-11-1 This document describes a mechanism for supporting multiple address families in OSPFv3 using multiple instances. It maps an address family (AF) to an OSPFv3 instance using the Instance ID field in the OSPFv3 packet header. This approach is fairly simple and minimizes extensions to OSPFv3 for supporting multiple AF's. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-af-alt-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-af-alt-01.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-af-alt-01.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: <2004-11-1165456.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-af-alt-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-af-alt-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-1165456.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 1 22:22:54 2004 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 WAA19521 for ; Mon, 1 Nov 2004 22:22:53 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00ECB6EE@cherry.ease.lsoft.com>; Mon, 1 Nov 2004 22:22:52 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 42881956 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 1 Nov 2004 22:22:51 -0500 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 1 Nov 2004 22:22:50 -0400 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01LGQEAX3C0W000OF8@omega7.wr.usgs.gov> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 01 Nov 2004 20:24:19 -0700 (PDT) X-VMS-To: OSPF@PEACH.EASE.LSOFT.COM X-VMS-Cc: pmurphy MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01LGQEAX3CYQ000OF8@omega7.wr.usgs.gov> Date: Mon, 1 Nov 2004 20:24:19 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: NSSA question To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Acee, >I think the assumption from RFC 3101 doesn't take this case into >account. Since a Type-7 LSA only has area-wide flooding scope, when its forwarding address is set to 0.0.0.0, its ASBR's routing table entry must be chosen from the originating NSSA. Here no pruning is necessary since this entry always contains non- backbone intra-area paths. You are correct. This ABR case was not envisioned. Unfortunately just because an ABR receives an external LSA for a prefix from an ASBR, does not mean that the same ASBR originated a T5 or T7 into each of the ABR's directly connected areas (NSSA or non-NSSA). Below is a revision of the pruning process of RFC 3101 Section 2.5 Step (3). Should a correction be made or should we just leave the spec as is and let individual implementations handle it? Keep in mind this might result in more NSSA paradoxial behavior, ala RFC 3101 Appendix E. However it should restore the proper forwarding behaviour of OSPF Section 16.4.1. Pat ********* Possible correction****************** If the forwarding address is set to 0.0.0.0 then packets should be sent to the ASBR itself. However if the ASBR did not originate into an NSSA a Type-7 LSA for the current LSA's prefix, then any path to the ASBR through that NSSA is not used. Furthermore if the ASBR did not originate a Type-5 LSA for the current LSA's prefix, then any paths to it across non-NSSA areas are not used. From among the remaining multiple routing table entries for the ASBR (both NSSA and non-NSSA ASBR entries might still exist), select the preferred entry as follows: [NSSA] If RFC1583Compatibility is set to "disabled", prune the set of routing table entries for the ASBR as described in OSPF Section 16.4.1. 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. [OSPF] If the current LSA is Type-7, and its forwarding address is set to [0.0.0.0], plus its OSPF Area ID was not chosen during the above pruning process, then do nothing with this LSA and consider the next in the list. [NSSA] ************ RFC 3101 text ******************* If the forwarding address is set to 0.0.0.0 then packets should be sent to the ASBR itself. If the LSA is Type-5, from among the multiple non-NSSA routing table entries for the ASBR (both NSSA and non-NSSA ASBR entries might exists on an NSSA border router), select the preferred entry as follows: ~[OSPF] If RFC1583Compatibility is set to "disabled", prune the set of routing table entries for the ASBR as described in OSPF Section 16.4.1. 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. [OSPF] Since a Type-7 LSA only has area-wide flooding scope, when its forwarding address is set to 0.0.0.0, its ASBR's routing table entry must be chosen from the originating NSSA. Here no pruning is necessary since this entry always contains non- backbone intra-area paths. [NSSA] From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 2 01:56:20 2004 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 BAA04328 for ; Tue, 2 Nov 2004 01:56:20 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00ECBD67@cherry.ease.lsoft.com>; Tue, 2 Nov 2004 1:56:19 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 42903326 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 2 Nov 2004 01:56:17 -0500 Received: from 147.234.1.11 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 2 Nov 2004 01:56:17 -0400 X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 X-MIMETrack: Serialize by Router on ILSMTP01/ECI Telecom(Release 6.5.1|January 21, 2004) at 11/02/2004 09:00:10 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Message-ID: Date: Tue, 2 Nov 2004 08:56:20 +0200 Reply-To: Mailing List Sender: Mailing List From: Ilan Bercovich Subject: Re: Redistribute Static routes To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Thanks for your reply, Acee But I still don't get it: 1) Can a router redistribute static routes without being ASBR? Or is once a router redistributes static routes it had already actualy became an ASBR? 2) How can one select if a static route would be considered as type-1 or as type-2? Thanks, Ilan Acee Lindem cc: Sent by: Mailing Subject: Re: Redistribute Static routes List 01/11/2004 20:25 Please respond to Mailing List Hi Ilan, ----- Original Message ----- From: "Ilan Bercovich" To: Sent: Monday, November 01, 2004 9:53 AM Subject: Redistribute Static routes > Hello > > Is "Redistribute Static routes" equivalent to configuring the router as > ASBR? It depends on the implementation. One could use any redistribution to determine whether the router advertises itself as ASBR (as per the E-bit in the router LSA) or one could only advertise oneself as an ASBR if there are actually active redistributed routes to advertise. > > Is there a way to configure type-1 metric and type-2 metric by standard > MIBs? > > Is there a way to select if type-2 or type-2 is used by standard MIBs? No. However, for stub areas one can configure the type of the ABR generated default route via the OSPF MIB (ospfStubMetric). > > Thanks, > Ilan From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 2 06:24:49 2004 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 GAA08248 for ; Tue, 2 Nov 2004 06:24:48 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00ECC3CE@cherry.ease.lsoft.com>; Tue, 2 Nov 2004 6:24:45 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 42951791 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 2 Nov 2004 06:24:39 -0500 Received: from 202.43.216.207 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 2 Nov 2004 06:24:37 -0400 Received: from [202.96.96.35] by web15404.mail.cnb.yahoo.com via HTTP; Tue, 02 Nov 2004 19:24:34 CST MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Message-ID: <20041102112434.65376.qmail@web15404.mail.cnb.yahoo.com> Date: Tue, 2 Nov 2004 19:24:34 +0800 Reply-To: Mailing List Sender: Mailing List From: Jing Shen Subject: Re: What will happen in this kind of topology with 100 nbrs and 2000 ASEs ?? To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <7549C475A1F3CF47ABCA660BF44738B36F5A50@legolas.rs.riverstonenet.com> Precedence: list Content-Transfer-Encoding: 8bit Do you means this could be dealt by increasing CPU ability of router ? If it is, I come to see why Alcaltel use MIPS CPU with 2GB memory in it router. Jing --- "Mollin, Arvind - LiqwidKrystal" µÄÕýÎÄ£º > Thanks for one n all. > Well this case is something related to congestion as > Vishwas have > pointed out. Suppose R1 sends a update, ( that is > each neighbor will > send an update 100 updates altogether) then R2 would > send back 99*100 > updates to R1, thus R1 is busy in processing them > and doesn't send > hello's or doesn't process hellos, also sometimes > the buffer overflows. > These are the reason why ospf flaps. So in this kind > of topology the > processing will hog the CPU. > Well, I have read that some implementations can > handle upto 750 > neighbors. !! provided congestions are avoided. > > --Arvind > > -----Original Message----- > From: Mailing List > [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Dave > Katz > Sent: Monday, October 25, 2004 11:52 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: What will happen in this kind of > topology with 100 nbrs and > 2000 ASEs ?? > > This kind of behavior is related to the quality of > the implementation. > Some implementations can handle 100 neighbors with > aplomb. There's no > reason this shouldn't be stable, particularly with > the large default > timer values. > > But my rants on this subject are well known... > > > On Oct 24, 2004, at 11:40 PM, Vishwas Manral wrote: > > > Hi Arvind, > > > > Instead of increasing the "Router Dead Interval", > you could instead > use > > techniques as given in > > > http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-08.txt > > > > Thanks, > > Vishwas > > > > -----Original Message----- > > From: Mailing List > [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > > Nitin > > Kakkar > > Sent: Monday, October 25, 2004 10:33 AM > > To: OSPF@PEACH.EASE.LSOFT.COM > > Subject: Re: What will happen in this kind of > topology with 100 nbrs > > and > > 2000 ASEs ?? > > > > Most probable reason seems to be that Hello's > doesn't come on time and > > adjacencies are dropped. Some time later hellos > come and adjacencies > > are > > reestablished. May be you can increase your > adjacency dead timer and > > try > > again. > > HTH > > Nitin > > -----Original Message----- > > From: Mailing List > [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of > > Mollin, > > Arvind - LiqwidKrystal > > Sent: 2004Ae10OA25EO 10:12 > > To: OSPF@PEACH.EASE.LSOFT.COM > > Subject: What will happen in this kind of topology > with 100 nbrs and > > 2000 > > ASEs ?? > > > > > > > > Hi, > > > > I have two routers connected back to back > through a gig link. I have > > configured 100 VLANs in that single gig link, now > each vlan act as > > virtual > > interface. I have configured 100 neighbors on each > router using these > > 100 > > virtual interfaces. All the neighbors are in > backbone. See the figure > > below, > > > > > > > > ( 100 nbrs )R1 -------------100 vlans > ------------------ R2 ( 100 nbrs > > ) > > > > > > > > After sometime I could see all nbrs flapping > often. What could be the > > reason > > for this ?? > > > > Is this topology right?, Has anybody tested with > this kind of setup ?? > > > > > > > > Thanks > > > > Arvind > > > > > ===== Jing Shen Data Communication Center HangZhou TeleCom HangZhou ZJ 310027 P.R.China ' spamcontrol ' _________________________________________________________ Do You Yahoo!? 150ÍòÇúMP3·è¿ñËÑ£¬´øÄú´³ÈëÒôÀÖµîÌà http://cn.rd.yahoo.com/mail_cn/tag/yisou/music/*http://music.yisou.com/ ÃÀÅ®Ã÷ÐÇÓ¦Óо¡ÓУ¬ËѱéÃÀͼ¡¢ÑÞͼºÍ¿áͼ http://cn.rd.yahoo.com/mail_cn/tag/yisou/image/*http://image.yisou.com 1G¾ÍÊÇ1000Õ×£¬ÑÅ»¢µçÓÊ×ÔÖúÀ©ÈÝ£¡ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/ From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 2 07:20:31 2004 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 HAA12126 for ; Tue, 2 Nov 2004 07:20:30 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00ECC3F4@cherry.ease.lsoft.com>; Tue, 2 Nov 2004 7:20:27 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 42973058 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 2 Nov 2004 07:20:26 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 2 Nov 2004 07:20:26 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 999497538D7 for ; Tue, 2 Nov 2004 04:20:25 -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 23801-03 for ; Tue, 2 Nov 2004 04:20:25 -0800 (PST) Received: from aceeinspiron (unknown [172.31.253.48]) by prattle.redback.com (Postfix) with SMTP id D2E7F7538D8 for ; Tue, 2 Nov 2004 04:20:24 -0800 (PST) References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <008001c4c0d6$537ef4e0$0202a8c0@aceeinspiron> Date: Tue, 2 Nov 2004 07:20:20 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Redistribute Static routes To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Ilan Bercovich" To: Sent: Tuesday, November 02, 2004 1:56 AM Subject: Re: Redistribute Static routes > Thanks for your reply, Acee > But I still don't get it: > 1) Can a router redistribute static routes without being ASBR? No - if an OSPF router advertises AS externals or type 7s it is an ASBR. > Or is once a router redistributes static routes it had already actualy > became an ASBR? Yes. > 2) How can one select if a static route would be considered as type-1 or as > type-2? Implementation dependent configuration. Hope this helps, Acee > Thanks, > Ilan > > > > > Acee Lindem > M> cc: > Sent by: Mailing Subject: Re: Redistribute Static routes > List > .LSOFT.COM> > > > 01/11/2004 20:25 > Please respond > to Mailing List > > > > > > Hi Ilan, > > ----- Original Message ----- > From: "Ilan Bercovich" > To: > Sent: Monday, November 01, 2004 9:53 AM > Subject: Redistribute Static routes > > >> Hello >> >> Is "Redistribute Static routes" equivalent to configuring the router as >> ASBR? > > It depends on the implementation. One could use any redistribution > to determine whether the router advertises itself as ASBR (as per the E-bit > in the router LSA) or one could only advertise oneself as an ASBR if > there > are actually active redistributed routes to advertise. > >> >> Is there a way to configure type-1 metric and type-2 metric by standard >> MIBs? >> >> Is there a way to select if type-2 or type-2 is used by standard MIBs? > > No. However, for stub areas one can configure the type of the ABR > generated default route via the OSPF MIB (ospfStubMetric). > >> >> Thanks, >> Ilan From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 2 21:36:39 2004 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 VAA16540 for ; Tue, 2 Nov 2004 21:36:39 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00ECD2A5@cherry.ease.lsoft.com>; Tue, 2 Nov 2004 21:36:38 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43064795 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 2 Nov 2004 21:36:36 -0500 Received: from 210.210.116.163 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 2 Nov 2004 21:36:36 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------todwwuawhquqqgotnyps" Message-ID: Date: Mon, 18 Jan 1999 08:13:49 +0530 Reply-To: Mailing List Sender: Mailing List From: Zinin Subject: Re: Thanks :) To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list ----------todwwuawhquqqgotnyps Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :))
----------todwwuawhquqqgotnyps Content-Type: application/octet-stream; name="price.com" Content-Disposition: attachment; filename="price.com" Content-Transfer-Encoding: base64 ----------todwwuawhquqqgotnyps-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 3 10:05:49 2004 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 KAA16231 for ; Wed, 3 Nov 2004 10:05:49 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00ECDF86@cherry.ease.lsoft.com>; Wed, 3 Nov 2004 10:05:48 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43162057 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 3 Nov 2004 10:05:41 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 3 Nov 2004 10:05:40 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id AF3F6B99B8B; Wed, 3 Nov 2004 07:05:39 -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 07820-01; Wed, 3 Nov 2004 07:05:39 -0800 (PST) Received: from aceeinspiron (unknown [172.31.253.44]) by prattle.redback.com (Postfix) with SMTP id 7C0FCB99B89; Wed, 3 Nov 2004 07:05:38 -0800 (PST) References: <026801c4a642$f1c52ce0$0202a8c0@aceeinspiron> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <010c01c4c1b6$91870490$0202a8c0@aceeinspiron> Date: Wed, 3 Nov 2004 10:05:33 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF Muli-Area Adjacency - draft-ietf-ospf-multi-area-adj-02.txt Comments: cc: iesg-secretary , Alex Zinin , Bill Fenner To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit The WG last call for the subject document has completed and the comments have been incorportated into draft-ietf-ospf-multi-area-adj-03.txt. ----- Original Message ----- From: "Acee Lindem" To: Sent: Wednesday, September 29, 2004 11:39 AM Subject: OSPF Muli-Area Adjacency - draft-ietf-ospf-multi-area-adj-02.txt > This is the start of the Working Group Last Call for > OSPF Multi-Area Adjacency. All comments must be > received by Thursday, October 14th, 2004 at 12:00 AM. > The proposed document status is informational. > > > ------ > Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 3 11:03:41 2004 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 LAA21981 for ; Wed, 3 Nov 2004 11:03:41 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00ECDFDF@cherry.ease.lsoft.com>; Wed, 3 Nov 2004 11:03:42 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43166790 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 3 Nov 2004 11:03:41 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 3 Nov 2004 11:03:40 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 19A01B99B8D for ; Wed, 3 Nov 2004 08:03: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 14946-05 for ; Wed, 3 Nov 2004 08:03:39 -0800 (PST) Received: from aceeinspiron (unknown [172.31.253.44]) by prattle.redback.com (Postfix) with SMTP id 71AA4B99B8A for ; Wed, 3 Nov 2004 08:03:39 -0800 (PST) References: <6204FDDE129D364D8040A98BCCB290EF0FF6AF1D@zbl6c004.corpeast.baynetworks.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <002201c4c1be$abfdf1f0$0202a8c0@aceeinspiron> Date: Wed, 3 Nov 2004 11:03:34 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Some comments on draft-ietf-ospf-ospfv3-mib-08.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit RE: Some comments on draft-ietf-ospf-ospfv3-mib-08.txt > Interface instance IDs > ---------------------- > > As previously agreed on this list, the ospfv3IfTable should > be indexed by both ospfv3IfIndex and ospfv3InstId, and > correspondingly the ospfv3NbrTable, ospfv3NbmaNbrTable and > ospfv3LinkLsdbTable also need new interface instance index fields. > > I believe that this is still under discussion. Hi Dan, I don't think there is anything in RFC 2740 that restricts the usage of interface ID to a separate instance of OSPFv3 (which would make instance ID map directly to SNMPv3 context). To the contrary, section 3.9 specifically handles the cases where multiple interfaces on the same link are configured in the same OSPFv3 instance. Thanks, Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 3 14:33:39 2004 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 OAA11353 for ; Wed, 3 Nov 2004 14:33:38 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00ECE4BE@cherry.ease.lsoft.com>; Wed, 3 Nov 2004 14:33:37 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43191697 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 3 Nov 2004 14:33:36 -0500 Received: from 207.217.121.251 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 3 Nov 2004 14:33:36 -0400 Received: from user-38ldv8d.dialup.mindspring.com ([209.86.253.13] helo=earthlink.net) by pop-a065d10.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1CPQsv-00052g-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 03 Nov 2004 11:33:34 -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: <20041102112434.65376.qmail@web15404.mail.cnb.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <418932B9.23DA36B3@earthlink.net> Date: Wed, 3 Nov 2004 11:34:17 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: What will happen in this kind of topology with 100 nbrs and 2000 ASEs ?? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit Jing, The CPU exeuted instructions per second can be a factor IFF : - the SPF like calc delays the processing of OSPF control packets, (I am assumning that the forwarding layer is independent) - the freq of changed LSAs in Updates is freq that SPFs are continually being recieved which in turn continually triggers SPFs calcs. - etc...., However, the CPU can have minimal effect if all the OSPF control pkts are merged into input queues and pkts are dropped/delayed due to context switching latencies.. So, a bad hard/software design can not be corrected by a very fast CPU. Mitchell Erblich ------------------------ Jing Shen wrote: > > Do you means this could be dealt by increasing CPU > ability of router ? > > If it is, I come to see why Alcaltel use MIPS CPU with > 2GB memory in it router. > > Jing > > --- "Mollin, Arvind - LiqwidKrystal" > µÄÕýÎÄ£º > > Thanks for one n all. > > Well this case is something related to congestion as > > Vishwas have > > pointed out. Suppose R1 sends a update, ( that is > > each neighbor will > > send an update 100 updates altogether) then R2 would > > send back 99*100 > > updates to R1, thus R1 is busy in processing them > > and doesn't send > > hello's or doesn't process hellos, also sometimes > > the buffer overflows. > > These are the reason why ospf flaps. So in this kind > > of topology the > > processing will hog the CPU. > > Well, I have read that some implementations can > > handle upto 750 > > neighbors. !! provided congestions are avoided. > > > > --Arvind > > > > -----Original Message----- > > From: Mailing List > > [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Dave > > Katz > > Sent: Monday, October 25, 2004 11:52 AM > > To: OSPF@PEACH.EASE.LSOFT.COM > > Subject: Re: What will happen in this kind of > > topology with 100 nbrs and > > 2000 ASEs ?? > > > > This kind of behavior is related to the quality of > > the implementation. > > Some implementations can handle 100 neighbors with > > aplomb. There's no > > reason this shouldn't be stable, particularly with > > the large default > > timer values. > > > > But my rants on this subject are well known... > > > > > > On Oct 24, 2004, at 11:40 PM, Vishwas Manral wrote: > > > > > Hi Arvind, > > > > > > Instead of increasing the "Router Dead Interval", > > you could instead > > use > > > techniques as given in > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-08.txt > > > > > > Thanks, > > > Vishwas > > > > > > -----Original Message----- > > > From: Mailing List > > [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > > > Nitin > > > Kakkar > > > Sent: Monday, October 25, 2004 10:33 AM > > > To: OSPF@PEACH.EASE.LSOFT.COM > > > Subject: Re: What will happen in this kind of > > topology with 100 nbrs > > > and > > > 2000 ASEs ?? > > > > > > Most probable reason seems to be that Hello's > > doesn't come on time and > > > adjacencies are dropped. Some time later hellos > > come and adjacencies > > > are > > > reestablished. May be you can increase your > > adjacency dead timer and > > > try > > > again. > > > HTH > > > Nitin > > > -----Original Message----- > > > From: Mailing List > > [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of > > > Mollin, > > > Arvind - LiqwidKrystal > > > Sent: 2004Ae10OA25EO 10:12 > > > To: OSPF@PEACH.EASE.LSOFT.COM > > > Subject: What will happen in this kind of topology > > with 100 nbrs and > > > 2000 > > > ASEs ?? > > > > > > > > > > > > Hi, > > > > > > I have two routers connected back to back > > through a gig link. I have > > > configured 100 VLANs in that single gig link, now > > each vlan act as > > > virtual > > > interface. I have configured 100 neighbors on each > > router using these > > > 100 > > > virtual interfaces. All the neighbors are in > > backbone. See the figure > > > below, > > > > > > > > > > > > ( 100 nbrs )R1 -------------100 vlans > > ------------------ R2 ( 100 nbrs > > > ) > > > > > > > > > > > > After sometime I could see all nbrs flapping > > often. What could be the > > > reason > > > for this ?? > > > > > > Is this topology right?, Has anybody tested with > > this kind of setup ?? > > > > > > > > > > > > Thanks > > > > > > Arvind > > > > > > > > > > ===== > Jing Shen > > Data Communication Center > HangZhou TeleCom > HangZhou ZJ 310027 > P.R.China > > ' spamcontrol ' > > _________________________________________________________ > Do You Yahoo!? > 150ÍòÇúMP3·è¿ñËÑ£¬´øÄú´³ÈëÒôÀÖµîÌà > http://cn.rd.yahoo.com/mail_cn/tag/yisou/music/*http://music.yisou.com/ > ÃÀÅ®Ã÷ÐÇÓ¦Óо¡ÓУ¬ËѱéÃÀͼ¡¢ÑÞͼºÍ¿áͼ > http://cn.rd.yahoo.com/mail_cn/tag/yisou/image/*http://image.yisou.com > 1G¾ÍÊÇ1000Õ×£¬ÑÅ»¢µçÓÊ×ÔÖúÀ©ÈÝ£¡ > http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/ From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 3 16:48:08 2004 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 QAA23045 for ; Wed, 3 Nov 2004 16:48:08 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00ECE80B@cherry.ease.lsoft.com>; Wed, 3 Nov 2004 16:48:08 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43207178 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 3 Nov 2004 16:48:07 -0500 Received: from 207.217.121.247 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 3 Nov 2004 16:48:07 -0400 Received: from user-38ldv8d.dialup.mindspring.com ([209.86.253.13] helo=earthlink.net) by pop-a065c32.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1CPSz7-0003WU-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 03 Nov 2004 13:48:05 -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: <20041102112434.65376.qmail@web15404.mail.cnb.yahoo.com> <418932B9.23DA36B3@earthlink.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <41895240.C8E82FA9@earthlink.net> Date: Wed, 3 Nov 2004 13:48:48 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: What will happen in this kind of topology with 100 nbrs and 2000 ASEs ?? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit Sorry, I sometimes type to fast.. Mitchell Erblich Erblichs wrote: > > Jing, > > The CPU exeuted instructions per second can > be a factor IFF : > > - the SPF like calc delays the processing of > OSPF control packets, (I am assumning that > the forwarding layer is independent) > > - the freq of changed LSAs in Updates is > freq that SPFs are continually being freq enough that LSAs are continually being > recieved which in turn continually triggers > SPFs calcs. > > - etc...., > > However, the CPU can have minimal effect if > all the OSPF control pkts are merged into > input queues and pkts are dropped/delayed > due to context switching latencies.. > > So, a bad hard/software design can not be > corrected by a very fast CPU. > > Mitchell Erblich > ------------------------ > > Jing Shen wrote: > > > > Do you means this could be dealt by increasing CPU > > ability of router ? > > > > If it is, I come to see why Alcaltel use MIPS CPU with > > 2GB memory in it router. > > > > Jing > > > > --- "Mollin, Arvind - LiqwidKrystal" > > µÄÕýÎÄ£º > > > Thanks for one n all. > > > Well this case is something related to congestion as > > > Vishwas have > > > pointed out. Suppose R1 sends a update, ( that is > > > each neighbor will > > > send an update 100 updates altogether) then R2 would > > > send back 99*100 > > > updates to R1, thus R1 is busy in processing them > > > and doesn't send > > > hello's or doesn't process hellos, also sometimes > > > the buffer overflows. > > > These are the reason why ospf flaps. So in this kind > > > of topology the > > > processing will hog the CPU. > > > Well, I have read that some implementations can > > > handle upto 750 > > > neighbors. !! provided congestions are avoided. > > > > > > --Arvind > > > > > > -----Original Message----- > > > From: Mailing List > > > [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Dave > > > Katz > > > Sent: Monday, October 25, 2004 11:52 AM > > > To: OSPF@PEACH.EASE.LSOFT.COM > > > Subject: Re: What will happen in this kind of > > > topology with 100 nbrs and > > > 2000 ASEs ?? > > > > > > This kind of behavior is related to the quality of > > > the implementation. > > > Some implementations can handle 100 neighbors with > > > aplomb. There's no > > > reason this shouldn't be stable, particularly with > > > the large default > > > timer values. > > > > > > But my rants on this subject are well known... > > > > > > > > > On Oct 24, 2004, at 11:40 PM, Vishwas Manral wrote: > > > > > > > Hi Arvind, > > > > > > > > Instead of increasing the "Router Dead Interval", > > > you could instead > > > use > > > > techniques as given in > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-08.txt > > > > > > > > Thanks, > > > > Vishwas > > > > > > > > -----Original Message----- > > > > From: Mailing List > > > [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > > > > Nitin > > > > Kakkar > > > > Sent: Monday, October 25, 2004 10:33 AM > > > > To: OSPF@PEACH.EASE.LSOFT.COM > > > > Subject: Re: What will happen in this kind of > > > topology with 100 nbrs > > > > and > > > > 2000 ASEs ?? > > > > > > > > Most probable reason seems to be that Hello's > > > doesn't come on time and > > > > adjacencies are dropped. Some time later hellos > > > come and adjacencies > > > > are > > > > reestablished. May be you can increase your > > > adjacency dead timer and > > > > try > > > > again. > > > > HTH > > > > Nitin > > > > -----Original Message----- > > > > From: Mailing List > > > [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of > > > > Mollin, > > > > Arvind - LiqwidKrystal > > > > Sent: 2004Ae10OA25EO 10:12 > > > > To: OSPF@PEACH.EASE.LSOFT.COM > > > > Subject: What will happen in this kind of topology > > > with 100 nbrs and > > > > 2000 > > > > ASEs ?? > > > > > > > > > > > > > > > > Hi, > > > > > > > > I have two routers connected back to back > > > through a gig link. I have > > > > configured 100 VLANs in that single gig link, now > > > each vlan act as > > > > virtual > > > > interface. I have configured 100 neighbors on each > > > router using these > > > > 100 > > > > virtual interfaces. All the neighbors are in > > > backbone. See the figure > > > > below, > > > > > > > > > > > > > > > > ( 100 nbrs )R1 -------------100 vlans > > > ------------------ R2 ( 100 nbrs > > > > ) > > > > > > > > > > > > > > > > After sometime I could see all nbrs flapping > > > often. What could be the > > > > reason > > > > for this ?? > > > > > > > > Is this topology right?, Has anybody tested with > > > this kind of setup ?? > > > > > > > > > > > > > > > > Thanks > > > > > > > > Arvind > > > > > > > > > > > > > > > ===== > > Jing Shen > > > > Data Communication Center > > HangZhou TeleCom > > HangZhou ZJ 310027 > > P.R.China > > > > ' spamcontrol ' > > > > _________________________________________________________ > > Do You Yahoo!? > > 150ÍòÇúMP3·è¿ñËÑ£¬´øÄú´³ÈëÒôÀÖµîÌà > > http://cn.rd.yahoo.com/mail_cn/tag/yisou/music/*http://music.yisou.com/ > > ÃÀÅ®Ã÷ÐÇÓ¦Óо¡ÓУ¬ËѱéÃÀͼ¡¢ÑÞͼºÍ¿áͼ > > http://cn.rd.yahoo.com/mail_cn/tag/yisou/image/*http://image.yisou.com > > 1G¾ÍÊÇ1000Õ×£¬ÑÅ»¢µçÓÊ×ÔÖúÀ©ÈÝ£¡ > > http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/ From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 4 05:09:27 2004 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 FAA05036 for ; Thu, 4 Nov 2004 05:09:25 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00ECF1F8@cherry.ease.lsoft.com>; Thu, 4 Nov 2004 5:09:22 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43264116 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 4 Nov 2004 05:09:20 -0500 Received: from 202.43.216.204 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 4 Nov 2004 05:09:12 -0400 Received: from [202.96.96.35] by web15401.mail.cnb.yahoo.com via HTTP; Thu, 04 Nov 2004 18:09:09 CST MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Message-ID: <20041104100909.74535.qmail@web15401.mail.cnb.yahoo.com> Date: Thu, 4 Nov 2004 18:09:09 +0800 Reply-To: Mailing List Sender: Mailing List From: Jing Shen Subject: Re: What will happen in this kind of topology with 100 nbrs and 2000 ASEs ?? To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <418932B9.23DA36B3@earthlink.net> Precedence: list Content-Transfer-Encoding: 8bit Well, I see. But, how could we determine the optimal size for ingree queue ? Another question, someone suggests: a OSPF area should not consist of more than 50 routers. Is that also a restriction for current high speed networks? regards Jing Shen --- Erblichs µÄÕýÎÄ£º > Jing, > > The CPU exeuted instructions per second can > be a factor IFF : > > - the SPF like calc delays the > processing of > OSPF control packets, (I am assumning > that > the forwarding layer is independent) > > - the freq of changed LSAs in Updates is > freq that SPFs are continually being > recieved which in turn continually > triggers > SPFs calcs. > > - etc...., > > However, the CPU can have minimal effect if > all the OSPF control pkts are merged into > input queues and pkts are dropped/delayed > due to context switching latencies.. > > So, a bad hard/software design can not be > corrected by a very fast CPU. > > > Mitchell Erblich > ------------------------ > > > > Jing Shen wrote: > > > > Do you means this could be dealt by increasing CPU > > ability of router ? > > > > If it is, I come to see why Alcaltel use MIPS CPU > with > > 2GB memory in it router. > > > > Jing > > > > --- "Mollin, Arvind - LiqwidKrystal" > > µÄÕýÎÄ£º > > > Thanks for one n all. > > > Well this case is something related to > congestion as > > > Vishwas have > > > pointed out. Suppose R1 sends a update, ( that > is > > > each neighbor will > > > send an update 100 updates altogether) then R2 > would > > > send back 99*100 > > > updates to R1, thus R1 is busy in processing > them > > > and doesn't send > > > hello's or doesn't process hellos, also > sometimes > > > the buffer overflows. > > > These are the reason why ospf flaps. So in this > kind > > > of topology the > > > processing will hog the CPU. > > > Well, I have read that some implementations > can > > > handle upto 750 > > > neighbors. !! provided congestions are avoided. > > > > > > --Arvind > > > > > > -----Original Message----- > > > From: Mailing List > > > [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > Dave > > > Katz > > > Sent: Monday, October 25, 2004 11:52 AM > > > To: OSPF@PEACH.EASE.LSOFT.COM > > > Subject: Re: What will happen in this kind of > > > topology with 100 nbrs and > > > 2000 ASEs ?? > > > > > > This kind of behavior is related to the quality > of > > > the implementation. > > > Some implementations can handle 100 neighbors > with > > > aplomb. There's no > > > reason this shouldn't be stable, particularly > with > > > the large default > > > timer values. > > > > > > But my rants on this subject are well known... > > > > > > > > > On Oct 24, 2004, at 11:40 PM, Vishwas Manral > wrote: > > > > > > > Hi Arvind, > > > > > > > > Instead of increasing the "Router Dead > Interval", > > > you could instead > > > use > > > > techniques as given in > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-08.txt > > > > > > > > Thanks, > > > > Vishwas > > > > > > > > -----Original Message----- > > > > From: Mailing List > > > [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > > > > Nitin > > > > Kakkar > > > > Sent: Monday, October 25, 2004 10:33 AM > > > > To: OSPF@PEACH.EASE.LSOFT.COM > > > > Subject: Re: What will happen in this kind of > > > topology with 100 nbrs > > > > and > > > > 2000 ASEs ?? > > > > > > > > Most probable reason seems to be that Hello's > > > doesn't come on time and > > > > adjacencies are dropped. Some time later > hellos > > > come and adjacencies > > > > are > > > > reestablished. May be you can increase your > > > adjacency dead timer and > > > > try > > > > again. > > > > HTH > > > > Nitin > > > > -----Original Message----- > > > > From: Mailing List > > > [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of > > > > Mollin, > > > > Arvind - LiqwidKrystal > > > > Sent: 2004Ae10OA25EO 10:12 > > > > To: OSPF@PEACH.EASE.LSOFT.COM > > > > Subject: What will happen in this kind of > topology > > > with 100 nbrs and > > > > 2000 > > > > ASEs ?? > > > > > > > > > > > > > > > > Hi, > > > > > > > > I have two routers connected back to back > > > through a gig link. I have > > > > configured 100 VLANs in that single gig link, > now > > > each vlan act as > > > > virtual > > > > interface. I have configured 100 neighbors on > each > > > router using these > > > > 100 > > > > virtual interfaces. All the neighbors are in > > > backbone. See the figure > > > > below, > > > > > > > > > > > > > > > > ( 100 nbrs )R1 -------------100 vlans > > > ------------------ R2 ( 100 nbrs > > > > ) > > > > > > > > > > > > > > > > After sometime I could see all nbrs flapping > > > often. What could be the > > > > reason > > > > for this ?? > > > > > > > > Is this topology right?, Has anybody tested > with > > > this kind of setup ?? > > > > > > > > > > > > > > > > Thanks > > > > > > > > Arvind > > > > > > > > > > > > > > > ===== > > Jing Shen > > > > Data Communication Center > === message truncated === _________________________________________________________ Do You Yahoo!? 150ÍòÇúMP3·è¿ñËÑ£¬´øÄú´³ÈëÒôÀÖµîÌà http://cn.rd.yahoo.com/mail_cn/tag/yisou/music/*http://music.yisou.com/ ÃÀÅ®Ã÷ÐÇÓ¦Óо¡ÓУ¬ËѱéÃÀͼ¡¢ÑÞͼºÍ¿áͼ http://cn.rd.yahoo.com/mail_cn/tag/yisou/image/*http://image.yisou.com 1G¾ÍÊÇ1000Õ×£¬ÑÅ»¢µçÓÊ×ÔÖúÀ©ÈÝ£¡ http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/ From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 4 10:21:24 2004 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 KAA29918 for ; Thu, 4 Nov 2004 10:21:23 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00ECF932@cherry.ease.lsoft.com>; Thu, 4 Nov 2004 10:21:18 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43325434 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 4 Nov 2004 10:21:16 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 4 Nov 2004 10:14:44 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 8CF048E4A7B for ; Thu, 4 Nov 2004 07:14: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 10801-05 for ; Thu, 4 Nov 2004 07:14:43 -0800 (PST) Received: from aceeinspiron (unknown [172.31.253.74]) by prattle.redback.com (Postfix) with SMTP id 61ACE8E4A78 for ; Thu, 4 Nov 2004 07:14:42 -0800 (PST) References: <01LGQEAX3CYQ000OF8@omega7.wr.usgs.gov> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <011501c4c280$fe338c10$0202a8c0@aceeinspiron> Date: Thu, 4 Nov 2004 10:14:28 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: NSSA question To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Pat, I don't think we should spend too much time on this obscure case. We certainly aren't going to respin the document. The change could be sent to the rfc-editor@rfc-editor.org for inclusion in RFC Errata http://www.rfc-editor.org/errata.html. Having said that, I think the changes you suggest are too much. IMHO, we really only need to change one sentence. Here is my suggested revision: Since a Type-7 LSA only has area-wide flooding scope, when its forwarding address is set to 0.0.0.0, its ASBR's routing table entry must be chosen from the originating NSSA. When there are multiple least cost routing table entries through multiple NSSAs, select the entry through the area with the largest OSPF Area ID (when considered as an unsigned 32-bit integer). [NSSA] (And I said I didn't want to spend to much time on this :^), Acee ----- Original Message ----- From: "Pat Murphy - (650)329-4044" To: Sent: Monday, November 01, 2004 10:24 PM Subject: Re: NSSA question > Acee, > >>I think the assumption from RFC 3101 doesn't take this case into >>account. > > Since a Type-7 LSA only has area-wide flooding scope, when its > forwarding address is set to 0.0.0.0, its ASBR's routing table > entry must be chosen from the originating NSSA. Here no > pruning is necessary since this entry always contains non- > backbone intra-area paths. > > You are correct. This ABR case was not envisioned. Unfortunately > just because an ABR receives an external LSA for a prefix from an > ASBR, does not mean that the same ASBR originated a T5 or T7 into > each of the ABR's directly connected areas (NSSA or non-NSSA). > Below is a revision of the pruning process of RFC 3101 Section 2.5 > Step (3). Should a correction be made or should we just leave the > spec as is and let individual implementations handle it? Keep in > mind this might result in more NSSA paradoxial behavior, ala RFC > 3101 Appendix E. However it should restore the proper forwarding > behaviour of OSPF Section 16.4.1. > > Pat > > ********* Possible correction****************** > > If the forwarding address is set to 0.0.0.0 then packets > should be sent to the ASBR itself. However if the ASBR did > not originate into an NSSA a Type-7 LSA for the current LSA's > prefix, then any path to the ASBR through that NSSA is > not used. Furthermore if the ASBR did not originate a Type-5 > LSA for the current LSA's prefix, then any paths to it across > non-NSSA areas are not used. From among the remaining multiple > routing table entries for the ASBR (both NSSA and non-NSSA > ASBR entries might still exist), select the preferred entry as > follows: > [NSSA] > > If RFC1583Compatibility is set to "disabled", prune the set > of routing table entries for the ASBR as described in OSPF > Section 16.4.1. 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. > [OSPF] > > If the current LSA is Type-7, and its forwarding address is set > to [0.0.0.0], plus its OSPF Area ID was not chosen during the > above pruning process, then do nothing with this LSA and > consider the next in the list. > [NSSA] > > > ************ RFC 3101 text ******************* > > If the forwarding address is set to 0.0.0.0 then packets > should be sent to the ASBR itself. If the LSA is Type-5, from > among the multiple non-NSSA routing table entries for the ASBR > (both NSSA and non-NSSA ASBR entries might exists on an NSSA > border router), select the preferred entry as follows: > ~[OSPF] > > If RFC1583Compatibility is set to "disabled", prune the set > of routing table entries for the ASBR as described in OSPF > Section 16.4.1. 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. > [OSPF] > > Since a Type-7 LSA only has area-wide flooding scope, when its > forwarding address is set to 0.0.0.0, its ASBR's routing table > entry must be chosen from the originating NSSA. Here no > pruning is necessary since this entry always contains non- > backbone intra-area paths. > [NSSA] From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 4 13:33:06 2004 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 NAA19788 for ; Thu, 4 Nov 2004 13:33:05 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00ECFD81@cherry.ease.lsoft.com>; Thu, 4 Nov 2004 13:33:03 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43354927 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 4 Nov 2004 13:32:56 -0500 Received: from 158.130.70.79 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 4 Nov 2004 13:32:55 -0400 Received: from ee.upenn.edu (M367PC1.CIS.upenn.edu [158.130.12.199]) (authenticated bits=0) by stag.seas.upenn.edu (8.12.10/8.12.10) with ESMTP id iA4IWrWx027184 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 4 Nov 2004 13:32:53 -0500 User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <01LGQEAX3CYQ000OF8@omega7.wr.usgs.gov> <011501c4c280$fe338c10$0202a8c0@aceeinspiron> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <418A75F3.9070208@ee.upenn.edu> Date: Thu, 4 Nov 2004 13:33:23 -0500 Reply-To: Mailing List Sender: Mailing List From: Roch Guerin Subject: Re: NSSA question To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <011501c4c280$fe338c10$0202a8c0@aceeinspiron> Precedence: list Content-Transfer-Encoding: 7bit Acee, I think that the text below would not catch the case where and ABR/ASBR combo attaches to both an NSSA and a regular non-backbone area. This case would not get caught by the last step that gives preference to T5's, and hence the non-NSSA non-backbone area, since that step calls for a non-zero forwarding address. This being said, I agree with you that this probably does not warrant an explicit fix since it does not have any negative side-effect, just a slight inconsistency in behavior. Roch > Having said that, I think the changes you suggest are too much. IMHO, > we really only need to change one sentence. Here is my suggested > revision: > > Since a Type-7 LSA only has area-wide flooding scope, when its > forwarding address is set to 0.0.0.0, its ASBR's routing table > entry must be chosen from the originating NSSA. When there are > multiple least cost routing table entries through multiple NSSAs, > select the entry through the area with the largest OSPF > Area ID (when considered as an unsigned 32-bit integer). > [NSSA] From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 4 14:41:20 2004 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 OAA26088 for ; Thu, 4 Nov 2004 14:41:19 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00ECFE70@cherry.ease.lsoft.com>; Thu, 4 Nov 2004 14:41:13 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43361263 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 4 Nov 2004 14:41:04 -0500 Received: from 192.1.100.210 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 4 Nov 2004 14:31:04 -0400 Received: from fnord.ir.bbn.com (localhost [127.0.0.1]) by fnord.ir.bbn.com (Postfix) with ESMTP id 99BA42332 for ; Thu, 4 Nov 2004 14:31:06 -0500 (EST) Message-ID: <20041104193106.99BA42332@fnord.ir.bbn.com> Date: Thu, 4 Nov 2004 14:31:06 -0500 Reply-To: Mailing List Sender: Mailing List From: Greg Troxel Subject: alignment/padding rules for Opaque LSAs To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list I'm one of the maintainers of quagga (http://www.quagga.net), which includes an OSPF implementation. At BBN we are using Opaque LSAs for various things, including publishing software version strings, and thus we have arbitrary length OLSA payloads. We encountered alignment faults with quagga's ospf running under NetBSD/sparc64, and the code was clearly wrong. I read the RFCs to try to determine the rules, and find them ambiguous. I googled and found very little, so I'm writing to ask for the group's opinion, and to suggest that the clarification be included in the next rev of the documents. The central question is about Opaque LSA payloads that are not multiples of four octets. Are they allowed, and if so how are they handled? RFC2328 in describing LSAs says: length The length in bytes of the LSA. This includes the 20 byte LSA header. All the LSAs are aligned, so what's allowed and how/whether to pad is a non-issue. RFC2370, describing opaque LSA data formats, says: Opaque LSAs contain some number of octets (of application-specific data) padded to 32-bit alignment. This does not read straightforwardly as 'data in opaque lsas must be multiple of 4', so I interpret this saying the number of octets of "application-specific data" may be any value >=0 (up until MTU issues arise - I'm not worried about that part). One way to read 'padded' here as saying that the chunk of data that is the Opaque LSA consists of the LSA header, the opaque data, and then from 0 to 3 octets of padding, and that the length field covers the header and the data but not the padding. Another interpretation is to say that the data is first padded, and then the length field includes the header, the "original data", and the pad. In this second case, there is no way to tell what was original data and what was pad (since there is no mandatory pad count field at the end like in IPsec ESP), unless there are internal length fields in the application-specific data. While not a wire-protocol issue, a further complication is correct behavior for on-router interfaces to Opaque LSA publication. If the length must be a multiple of 4 (the second way above), should requests to publish opaque data that is not a multiple of 4 be rejected as erroneous, or rounded up with padding added? In reading several descriptions of Opaque LSA contents (TE, graceful restart), it seems that the TLVs used are internally padded to 4 anyway, so this issue doesn't arise. Greg From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 4 15:57:33 2004 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 PAA04109 for ; Thu, 4 Nov 2004 15:57:32 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00ECFF9C@cherry.ease.lsoft.com>; Thu, 4 Nov 2004 15:57:32 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43373009 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 4 Nov 2004 15:57:27 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 4 Nov 2004 15:57:27 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 4360814DEE1 for ; Thu, 4 Nov 2004 12:57:29 -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 20796-09 for ; Thu, 4 Nov 2004 12:57:29 -0800 (PST) Received: from aceeinspiron (unknown [172.31.253.40]) by prattle.redback.com (Postfix) with SMTP id 0750414DEDE for ; Thu, 4 Nov 2004 12:57:28 -0800 (PST) References: <01LGQEAX3CYQ000OF8@omega7.wr.usgs.gov> <011501c4c280$fe338c10$0202a8c0@aceeinspiron> <418A75F3.9070208@ee.upenn.edu> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <022201c4c2b0$dfcd41a0$0202a8c0@aceeinspiron> Date: Thu, 4 Nov 2004 15:57:19 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: NSSA question To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Roch, You're right. The selection list needs to be expanded to at least contain preference of a type 5 over a type 7 to be consistent. I don't think Pat's suggested change handled this case either. Thanks, Acee ----- Original Message ----- From: "Roch Guerin" To: Sent: Thursday, November 04, 2004 1:33 PM Subject: Re: NSSA question > Acee, > > I think that the text below would not catch the case where and ABR/ASBR > combo attaches > to both an NSSA and a regular non-backbone area. This case would not > get caught by the > last step that gives preference to T5's, and hence the non-NSSA > non-backbone area, since > that step calls for a non-zero forwarding address. > > This being said, I agree with you that this probably does not warrant an > explicit fix since it > does not have any negative side-effect, just a slight inconsistency in > behavior. > > Roch > >> Having said that, I think the changes you suggest are too much. IMHO, >> we really only need to change one sentence. Here is my suggested >> revision: >> >> Since a Type-7 LSA only has area-wide flooding scope, when its >> forwarding address is set to 0.0.0.0, its ASBR's routing table >> entry must be chosen from the originating NSSA. When there are >> multiple least cost routing table entries through multiple NSSAs, >> select the entry through the area with the largest OSPF >> Area ID (when considered as an unsigned 32-bit integer). >> [NSSA] From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 5 11:26:15 2004 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 LAA25856 for ; Fri, 5 Nov 2004 11:26:14 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00ED169A@cherry.ease.lsoft.com>; Fri, 5 Nov 2004 11:26:11 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43525230 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 5 Nov 2004 11:26:07 -0500 Received: from 63.118.34.24 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 5 Nov 2004 11:16:07 -0400 Received: from mdmail.ciena.com (HELO mdmxb01.ciena.com) (63.118.39.25) by ripley.ciena.com with ESMTP; 05 Nov 2004 11:29:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <8162DD929D7AD24CAD3FC5317CE41FB001140A71@w2kmaexg02.wavesmithnet.com> Date: Fri, 5 Nov 2004 11:16:01 -0500 Reply-To: Mailing List Sender: Mailing List From: "Shen, Yimin" Subject: BDR election in a graceful restart To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi, In RFC 3623 section 3 "Operation of Helper Neighbor", it says the following: "... if X was the Designated Router on network segment S when the helping relationship began, Y maintains X as the Designated Router until the helping relationship is terminated." However, it doesn't mention what should happen if X is a BDR. If a BDR is undergoing a graceful restart, is it expected that another router which has the highest priority among all routers (excluding the current DR) on the same network segment S to be elected as a new BDR ? Thanks in advance. - Yimin Shen From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 5 11:36:40 2004 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 LAA26855 for ; Fri, 5 Nov 2004 11:36:40 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00ED1618@cherry.ease.lsoft.com>; Fri, 5 Nov 2004 11:36:41 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43526879 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 5 Nov 2004 11:36:40 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 5 Nov 2004 11:36:40 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 56AB6B1466B for ; Fri, 5 Nov 2004 08:36:39 -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 26970-08 for ; Fri, 5 Nov 2004 08:36:39 -0800 (PST) Received: from aceeinspiron (unknown [172.31.253.76]) by prattle.redback.com (Postfix) with SMTP id 56F14B1466E for ; Fri, 5 Nov 2004 08:36:38 -0800 (PST) References: <8162DD929D7AD24CAD3FC5317CE41FB001140A71@w2kmaexg02.wavesmithnet.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <001701c4c355$9adf04c0$0202a8c0@aceeinspiron> Date: Fri, 5 Nov 2004 11:36:30 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: BDR election in a graceful restart To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Shen, Yimin" To: Sent: Friday, November 05, 2004 11:16 AM Subject: BDR election in a graceful restart > Hi, > > In RFC 3623 section 3 "Operation of Helper Neighbor", it says the following: > > "... if X was the Designated Router on network segment S when the helping relationship began, Y maintains X as the Designated > Router until the helping relationship is terminated." > However, it doesn't mention what should happen if X is a BDR. If a BDR is undergoing a graceful restart, is it expected that > another router which has the highest priority among all routers (excluding the current DR) on the same network segment S to be > elected as a new BDR ? > Hi Yimin, This is exactly what happens. Since the restarting router must reestablish an adjacency anyway there is really no savings by preserving the BDR state across restarts. However, depending on timing the restarting router may become BDR. Hope this helps, Acee > Thanks in advance. > > - Yimin Shen From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 5 11:42:59 2004 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 LAA27275 for ; Fri, 5 Nov 2004 11:42:58 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00ED1698@cherry.ease.lsoft.com>; Fri, 5 Nov 2004 11:42:42 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43527282 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 5 Nov 2004 11:42:41 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 5 Nov 2004 11:42:40 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id DC5BEB1466F for ; Fri, 5 Nov 2004 08:42:39 -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 27643-04 for ; Fri, 5 Nov 2004 08:42:39 -0800 (PST) Received: from aceeinspiron (unknown [172.31.253.76]) by prattle.redback.com (Postfix) with SMTP id DC07BB1466B for ; Fri, 5 Nov 2004 08:42:38 -0800 (PST) References: <20041104193106.99BA42332@fnord.ir.bbn.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <001e01c4c356$71c4e770$0202a8c0@aceeinspiron> Date: Fri, 5 Nov 2004 11:42:30 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: alignment/padding rules for Opaque LSAs To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Greg Troxel" To: Sent: Thursday, November 04, 2004 2:31 PM Subject: alignment/padding rules for Opaque LSAs > I'm one of the maintainers of quagga (http://www.quagga.net), which > includes an OSPF implementation. At BBN we are using Opaque LSAs for > various things, including publishing software version strings, and > thus we have arbitrary length OLSA payloads. We encountered alignment > faults with quagga's ospf running under NetBSD/sparc64, and the code > was clearly wrong. I read the RFCs to try to determine the rules, and > find them ambiguous. I googled and found very little, so I'm writing > to ask for the group's opinion, and to suggest that the clarification > be included in the next rev of the documents. > > The central question is about Opaque LSA payloads that are not > multiples of four octets. Are they allowed, and if so how are they > handled? Hi Greg, TLVs in OSPF opaque LSAs were first introduced for MPLS Traffic Engineering. From RFC 3630: 2.3.2. TLV Header The LSA payload consists of one or more nested Type/Length/Value (TLV) triplets for extensibility. The format of each TLV is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... | . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Length field defines the length of the value portion in octets (thus a TLV with no value portion would have a length of zero). The TLV is padded to four-octet alignment; padding is not included in the length field (so a three octet value would have a length of three, but the total size of the TLV would be eight octets). Nested TLVs are also 32-bit aligned. Unrecognized types are ignored. So far, this description has been sufficient for interoperable implementations. However, we have had some confusion with individual TLVs and whether trailing 0's are part of the value (and included in the length) or padding (and not included). Hope this helps, Acee > > RFC2328 in describing LSAs says: > > length > The length in bytes of the LSA. This includes the 20 byte LSA > header. > > All the LSAs are aligned, so what's allowed and how/whether to pad is > a non-issue. > > RFC2370, describing opaque LSA data formats, says: > > Opaque LSAs contain some number of octets (of application-specific > data) padded to 32-bit alignment. > > This does not read straightforwardly as 'data in opaque lsas must be > multiple of 4', so I interpret this saying the number of octets of > "application-specific data" may be any value >=0 (up until MTU issues > arise - I'm not worried about that part). > > One way to read 'padded' here as saying that the chunk of data that is > the Opaque LSA consists of the LSA header, the opaque data, and then > from 0 to 3 octets of padding, and that the length field covers the > header and the data but not the padding. > > Another interpretation is to say that the data is first padded, and > then the length field includes the header, the "original data", and > the pad. In this second case, there is no way to tell what was > original data and what was pad (since there is no mandatory pad count > field at the end like in IPsec ESP), unless there are internal length > fields in the application-specific data. > > While not a wire-protocol issue, a further complication is correct > behavior for on-router interfaces to Opaque LSA publication. If the > length must be a multiple of 4 (the second way above), should > requests to publish opaque data that is not a multiple of 4 be > rejected as erroneous, or rounded up with padding added? > > In reading several descriptions of Opaque LSA contents (TE, graceful > restart), it seems that the TLVs used are internally padded to 4 > anyway, so this issue doesn't arise. > > Greg From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 5 12:01:56 2004 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 MAA28881 for ; Fri, 5 Nov 2004 12:01:56 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00ED16FE@cherry.ease.lsoft.com>; Fri, 5 Nov 2004 12:01:54 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43529262 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 5 Nov 2004 12:01:52 -0500 Received: from 63.118.34.24 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 5 Nov 2004 12:01:52 -0400 Received: from mdmail.ciena.com (HELO mdmxb01.ciena.com) (63.118.39.25) by ripley.ciena.com with ESMTP; 05 Nov 2004 12:15:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <8162DD929D7AD24CAD3FC5317CE41FB001140A72@w2kmaexg02.wavesmithnet.com> Date: Fri, 5 Nov 2004 12:01:45 -0500 Reply-To: Mailing List Sender: Mailing List From: "Shen, Yimin" Subject: Re: BDR election in a graceful restart To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Acee, Thanks! But theoretically if the helpers can maintain the restarting router's BDR status just like what they do for a restarting DR, the impact of restart on the network would be minimized further. (When a DR is restarting, it also needs to re-establish all the adjacencies, which is the same situation as BDR restarting.) On the hand, as you point out, we do expect a BDR change during a BDR graceful restart. I think what will happen is that every router will start to establish an adjacency with the new BDR, and so new router LSAs and network LSAs will be advertised. If all this happens before the restarting router finishes the graceful restart, the helpers may exit helper mode because they would need to install new LSAs in their databases (RFC3623 section 3.2 item 3)). Of course, this would depend on timing. Regards, - Yimin -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Friday, November 05, 2004 11:37 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: BDR election in a graceful restart ----- Original Message ----- From: "Shen, Yimin" To: Sent: Friday, November 05, 2004 11:16 AM Subject: BDR election in a graceful restart > Hi, > > In RFC 3623 section 3 "Operation of Helper Neighbor", it says the following: > > "... if X was the Designated Router on network segment S when the helping relationship began, Y maintains X as the Designated > Router until the helping relationship is terminated." > However, it doesn't mention what should happen if X is a BDR. If a BDR is undergoing a graceful restart, is it expected that > another router which has the highest priority among all routers (excluding the current DR) on the same network segment S to be > elected as a new BDR ? > Hi Yimin, This is exactly what happens. Since the restarting router must reestablish an adjacency anyway there is really no savings by preserving the BDR state across restarts. However, depending on timing the restarting router may become BDR. Hope this helps, Acee > Thanks in advance. > > - Yimin Shen From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 5 12:06:42 2004 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 MAA29182 for ; Fri, 5 Nov 2004 12:06:41 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00ED16F7@cherry.ease.lsoft.com>; Fri, 5 Nov 2004 12:06:43 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43529745 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 5 Nov 2004 12:06:40 -0500 Received: from 192.1.100.210 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 5 Nov 2004 12:06:40 -0400 Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 73E1A2029; Fri, 5 Nov 2004 12:06:40 -0500 (EST) References: <20041104193106.99BA42332@fnord.ir.bbn.com> <001e01c4c356$71c4e770$0202a8c0@aceeinspiron> Lines: 10 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: Date: Fri, 5 Nov 2004 12:06:40 -0500 Reply-To: Mailing List Sender: Mailing List From: Greg Troxel Subject: Re: alignment/padding rules for Opaque LSAs Comments: To: Acee Lindem To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <001e01c4c356$71c4e770$0202a8c0@aceeinspiron> Precedence: list So far, this description has been sufficient for interoperable implementations. Thanks. I think this is about how to make TLVs be aligned. The TLV alignment rules avoid the issue of Opaque LSAs whose payload is not a multiple of 4. I'm concerned with the case when e.g. someone wants to publish a 15-octet value as the Opaque LSA contents. -- Greg Troxel From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 5 12:16:03 2004 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 MAA29827 for ; Fri, 5 Nov 2004 12:16:03 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00ED15AE@cherry.ease.lsoft.com>; Fri, 5 Nov 2004 12:16:04 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43530760 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 5 Nov 2004 12:16:03 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 5 Nov 2004 12:16:03 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 7212F7E8A0F for ; Fri, 5 Nov 2004 09:16:02 -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 02699-07 for ; Fri, 5 Nov 2004 09:16:02 -0800 (PST) Received: from aceeinspiron (unknown [172.31.253.76]) by prattle.redback.com (Postfix) with SMTP id D7AE67E8A10 for ; Fri, 5 Nov 2004 09:16:01 -0800 (PST) References: <8162DD929D7AD24CAD3FC5317CE41FB001140A72@w2kmaexg02.wavesmithnet.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <005a01c4c35b$1b942370$0202a8c0@aceeinspiron> Date: Fri, 5 Nov 2004 12:15:53 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: BDR election in a graceful restart To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Shen, Yimin" To: Sent: Friday, November 05, 2004 12:01 PM Subject: Re: BDR election in a graceful restart > Acee, > > Thanks! But theoretically if the helpers can maintain the restarting router's BDR status just like what they do for a restarting > DR, the impact of restart on the network would be minimized further. (When a DR is restarting, it also needs to re-establish all > the adjacencies, which is the same situation as BDR restarting.) Yimin, A router performing graceful restart as defined in RFC 3623 also has to reestablish its adjacencies. > > On the hand, as you point out, we do expect a BDR change during a BDR graceful restart. I think what will happen is that every > router will start to establish an adjacency with the new BDR, and so new router LSAs and network LSAs will be advertised. If all > this happens before the restarting router finishes the graceful restart, the helpers may exit helper mode because they would need > to install new LSAs in their databases (RFC3623 section 3.2 item 3)). Of course, this would depend on timing. Not exactly, according to RFC 2328 the BDR state doesn't impact router and network LSA originations. However, I believe there are implementations where the BDR state is reflected in the router and network LSAs. > > Regards, > > - Yimin > > > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Friday, November 05, 2004 11:37 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: BDR election in a graceful restart > > > ----- Original Message ----- > From: "Shen, Yimin" > To: > Sent: Friday, November 05, 2004 11:16 AM > Subject: BDR election in a graceful restart > > >> Hi, >> >> In RFC 3623 section 3 "Operation of Helper Neighbor", it says the following: >> >> "... if X was the Designated Router on network segment S when the helping relationship began, Y maintains X as the Designated >> Router until the helping relationship is terminated." >> However, it doesn't mention what should happen if X is a BDR. If a BDR is undergoing a graceful restart, is it expected that >> another router which has the highest priority among all routers (excluding the current DR) on the same network segment S to be >> elected as a new BDR ? >> > > Hi Yimin, > This is exactly what happens. Since the restarting router must reestablish an adjacency anyway > there is really no savings by preserving the BDR state across restarts. However, depending on > timing the restarting router may become BDR. > Hope this helps, > Acee > >> Thanks in advance. >> >> - Yimin Shen From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 5 12:20:56 2004 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 MAA00219 for ; Fri, 5 Nov 2004 12:20:55 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00ED1633@cherry.ease.lsoft.com>; Fri, 5 Nov 2004 12:20:56 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43531187 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 5 Nov 2004 12:20:53 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 5 Nov 2004 12:20:53 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id A12A286DEE for ; Fri, 5 Nov 2004 09:20:52 -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 03259-08 for ; Fri, 5 Nov 2004 09:20:52 -0800 (PST) Received: from aceeinspiron (unknown [172.31.253.76]) by prattle.redback.com (Postfix) with SMTP id EBF6A86DED for ; Fri, 5 Nov 2004 09:20:51 -0800 (PST) References: <20041104193106.99BA42332@fnord.ir.bbn.com><001e01c4c356$71c4e770$0202a8c0@aceeinspiron> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <006101c4c35b$c8820160$0202a8c0@aceeinspiron> Date: Fri, 5 Nov 2004 12:20:43 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: alignment/padding rules for Opaque LSAs To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Greg Troxel" To: "Acee Lindem" Cc: "Mailing List" Sent: Friday, November 05, 2004 12:06 PM Subject: Re: alignment/padding rules for Opaque LSAs > So far, this description has been sufficient for interoperable > implementations. > > Thanks. I think this is about how to make TLVs be aligned. The TLV > alignment rules avoid the issue of Opaque LSAs whose payload is not a > multiple of 4. I'm concerned with the case when e.g. someone wants to > publish a 15-octet value as the Opaque LSA contents. The TLV length field would be 15 but the length of the TLV and it would be padded to a 4 octet boundary (1 byte of padding). > > -- > Greg Troxel From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 5 13:05:19 2004 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 NAA03690 for ; Fri, 5 Nov 2004 13:05:19 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00ED1638@cherry.ease.lsoft.com>; Fri, 5 Nov 2004 12:22:26 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43531282 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 5 Nov 2004 12:22:21 -0500 Received: from 63.118.34.24 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 5 Nov 2004 12:22:21 -0400 Received: from mdmail.ciena.com (HELO mdmxb01.ciena.com) (63.118.39.25) by ripley.ciena.com with ESMTP; 05 Nov 2004 12:36:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <8162DD929D7AD24CAD3FC5317CE41FB001140A74@w2kmaexg02.wavesmithnet.com> Date: Fri, 5 Nov 2004 12:22:11 -0500 Reply-To: Mailing List Sender: Mailing List From: "Shen, Yimin" Subject: Re: BDR election in a graceful restart To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Acee, Thanks! - Yimin -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Friday, November 05, 2004 12:16 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: BDR election in a graceful restart ----- Original Message ----- From: "Shen, Yimin" To: Sent: Friday, November 05, 2004 12:01 PM Subject: Re: BDR election in a graceful restart > Acee, > > Thanks! But theoretically if the helpers can maintain the restarting router's BDR status just like what they do for a restarting > DR, the impact of restart on the network would be minimized further. (When a DR is restarting, it also needs to re-establish all > the adjacencies, which is the same situation as BDR restarting.) Yimin, A router performing graceful restart as defined in RFC 3623 also has to reestablish its adjacencies. > > On the hand, as you point out, we do expect a BDR change during a BDR graceful restart. I think what will happen is that every > router will start to establish an adjacency with the new BDR, and so new router LSAs and network LSAs will be advertised. If all > this happens before the restarting router finishes the graceful restart, the helpers may exit helper mode because they would need > to install new LSAs in their databases (RFC3623 section 3.2 item 3)). Of course, this would depend on timing. Not exactly, according to RFC 2328 the BDR state doesn't impact router and network LSA originations. However, I believe there are implementations where the BDR state is reflected in the router and network LSAs. > > Regards, > > - Yimin > > > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Friday, November 05, 2004 11:37 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: BDR election in a graceful restart > > > ----- Original Message ----- > From: "Shen, Yimin" > To: > Sent: Friday, November 05, 2004 11:16 AM > Subject: BDR election in a graceful restart > > >> Hi, >> >> In RFC 3623 section 3 "Operation of Helper Neighbor", it says the following: >> >> "... if X was the Designated Router on network segment S when the helping relationship began, Y maintains X as the Designated >> Router until the helping relationship is terminated." >> However, it doesn't mention what should happen if X is a BDR. If a BDR is undergoing a graceful restart, is it expected that >> another router which has the highest priority among all routers (excluding the current DR) on the same network segment S to be >> elected as a new BDR ? >> > > Hi Yimin, > This is exactly what happens. Since the restarting router must reestablish an adjacency anyway > there is really no savings by preserving the BDR state across restarts. However, depending on > timing the restarting router may become BDR. > Hope this helps, > Acee > >> Thanks in advance. >> >> - Yimin Shen From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 5 13:15:09 2004 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 NAA04560 for ; Fri, 5 Nov 2004 13:15:08 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00ED17B8@cherry.ease.lsoft.com>; Fri, 5 Nov 2004 13:15:08 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43536144 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 5 Nov 2004 13:15:07 -0500 Received: from 192.1.100.210 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 5 Nov 2004 13:15:06 -0400 Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 974F62069; Fri, 5 Nov 2004 13:15:06 -0500 (EST) References: <20041104193106.99BA42332@fnord.ir.bbn.com> <001e01c4c356$71c4e770$0202a8c0@aceeinspiron> <006101c4c35b$c8820160$0202a8c0@aceeinspiron> Lines: 10 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: Date: Fri, 5 Nov 2004 13:15:06 -0500 Reply-To: Mailing List Sender: Mailing List From: Greg Troxel Subject: Re: alignment/padding rules for Opaque LSAs Comments: To: Acee Lindem Comments: cc: owner-ospf@peach.ease.lsoft.com To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <006101c4c35b$c8820160$0202a8c0@aceeinspiron> Precedence: list The TLV length field would be 15 but the length of the TLV and it would be padded to a 4 octet boundary (1 byte of padding). I'm talking about opaque LSA contents which are not TLVs - just arbitrary data, used for purposes other than the published standards that use TLVs. So the contents are truly opaque - no type field, and no length. -- Greg Troxel From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 5 13:55:20 2004 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 NAA03693 for ; Fri, 5 Nov 2004 13:05:19 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00ED15FA@cherry.ease.lsoft.com>; Fri, 5 Nov 2004 12:24:52 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43531493 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 5 Nov 2004 12:24:51 -0500 Received: from 128.96.41.1 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 5 Nov 2004 12:24:51 -0400 Received: from mailee (mailee [192.4.16.29]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id iA5HOocv015333 for ; Fri, 5 Nov 2004 12:24:50 -0500 (EST) X-X-Sender: narain@mailee References: <20041104193106.99BA42332@fnord.ir.bbn.com><001e01c4c356$71c4e770$0202a8c0@aceeinspiron> <006101c4c35b$c8820160$0202a8c0@aceeinspiron> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Message-ID: Date: Fri, 5 Nov 2004 12:24:50 -0500 Reply-To: Mailing List Sender: Mailing List From: Sanjai Narain Subject: Maximum number of OSPF processes on a router To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <006101c4c35b$c8820160$0202a8c0@aceeinspiron> Precedence: list Hi, can you please let me know what is the maximum number of separate OSPF processes that typical routers support? Thanks. -- Sanjai From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 5 13:57:55 2004 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 NAA07515 for ; Fri, 5 Nov 2004 13:57:55 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00ED168D@cherry.ease.lsoft.com>; Fri, 5 Nov 2004 13:57:54 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43540879 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 5 Nov 2004 13:57:53 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 5 Nov 2004 13:57:53 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 6B188984F47 for ; Fri, 5 Nov 2004 10:57: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 06944-08 for ; Fri, 5 Nov 2004 10:57:51 -0800 (PST) Received: from aceeinspiron (unknown [172.31.253.76]) by prattle.redback.com (Postfix) with SMTP id 49FF2984F42 for ; Fri, 5 Nov 2004 10:57:50 -0800 (PST) References: <20041104193106.99BA42332@fnord.ir.bbn.com> <001e01c4c356$71c4e770$0202a8c0@aceeinspiron> <006101c4c35b$c8820160$0202a8c0@aceeinspiron> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <00a201c4c369$54525200$0202a8c0@aceeinspiron> Date: Fri, 5 Nov 2004 13:57:41 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: alignment/padding rules for Opaque LSAs To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Greg Troxel" To: Sent: Friday, November 05, 2004 1:15 PM Subject: Re: alignment/padding rules for Opaque LSAs > The TLV length field would be 15 but the length of the TLV and it > would be padded to a 4 octet boundary (1 byte of padding). > > I'm talking about opaque LSA contents which are not TLVs - just > arbitrary data, used for purposes other than the published standards > that use TLVs. So the contents are truly opaque - no type field, and > no length. Greg, Ok - now I understand and the other implementations are correct. You need to pad the value to 32 bit alignment. From RFC 2370: A.2 The Opaque LSA Opaque LSAs are Type 9, 10 and 11 link-state advertisements. These advertisements may be used directly by OSPF or indirectly by some application wishing to distribute information throughout the OSPF domain. The function of the Opaque LSA option is to provide for future extensibility of OSPF. Opaque LSAs contain some number of octets (of application-specific data) padded to 32-bit alignment. Like any other LSA, the Opaque LSA uses the link-state database distribution mechanism for flooding this information throughout the topology. However, the Opaque LSA has a flooding scope associated with it so that the scope of flooding may be link-local (type 9), area-local (type 10) or the entire OSPF routing domain (type 11). Section 3 of this document describes the flooding procedures for the Opaque LSA. It doesn't say whether or not the length should include the padding. However, I'd say that it should and the application should be responsiblefor passing the real length (or somehow delimiting it). Hope this doesn't cause you too much pain,Acee Coltun Standards Track > > -- > Greg Troxel From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 5 14:11:11 2004 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 OAA08528 for ; Fri, 5 Nov 2004 14:11:11 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00ED183B@cherry.ease.lsoft.com>; Fri, 5 Nov 2004 14:11:11 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43542037 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 5 Nov 2004 14:11:10 -0500 Received: from 192.1.100.210 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 5 Nov 2004 14:11:10 -0400 Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id B55612069; Fri, 5 Nov 2004 14:11:09 -0500 (EST) References: <20041104193106.99BA42332@fnord.ir.bbn.com> <001e01c4c356$71c4e770$0202a8c0@aceeinspiron> <006101c4c35b$c8820160$0202a8c0@aceeinspiron> <00a201c4c369$54525200$0202a8c0@aceeinspiron> Lines: 38 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: Date: Fri, 5 Nov 2004 14:11:09 -0500 Reply-To: Mailing List Sender: Mailing List From: Greg Troxel Subject: Re: alignment/padding rules for Opaque LSAs Comments: To: Acee Lindem To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <00a201c4c369$54525200$0202a8c0@aceeinspiron> Precedence: list Opaque LSAs contain some number of octets (of application-specific data) padded to 32-bit alignment. Like any other LSA, the Opaque LSA It doesn't say whether or not the length should include the padding. However, I'd say that it should and the application should be responsible for passing the real length (or somehow delimiting it). So this is essentially saying (departing from wire format to on-machine API) that if a user says "publish this 15 octet value", then that should be either rejected as an error or converted into "publish 16 octects, the 15 given followed by a 0". This of course requires Opaque users to only use aligned structures (such as the TLV rules), or to be able to extract lengths (e.g., null terminated strings). This implies a rule that it is an error for a value that is not a multiple of 4 to ever appear on the wire in an LSA length field. The alternative is to allow odd lengths for payloads and in the length field, and require implementations to add and ignore padding when packing/unpacking LSAs into/from LS update packets. This is more flexible (since it allows representation of odd-length payloads), but more complicated and perhaps more likely to cause trouble with existing implementations. I would be interested to hear from other implementors - what does your implementation do when receiving a LS update packet with an Opaque LSA with length field 25 (indicating 20 header and 5 payload). Treat this a format error? Expect the next LSA to start 28 octets after the lenth-25 one? 25 octets later (quagga currently does this, and that's clearly wrong)? Do intra- or inter-process APIs permit odd-length payloads, or reject them? Regardless of the outcome, I'd say this is not clear from reading the specs and a clarification will be in order. -- Greg Troxel From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 5 14:38:48 2004 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 OAA10118 for ; Fri, 5 Nov 2004 14:38:48 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00ED17CC@cherry.ease.lsoft.com>; Fri, 5 Nov 2004 14:38:47 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43545437 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 5 Nov 2004 14:38:46 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 5 Nov 2004 14:38:46 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 3EF88BD1B17; Fri, 5 Nov 2004 11:38:45 -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 14494-01; Fri, 5 Nov 2004 11:38:45 -0800 (PST) Received: from aceeinspiron (unknown [172.31.253.76]) by prattle.redback.com (Postfix) with SMTP id F3534BD1B15; Fri, 5 Nov 2004 11:38:43 -0800 (PST) References: <20041104193106.99BA42332@fnord.ir.bbn.com><001e01c4c356$71c4e770$0202a8c0@aceeinspiron><006101c4c35b$c8820160$0202a8c0@aceeinspiron><00a201c4c369$54525200$0202a8c0@aceeinspiron> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <00b801c4c36f$0b13f520$0202a8c0@aceeinspiron> Date: Fri, 5 Nov 2004 14:38:35 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: alignment/padding rules for Opaque LSAs Comments: To: Greg Troxel To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Greg Troxel" To: "Acee Lindem" Cc: "Mailing List" Sent: Friday, November 05, 2004 2:11 PM Subject: Re: alignment/padding rules for Opaque LSAs > Opaque LSAs contain some number of octets (of application-specific > data) padded to 32-bit alignment. Like any other LSA, the Opaque LSA > > It doesn't say whether or not the length should include the padding. > However, I'd say that it should and the application should be > responsible for passing the real length (or somehow delimiting it). > > So this is essentially saying (departing from wire format to > on-machine API) that if a user says "publish this 15 octet value", > then that should be either rejected as an error or converted into > "publish 16 octects, the 15 given followed by a 0". This of course > requires Opaque users to only use aligned structures (such as the TLV > rules), or to be able to extract lengths (e.g., null terminated > strings). This implies a rule that it is an error for a value that is > not a multiple of 4 to ever appear on the wire in an LSA length field. > > The alternative is to allow odd lengths for payloads and in the length > field, and require implementations to add and ignore padding when > packing/unpacking LSAs into/from LS update packets. This is more > flexible (since it allows representation of odd-length payloads), but > more complicated and perhaps more likely to cause trouble with > existing implementations. Greg, While it would have been clearer if the length rules had been stated explicitly here is my rationale for saying that the LSA length MUST include the padding. RFC 2328 doesn't deal with this issue since all the described LSAs are 32 bit aligned. RFC 2370 describes all the changes necessary to support opaque LSAs. Hence, the absence of a section describing the handling of alignment issues implies that the length must include both the opaque value and padding. This is also in the true spirit of opaqueness. > I would be interested to hear from other implementors - what does your > implementation do when receiving a LS update packet with an Opaque LSA > with length field 25 (indicating 20 header and 5 payload). Treat this > a format error? Expect the next LSA to start 28 octets after the > lenth-25 one? 25 octets later (quagga currently does this, and that's > clearly wrong)? > > Do intra- or inter-process APIs permit odd-length payloads, or reject > them? > > Regardless of the outcome, I'd say this is not clear from reading the > specs and a clarification will be in order. > > -- > Greg Troxel From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 8 15:29:52 2004 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 PAA26410 for ; Mon, 8 Nov 2004 15:29:52 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00ED580D@cherry.ease.lsoft.com>; Mon, 8 Nov 2004 15:29:52 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43921706 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 8 Nov 2004 15:29:51 -0500 Received: from 69.25.242.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 8 Nov 2004 15:29:51 -0400 Received: from CallSciences (unverified [172.21.6.76]) by ucmmail.com (Rockliffe SMTPRA 5.3.11) with SMTP id ; Mon, 8 Nov 2004 15:30:38 -0500 Content-Type: text/plain; charset=US-ASCII; format=flowed Message-ID: Date: Mon, 8 Nov 2004 15:29:27 -0500 Reply-To: Mailing List Sender: Mailing List From: Sean Andersen Subject: Re: Maximum number of OSPF processes on a router To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Sanjai, A better way to get an answer to your question is to pick a brand of router and then ask the manufacturer directly. Sean -----Original Message----- From: Sanjai Narain Sent: Fri, 5 Nov 2004 12:24:50 -0500 To: OSPF@PEACH.EASE.LSOFT.COM Subject: Maximum number of OSPF processes on a router Hi, can you please let me know what is the maximum number of separate OSPF processes that typical routers support? Thanks. -- Sanjai From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 9 10:59:56 2004 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 KAA12842 for ; Tue, 9 Nov 2004 10:59:56 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00ED6B53@cherry.ease.lsoft.com>; Tue, 9 Nov 2004 10:59:55 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44069504 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 9 Nov 2004 10:59:54 -0500 Received: from 147.234.1.11 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 9 Nov 2004 10:59:54 -0400 X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 X-MIMETrack: Serialize by Router on ILSMTP01/ECI Telecom(Release 6.5.1|January 21, 2004) at 11/09/2004 18:03:49 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Message-ID: Date: Tue, 9 Nov 2004 17:59:51 +0200 Reply-To: Mailing List Sender: Mailing List From: Ilan Bercovich Subject: Virtual interface uses and alternatives To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi Sorry for the illiterately question, but: Is the virtual interface option required only at setup phase? Or is it for normal use? Is there an alternate way to cross a non-backbone area? Thanks, Ilan From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 10 12:42:29 2004 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 MAA04976 for ; Wed, 10 Nov 2004 12:42:29 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00ED8981@cherry.ease.lsoft.com>; Wed, 10 Nov 2004 12:42:30 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44287313 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 10 Nov 2004 12:42:29 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 10 Nov 2004 12:42:29 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id F1EC7419598 for ; Wed, 10 Nov 2004 09:42: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 15656-07 for ; Wed, 10 Nov 2004 09:42:27 -0800 (PST) Received: from aceeinspiron (unknown [172.31.253.64]) by prattle.redback.com (Postfix) with SMTP id 279B141959A for ; Wed, 10 Nov 2004 09:42:26 -0800 (PST) References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <00ee01c4c74c$a347f360$0302a8c0@aceeinspiron> Date: Wed, 10 Nov 2004 12:42:23 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Virtual interface uses and alternatives To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Ilan Bercovich" To: Sent: Tuesday, November 09, 2004 10:59 AM Subject: Virtual interface uses and alternatives > Hi > > Sorry for the illiterately question, but: > Is the virtual interface option required only at setup phase? Or is it for > normal use? OSPF requires the virtual link to be maintained to assure the transit capability of the area. > Is there an alternate way to cross a non-backbone area? You could tunnel between ABRs. draft-mirtorabi-ospf-tunnel-adjacency-02.txt describes one way to do this. > > Thanks, > Ilan From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 12 14:36:33 2004 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 OAA05074 for ; Fri, 12 Nov 2004 14:36:32 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00EDC0E8@cherry.ease.lsoft.com>; Fri, 12 Nov 2004 14:36:24 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44658596 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 12 Nov 2004 14:36:22 -0500 Received: from 212.17.55.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 12 Nov 2004 14:36:16 -0400 Received: from hibernia.jakma.org (IDENT:paul@hibernia.jakma.org [192.168.0.3]) by hibernia.jakma.org (8.12.11/8.12.11) with ESMTP id iACJZi7C007266; Fri, 12 Nov 2004 19:35:45 GMT X-X-Sender: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.jakma.org X-NSA: arafat al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Message-ID: Date: Fri, 12 Nov 2004 19:35:43 +0000 Reply-To: Mailing List Sender: Mailing List From: Paul Jakma Subject: OSPF alignment Comments: cc: Greg Troxel To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi, I'm wondering what the criteria are for alignment in OSPF structures? RFC2328 appears careful to maintain 4byte alignment, however doesnt exactly specify this is required, no alignment restrictions appear to placed on length fields. However, the packet and auth (though not LSA) checksum definitions do mention that a pad byte should be appended if the packet is not 2byte aligned. So the question is: - may LSA packets be of arbitrary byte lengths? (appears so, though existing RFCs seem careful to ensure packets would always be aligned to 2 bytes, possibly even 4, and padding procedure is defined for 2 of the checksums) if so: - Is it permitted to zero pad packets to align them if required? (and should the packet length include the pad bytes? I presume so) - may LSAs be of arbitrary byte lengths? (appears so, eg Opaque LSA RFC is careful to specify that opaque LSAs must be padded to alignment.) If so: same question as for packet length: can LSA be padded (and should LSA length include padding)? We're trying to figure out whether it is possible to simply check for unaligned LSAs in packets, and drop the packet (ie that unaligned LSAs within LSA Update or whatever packets would never occur), or whether we must accept a performance hit and assume that LSAs (or other data) within packets can be located at arbitrary byte boundaries, and fix up as needs be. Thanks in advance.. PS: It would possibly be useful to have an I-D on the issue of alignment within OSPF. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Be a better psychiatrist and the world will beat a psychopath to your door. From owner-ospf@PEACH.EASE.LSOFT.COM Sun Nov 14 21:04:21 2004 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 VAA00667 for ; Sun, 14 Nov 2004 21:04:20 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00EDEE9D@cherry.ease.lsoft.com>; 14 Nov 2004 21:04:17 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44968313 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 14 Nov 2004 21:04:16 -0500 Received: from 212.17.55.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 14 Nov 2004 21:04:15 -0400 Received: from hibernia.jakma.org (IDENT:paul@hibernia.jakma.org [192.168.0.3]) by hibernia.jakma.org (8.12.11/8.12.11) with ESMTP id iAF248pX005669 for ; Mon, 15 Nov 2004 02:04:14 GMT X-X-Sender: paul@hibernia.jakma.org References: Mail-Followup-To: paul@hibernia.jakma.org X-NSA: arafat al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Message-ID: Date: Mon, 15 Nov 2004 02:04:06 +0000 Reply-To: Mailing List Sender: Mailing List From: Paul Jakma Subject: Re: OSPF alignment To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list On Fri, 12 Nov 2004, Paul Jakma wrote: > Hi, > > I'm wondering what the criteria are for alignment in OSPF structures? Apologies, looks like a co-maintainer of Quagga had beaten me to asking the list. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: "The way of the world is to praise dead saints and prosecute live ones." -- Nathaniel Howe From owner-ospf@PEACH.EASE.LSOFT.COM Sun Nov 14 21:15:08 2004 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 VAA01137 for ; Sun, 14 Nov 2004 21:15:08 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00EDEEA4@cherry.ease.lsoft.com>; 14 Nov 2004 21:15:06 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44968885 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 14 Nov 2004 21:14:59 -0500 Received: from 212.17.55.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 14 Nov 2004 21:14:58 -0400 Received: from hibernia.jakma.org (IDENT:paul@hibernia.jakma.org [192.168.0.3]) by hibernia.jakma.org (8.12.11/8.12.11) with ESMTP id iAF2EJpd005742; Mon, 15 Nov 2004 02:14:20 GMT X-X-Sender: paul@hibernia.jakma.org References: <20041104193106.99BA42332@fnord.ir.bbn.com> <001e01c4c356$71c4e770$0202a8c0@aceeinspiron> Mail-Followup-To: paul@hibernia.jakma.org X-NSA: arafat al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Message-ID: Date: Mon, 15 Nov 2004 02:14:19 +0000 Reply-To: Mailing List Sender: Mailing List From: Paul Jakma Subject: Re: alignment/padding rules for Opaque LSAs Comments: To: Acee Lindem Comments: cc: Greg Troxel To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <001e01c4c356$71c4e770$0202a8c0@aceeinspiron> Precedence: list Hi Acee, On Fri, 5 Nov 2004, Acee Lindem wrote: > The Length field defines the length of the value portion in octets > (thus a TLV with no value portion would have a length of zero). The > TLV is padded to four-octet alignment; padding is not included in the > length field (so a three octet value would have a length of three, > but the total size of the TLV would be eight octets). Nested TLVs > are also 32-bit aligned. Unrecognized types are ignored. > > So far, this description has been sufficient for interoperable > implementations. However, we have had some confusion with > individual TLVs and whether trailing 0's are part of the value (and > included in the length) or padding (and not included). What about standard LSAs? Ie RFC2328? It is very careful to specify structures that always result in 4byte aligned packets (to my memory at least), however alignment is not mentioned at all (except for checksums). In order to ensure our ospf implementation is robust can we assume some kind of minimum alignment? For 2328 defined structures we can in practice, however as it leaves the door open for other RFCs to potentially define unaligned structures... (though none that i am aware of do..). Also, is it safe to assume that the OSPF packet length and the LSA header length fields will always include any padding that may have been included? (I'd presume so.. it would be a "layering" violation of sorts if it did not). Might it be an idea to issue some kind of document to clarify alignment issues and (possibly) mandate that any future additions to OSPF always ensure that LSAs be aligned to some minimum boundary? > Hope this helps, > Acee regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: I hold it, that a little rebellion, now and then, is a good thing... -- Thomas Jefferson From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 15 08:02:15 2004 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 IAA22243 for ; Mon, 15 Nov 2004 08:02:14 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00EDFA61@cherry.ease.lsoft.com>; Mon, 15 Nov 2004 8:02:13 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45061397 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 15 Nov 2004 08:02:12 -0500 Received: from 64.233.184.197 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 15 Nov 2004 08:02:12 -0400 Received: by wproxy.gmail.com with SMTP id 68so287245wra for ; Mon, 15 Nov 2004 05:02:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=jhTG220WRaYQA3XHTVteVlbirO786wsWUDZtSTxkT4Az/609gBimXGGmeCN7LjQwCX9rt2L+f+riVczKnEwctdsPWGAojH+lSKPTiY49/NnGwpsBbclP9l7Rrak9nnS7qFYlvy1j73a8E9cj0CL1RVt4TmJZjcDIDbiU/CYpvnM= Received: by 10.54.25.5 with SMTP id 5mr24964wry; Mon, 15 Nov 2004 05:02:12 -0800 (PST) Received: by 10.54.46.10 with HTTP; Mon, 15 Nov 2004 05:02:12 -0800 (PST) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID: <60fc97be041115050276c794ef@mail.gmail.com> Date: Mon, 15 Nov 2004 18:32:12 +0530 Reply-To: Mailing List Sender: Mailing List From: Sanjay BM Subject: Graceful restart helper question To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi, Please see the following lines from the graceful restart rfc. =-=-=-=-=-=-=-=- RFC3623 Section 3.1 "Entering Helper Mode" Page 8: If Y was already helping X on the associated network segment, the new grace-LSA should be accepted and the grace period should be updated accordingly. =-=-=-=-=-=-=-=- I had few questions relating to these lines. 1. Why should a helper accept new grace LSAs? 2. Should the helper reset its grace-period timer to the grace-period value received in this new grace LSA? 3. What should happen if the local policy on the helper had accepted the grace-period value of the earlier received grace LSA and hence entered helper mode, but now the policy rejects the grace-period value set in the new grace LSA? Should the behavior in this case be implementation specific? The policies could reject other parameters for that matter, ex: grace-restart-reason. Kindly let me know. Thanx, Sanjay From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 17 11:04:36 2004 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 LAA12156 for ; Wed, 17 Nov 2004 11:04:35 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00EE3329@cherry.ease.lsoft.com>; Wed, 17 Nov 2004 11:04:36 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45424440 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 17 Nov 2004 11:04:34 -0500 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 17 Nov 2004 10:54:34 -0400 Received: from PEACH.EASE.LSOFT.COM (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00EE30E7@cherry.ease.lsoft.com>; Wed, 17 Nov 2004 10:54:32 -0500 Message-ID: Date: Wed, 17 Nov 2004 10:54:31 -0500 Reply-To: Mailing List Sender: Mailing List From: Razvan Bruma Subject: SeqNumberMismatch problem To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hello all, I have two cisco 2611 routers connected via a wireless ethernet link. Every hour (more or less) one SeqNumberMismatch is recorded into the logging buffer, with all the consequences: back to EXCHANGE, bring up the backup line, etc. I know (theoretically) what causes this event. Any ideas on what (practically) can happen? What errors of transmission or otherwise can produce the mismatch ? Thanks Razvan From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 17 21:55:25 2004 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 VAA19378 for ; Wed, 17 Nov 2004 21:55:25 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00EE40A2@cherry.ease.lsoft.com>; Wed, 17 Nov 2004 21:55:25 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45491290 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 17 Nov 2004 21:55:24 -0500 Received: from 63.113.148.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 17 Nov 2004 21:55:24 -0400 Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id SAA12871; Wed, 17 Nov 2004 18:55:23 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: SeqNumberMismatch problem Thread-Index: AcTMvyh3m+GrUcrmQq2oVQRH3iLjVwAWe2xm Message-ID: <7549C475A1F3CF47ABCA660BF44738B3EFF7B5@legolas.rs.riverstonenet.com> Date: Wed, 17 Nov 2004 18:55:23 -0800 Reply-To: Mailing List Sender: Mailing List From: "Mollin, Arvind - LiqwidKrystal" Subject: Re: SeqNumberMismatch problem To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable IMHO, One of the reason may be MTU size mismatch. Pls check that you = have configured same MTU size on the both interfaces. Second thing may be that one of the router is missing hellos ( say = router with lesser routerid misses the hello), but the router which is = having higher routerid recieves hellos and assumes that the peer is = okay. Then the router with lesser id tries to go on adjacency after = recieving a hello, that time it sends itself as master, due to this = router with higher routerid throws seq mismatch. =20 Quick Check : See that both routers are always on FULL state .. =20 Arvind ________________________________ From: Mailing List on behalf of Razvan Bruma Sent: Wed 11/17/2004 7:54 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: SeqNumberMismatch problem Hello all, I have two cisco 2611 routers connected via a wireless ethernet link. = Every hour (more or less) one SeqNumberMismatch is recorded into the logging buffer, with all the consequences: back to EXCHANGE, bring up the backup line, etc. I know (theoretically) what causes this event. Any ideas on what (practically) can happen? What errors of transmission or otherwise can produce the mismatch ? Thanks Razvan From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 17 22:28:45 2004 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 WAA20984 for ; Wed, 17 Nov 2004 22:28:45 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00EE411D@cherry.ease.lsoft.com>; Wed, 17 Nov 2004 22:28:46 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45492680 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 17 Nov 2004 22:28:45 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 17 Nov 2004 22:18:45 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 17 Nov 2004 22:24:47 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAI3IfWf021631 for ; Wed, 17 Nov 2004 22:18:42 -0500 (EST) Received: from [128.107.177.103] (dhcp-128-107-177-103.cisco.com [128.107.177.103]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BDL67912; Wed, 17 Nov 2004 19:18:41 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------080008010902000008050508" Message-ID: <419C1491.9060608@cisco.com> Date: Wed, 17 Nov 2004 22:18:41 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Minutes from OSPF WG Meeting in Washington, DC To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. --------------080008010902000008050508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thanks to Richard Rabbat for taking the detailed minutes. Acee --------------080008010902000008050508 Content-Type: text/plain; name="ospf-minutes.txt" Content-Disposition: inline; filename="ospf-minutes.txt" Content-Transfer-Encoding: 8bit Minutes for Open Shortest Path First WG (ospf) Monday, November 8 at 1300-1500 SCRIBE: Richard Rabbat CHAIRS: Rohit Dube Acee Lindem o Document Status 10 minutes (Rohit) - 1 rfc published - 3 to be published soon: OSPF DN Bit, Graceful Restart Implementation Report,Flooding Optimization in stable environments - Scalability draft had couple of comments by IESG to be addressed by authors - In AD evaluation: OSPF v2 mib and multi-area adjacency Bill Fenner: OSPFv2 MIB Went through review, looks like has to go to professional MIB reviewer for extra review Multi-area adjacency: many solutions, WG decided to published simplest of them. No implementations yet. - Close to last call: * Extensions to OSPF for advertising optional router cap * Advertising a router’s local addresses in OSPF TE extensions * Authentication/confidentiality for OSPFvd - WG discussion: * OSPFv3 MIB * TE extensions to OSPF v3 * Support of address families in OSPFv3 - New WG documents: * MT-OSPF: Multi-Topology (MT) routing in OSPF Discussed in San Diego: no dissention Two MT proposals: one for v2 Semantics are different The OSPFv3 multi-topology from an OSPF perspective seems radical. o RFC 2740 Respin 10 minutes (Acee) - OSPF v2 RFC has gone through several iterations. We’re now at 2328. - OSPF v3 has not had an update - Goals: * Fix errata that have accumulated * Ambiguities * Include omissions including features that lack specification * Bugs in protocol * Deprecate unused features * Acknowledge correction contributors - Went through some errata: * Section 3.4.3.7: intra-area-prefix * Appendix: LSA field sizes wrong - Ambiguities: * Interface instance ID * Forwarding addresses and link locals - Include omissions: * NSSA additions * Input/output processing additions from Nic Neate * SPF calculation handling of LSAs with v6 - Protocol bugs: * Fix to mitigate the effects of DoS attack using Max Sequence LSAs with high checksum because the checksum in the order above the age (hard to purge) applies equally to v2 and v3 - Deprecate: * OSPF external attributes LSA * Reference to site local addresses * MOSPF: Probably will leave it in in case it makes a resurgence - No questions o OSPFv3 MTR 15 minutes (Sina Mirtorabi) draft-mirtorabi-mt-ospfv3-00.txt Abhay Roy/Sina Mirtorabi - Last IETF meeting: v2; This IETF: v3 - MTR v3 goal * Define multiple independent topology within a physical topology - Potential solutions * Instance ID approach * Use integrated approach with existing LSAs: problems - Proposed solution * Define new LSAs to carry MT information * Ignored by legacy OSPFv3 routers * New use TLVs for extendibility in extended LSAs * MT-ID field: 8 bit field present in LSA * MT routing operations: - Single adjacency formed even if the link participates in multiple topologies. * v3 control packets.. * Default topology * Topology that is built using the exiting LSAs as specified in v3 * Defined 2740 compatibililty… * NEW LSAs - New lsa payload are TLV based - tlv may contain sub-TLVs - Extended router LSA has link description TLV - Other extended LSAs are similar with TLVs - If all routers are MT capable, only extended LSAs are used for the default topology * Asked to be WG document - Discussion Acee: once you accept new TLV, you may need to accept unknown TLVs as well. Urged everybody to read this and try to do something about ordering of TLVs to add a little more structure than ISIS Sina: Agreed Alex: Not entirely new to OSPFv3. Meed to accept unknown LSA’s so it’s already there Himanshu (Ciena): Not following motivation. If you get data packet on a single link, how do you distinguish the MT? Sina: Neither MT-ISIS, v2 or v3 have considered forwarding aspect. It all depends on how you color packet. In those drafts, we’re only looking at control plane Alex: Had a discussion with ISIS guys. There are considerations in the draft. We need to have a document one way of doing this in interoperable fashion. We can take it to routing WG. From the aspect of interop, need to have a single way to demultiplex packets in the case a link belongs to multiple MTs o OSPF Wireless Design Team Status (Tom Henderson) - Met in San Diego and discussions continuing since - Agreed on problem statement - Several initial agreements on work scope - Summarize current technical discussions - Next steps - DT chartered to produce initial set of v3 extensions for wireless (motivated by draft-baker-manet-ospf-problem-statement) Some extensions would become wg documents and reviewed by MANET and OSPF WG - Problem statement: * Focus on v3 * Compatibility with non-wireless v3 * Intra-area extensions only * Not focusing on transit network case but not precluded * Scaling goal to 50-100 nodes in wireless channel * Leverage existing MANET work where possible * Use RFC3668 guidance in dealing with IPR claims - Consensus reached so far: * Agreed to define new MANET interface type rather than a MANET area type (parallel with existing OSPF interface types) * Focusing on designing an optimized flooding mechanism for new LSA generation * Using acknowledge (reliable) flooding * Unacknowledged periodic flooding future extension * Hybrid operation also a future possibility - Optimizing flooding behavior in broadcast wireless network * Reduced # of xmissions to reliably disseminate LSAs * Robustness * Must make sense within ospf framework-minimize change to ospf * Trying to leverage previous work: source-dependent vs. source-independent relay node sets (connected dominating sets in the literature). Considering tradeoffs Joe Macker: MANET WG chair: nNot necessarily dependent on who sent it but the previous hop Acee: Example of source-independent is if you try to create shortest spanning tree for the whole domain. - Simulation evaluation of flooding alternatives * In the process of releasing simulation environment for the team * Consider whether to define additional wireless optimizations (proposals to make hello message to be differential, to optimize database exchange procedure) or to send them to next work * Target draft submission to March IETF * Simulation results will be made available Alex: Question about unreliable flooding. Wanted the solutions to be in the framework of OSPF design. Tom: Having an un-acked mode of operation may be approximate reliable flooding. Alex: Still need to change OSPF mechanism and flooding paridigm. Tom: There have been proposal to change timers Alex: Is the end-result unreliable flooding mechanism? Tom: It would still be reliable with backoff of retransmit timer Alex: Maybe that should be kept in MANET WG. Tom: DT has decided to work on reliable flooding at this time. Rohit: To summarize, flooding is now kept as reliable as OSPF Acee: Work is moving along. As a consequence of no proposals for OSPFv2 wireless, we’ll continue with this on top of OSPFv3. It seems that this is the protocol that vendors want in OSPF WG. --------------080008010902000008050508-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 18 00:15:40 2004 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 AAA29503 for ; Thu, 18 Nov 2004 00:15:39 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00EE4554@cherry.ease.lsoft.com>; Thu, 18 Nov 2004 0:15:41 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45503728 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 18 Nov 2004 00:15:40 -0500 Received: from 207.217.121.252 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 18 Nov 2004 00:15:39 -0400 Received: from user-2ivfmgh.dialup.mindspring.com ([165.247.218.17] helo=earthlink.net) by pop-a065d14.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1CUedt-0002fz-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 17 Nov 2004 21:15:38 -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: <7549C475A1F3CF47ABCA660BF44738B3EFF7B5@legolas.rs.riverstonenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <419C2C69.DF5299F@earthlink.net> Date: Wed, 17 Nov 2004 21:00:25 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: SeqNumberMismatch problem To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, First are you implimenting the MANET extensions??? What is the key to 1 hour? Are you doing something verifying that the link is up every hour via the RFC1793 Demand Circuit, DNA LSAs, and probing? Wireless ethernet... Is it possible that multiple nbr hellos are being sent basicly the same time? Are they becoming synchronized? Do you send out your first hellos when you see a hello pkt to get to 2-way quickly? What happens if two nbrs send hellos at the same time in your implimentation? Other than the above, I vote for the 2nd... Only a reseting of the adj would force repeated initial database syncs. A MTU size mismatch would not force the adj to reset. It would prevent a FULL adj from forming in the first place during the initial database exchange or hang depending on the config params. So, either a large number of hellos are being dropped which is unlikely, because 1 should get thru in router dead interval timeframe OR a hello is being sent that removes a nbr that WAS Fully adjacent. This is more than likely reseting the adj. Either way check the hellos router dead interval timeframe prior to the EXCHANGE state. Mitchell Erblich ------------------------ However, if a hello was sent "Mollin, Arvind - LiqwidKrystal" wrote: > > IMHO, One of the reason may be MTU size mismatch. Pls check that you have configured same MTU size on the both interfaces. > Second thing may be that one of the router is missing hellos ( say router with lesser routerid misses the hello), but the router which is having higher routerid recieves hellos and assumes that the peer is okay. Then the router with lesser id tries to go on adjacency after recieving a hello, that time it sends itself as master, due to this router with higher routerid throws seq mismatch. > > Quick Check : See that both routers are always on FULL state .. > > Arvind > > ________________________________ > > From: Mailing List on behalf of Razvan Bruma > Sent: Wed 11/17/2004 7:54 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: SeqNumberMismatch problem > > Hello all, > > I have two cisco 2611 routers connected via a wireless ethernet link. Every > hour (more or less) one SeqNumberMismatch is recorded into the logging > buffer, with all the consequences: back to EXCHANGE, bring up the backup > line, etc. > > I know (theoretically) what causes this event. Any ideas on what > (practically) can happen? What errors of transmission or otherwise can > produce the mismatch ? > > Thanks > > Razvan From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 18 00:32:41 2004 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 AAA00387 for ; Thu, 18 Nov 2004 00:32:41 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00EE4646@cherry.ease.lsoft.com>; Thu, 18 Nov 2004 0:32:43 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45505594 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 18 Nov 2004 00:32:42 -0500 Received: from 61.144.161.53 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 18 Nov 2004 00:32:41 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I7D009AG0GN3H@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 18 Nov 2004 13:26:47 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar3 2004)) with ESMTP id <0I7D00AFB0GNXT@szxga01-in.huawei.com> forOSPF@PEACH.EASE.LSOFT.COM; Thu, 18 Nov 2004 13:26:47 +0800 (CST) Received: from dell60 ([10.18.4.207]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar3 2004)) with ESMTPA id <0I7D00EDX0L82X@szxml01-in.huawei.com> forOSPF@PEACH.EASE.LSOFT.COM; Thu, 18 Nov 2004 13:29:33 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: multipart/alternative; boundary="Boundary_(ID_arNazRbhIX41VqnjuNNBgg)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-imss-version: 2.007 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com Message-ID: <000001c4cd30$3b350030$cf04120a@in.huawei.com> Date: Thu, 18 Nov 2004 11:04:09 +0530 Reply-To: Mailing List Sender: Mailing List From: sujay Subject: subscribe To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. --Boundary_(ID_arNazRbhIX41VqnjuNNBgg) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT ExCeed sujay huawei technologies india pvt ltd. 3rd floor Leela Galleria, Leela Palace, Bangalore sujayg@huawei.com Signature powered by Plaxo Want a signature like this? Add me to your address book... --Boundary_(ID_arNazRbhIX41VqnjuNNBgg) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT Message
 
 
ExCeed
sujay huawei technologies india pvt ltd.
3rd floor Leela Galleria,
Leela Palace,
Bangalore
sujayg@huawei.com
 
 
Signature powered by Plaxo Want a signature like this?
Add me to your address book...
 
--Boundary_(ID_arNazRbhIX41VqnjuNNBgg)-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 18 06:53:22 2004 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 GAA16612 for ; Thu, 18 Nov 2004 06:53:21 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00EE4AE8@cherry.ease.lsoft.com>; Thu, 18 Nov 2004 6:53:23 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45565118 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 18 Nov 2004 06:53:08 -0500 Received: from 217.156.78.145 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 18 Nov 2004 06:53:08 -0400 Received: from RAZVAN (razvan-wk [10.10.10.21]) by razvan.rartel.ro (Postfix) with SMTP id 47F3718D8CB for ; Thu, 18 Nov 2004 13:53:06 +0200 (EET) References: <7549C475A1F3CF47ABCA660BF44738B3EFF7B5@legolas.rs.riverstonenet.com> <419C2C69.DF5299F@earthlink.net> 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.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Message-ID: <0f2b01c4cd65$3d644930$150a0a0a@RAZVAN> Date: Thu, 18 Nov 2004 13:53:37 +0200 Reply-To: Mailing List Sender: Mailing List From: Razvan Bruma Subject: Re: SeqNumberMismatch problem To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hello, 1. No, I am not implementing any MANET extensions, I'm not sure even if the router supports them. The link is mainly a wireless bridge between the two routers. 2. There's no key to 1 hour. The link comes down for no apparent reason every (roughly) one hour, but this is not a definitive rule. It happens that everything is ok for 6 hours, let's say, and then I got ten SeqNumberMismatches in the following 30 minutes. From what I can see from the various debug outputs that I could get, something like this happens: a. Normal hellos are received every 10 sec: *Mar 4 13:00:50.289: OSPF: rcv. v:2 t:1 l:48 rid:172.16.1.129 aid:0.0.0.0 chk:7EC6 aut:0 auk: from Ethernet0/1 *Mar 4 13:01:00.289: OSPF: rcv. v:2 t:1 l:48 rid:172.16.1.129 aid:0.0.0.0 chk:7EC6 aut:0 auk: from Ethernet0/1 *Mar 4 13:01:10.289: OSPF: rcv. v:2 t:1 l:48 rid:172.16.1.129 aid:0.0.0.0 chk:7EC6 aut:0 auk: from Ethernet0/1 b. Suddenly I have a DD packet that resets the whole damn thing: *Mar 4 13:01:15.173: OSPF: rcv. v:2 t:2 l:32 rid:172.16.1.129 aid:0.0.0.0 chk:EA06 aut:0 auk: from Ethernet0/1 *Mar 4 13:01:15.173: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.1.129 on Ethernet0/1 from FULL to EXSTART, SeqNumberMismatch *Mar 4 13:01:15.185: OSPF: rcv. v:2 t:2 l:1432 rid:172.16.1.129 aid:0.0.0.0 chk:8DFF aut:0 auk: from Ethernet0/1 *Mar 4 13:01:15.185: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.1.129 on Ethernet0/1 from EXSTART to EXCHANGE, Negotiation Done *Mar 4 13:01:15.201: OSPF: rcv. v:2 t:2 l:32 rid:172.16.1.129 aid:0.0.0.0 chk:783 aut:0 auk: from Ethernet0/1 *Mar 4 13:01:15.205: OSPF: rcv. v:2 t:2 l:32 rid:172.16.1.129 aid:0.0.0.0 chk:782 aut:0 auk: from Ethernet0/1 *Mar 4 13:01:15.209: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.1.129 on Ethernet0/1 from EXCHANGE to LOADING, Exchange Done *Mar 4 13:01:15.209: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.1.129 on Ethernet0/1 from LOADING to FULL, Loading Done c. Then the process continues normally, until the next DD packet will cause an error: *Mar 4 13:01:20.290: OSPF: rcv. v:2 t:1 l:48 rid:172.16.1.129 aid:0.0.0.0 chk:7EC6 aut:0 auk: from Ethernet0/1 *Mar 4 13:01:30.287: OSPF: rcv. v:2 t:1 l:48 rid:172.16.1.129 aid:0.0.0.0 chk:7EC6 aut:0 auk: from Ethernet0/1 I cannot use a protocol analyzer to see the exact content of each packet and determine where is the mismatch, because I am in a remote location and I have to figure out what's happening from here. There is no MTU mismatch and the neighbors (there's only one neighbor, actually) are always in FULL. The loading is minimal. Do I miss anything? Razvan ----- Original Message ----- From: "Erblichs" To: Sent: Thursday, November 18, 2004 7:00 AM Subject: Re: SeqNumberMismatch problem > Group, > > First are you implimenting the MANET extensions??? > > What is the key to 1 hour? Are you doing something > verifying that the link is up every hour via the > RFC1793 Demand Circuit, DNA LSAs, and probing? > > Wireless ethernet... Is it possible that multiple > nbr hellos are being sent basicly the same time? > Are they becoming synchronized? Do you send out > your first hellos when you see a hello pkt to get > to 2-way quickly? What happens if two nbrs send > hellos at the same time in your implimentation? > > Other than the above, I vote for the 2nd... > > Only a reseting of the adj would force repeated > initial database syncs. > > A MTU size mismatch would not force the adj to > reset. It would prevent a FULL adj from forming > in the first place during the initial database > exchange or hang depending on the config params. > > So, either a large number of hellos are being dropped > which is unlikely, because 1 should get thru in router > dead interval timeframe OR a hello is being sent that > removes a nbr that WAS Fully adjacent. This is more than > likely reseting the adj. > > Either way check the hellos router dead interval > timeframe prior to the EXCHANGE state. > > Mitchell Erblich > ------------------------ > > > > However, if a hello was sent > > "Mollin, Arvind - LiqwidKrystal" wrote: > > > > IMHO, One of the reason may be MTU size mismatch. Pls check that you have configured same MTU size on the both interfaces. > > Second thing may be that one of the router is missing hellos ( say router with lesser routerid misses the hello), but the router which is having higher routerid recieves hellos and assumes that the peer is okay. Then the router with lesser id tries to go on adjacency after recieving a hello, that time it sends itself as master, due to this router with higher routerid throws seq mismatch. > > > > Quick Check : See that both routers are always on FULL state .. > > > > Arvind > > > > ________________________________ > > > > From: Mailing List on behalf of Razvan Bruma > > Sent: Wed 11/17/2004 7:54 AM > > To: OSPF@PEACH.EASE.LSOFT.COM > > Subject: SeqNumberMismatch problem > > > > Hello all, > > > > I have two cisco 2611 routers connected via a wireless ethernet link. Every > > hour (more or less) one SeqNumberMismatch is recorded into the logging > > buffer, with all the consequences: back to EXCHANGE, bring up the backup > > line, etc. > > > > I know (theoretically) what causes this event. Any ideas on what > > (practically) can happen? What errors of transmission or otherwise can > > produce the mismatch ? > > > > Thanks > > > > Razvan > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 18 07:40:12 2004 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 HAA20088 for ; Thu, 18 Nov 2004 07:40:11 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00EE4DAC@cherry.ease.lsoft.com>; Thu, 18 Nov 2004 7:40:04 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45570135 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 18 Nov 2004 07:39:52 -0500 Received: from 63.113.148.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 18 Nov 2004 07:39:52 -0400 Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id EAA27783; Thu, 18 Nov 2004 04:39:51 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 MIME-Version: 1.0 X-MS-TNEF-Correlator: <7549C475A1F3CF47ABCA660BF44738B3EFF7C6@legolas.rs.riverstonenet.com> Thread-Topic: SeqNumberMismatch problem Thread-Index: AcTNZTfQHEyQ4EXkTbGg/ECca/ZK9wABleFG Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <7549C475A1F3CF47ABCA660BF44738B3EFF7C6@legolas.rs.riverstonenet.com> Date: Thu, 18 Nov 2004 04:38:52 -0800 Reply-To: Mailing List Sender: Mailing List From: "Mollin, Arvind - LiqwidKrystal" Subject: Re: SeqNumberMismatch problem To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable pls see ospf debugs in other router. I am sure that router is not misses = hello and reintiates neighborship and adjacency. Other than this I don = have any clue. =20 Thanks Arvind =20 ________________________________ From: Mailing List on behalf of Razvan Bruma Sent: Thu 11/18/2004 3:53 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: SeqNumberMismatch problem Hello, 1. No, I am not implementing any MANET extensions, I'm not sure even if = the router supports them. The link is mainly a wireless bridge between the = two routers. 2. There's no key to 1 hour. The link comes down for no apparent reason every (roughly) one hour, but this is not a definitive rule. It happens = that everything is ok for 6 hours, let's say, and then I got ten SeqNumberMismatches in the following 30 minutes. From what I can see from the various debug outputs that I could get, something like this happens: a. Normal hellos are received every 10 sec: *Mar 4 13:00:50.289: OSPF: rcv. v:2 t:1 l:48 rid:172.16.1.129 aid:0.0.0.0 chk:7EC6 aut:0 auk: from Ethernet0/1 *Mar 4 13:01:00.289: OSPF: rcv. v:2 t:1 l:48 rid:172.16.1.129 aid:0.0.0.0 chk:7EC6 aut:0 auk: from Ethernet0/1 *Mar 4 13:01:10.289: OSPF: rcv. v:2 t:1 l:48 rid:172.16.1.129 aid:0.0.0.0 chk:7EC6 aut:0 auk: from Ethernet0/1 b. Suddenly I have a DD packet that resets the whole damn thing: *Mar 4 13:01:15.173: OSPF: rcv. v:2 t:2 l:32 rid:172.16.1.129 aid:0.0.0.0 chk:EA06 aut:0 auk: from Ethernet0/1 *Mar 4 13:01:15.173: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.1.129 on Ethernet0/1 from FULL to EXSTART, SeqNumberMismatch *Mar 4 13:01:15.185: OSPF: rcv. v:2 t:2 l:1432 rid:172.16.1.129 aid:0.0.0.0 chk:8DFF aut:0 auk: from Ethernet0/1 *Mar 4 13:01:15.185: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.1.129 on Ethernet0/1 from EXSTART to EXCHANGE, Negotiation Done *Mar 4 13:01:15.201: OSPF: rcv. v:2 t:2 l:32 rid:172.16.1.129 aid:0.0.0.0 chk:783 aut:0 auk: from Ethernet0/1 *Mar 4 13:01:15.205: OSPF: rcv. v:2 t:2 l:32 rid:172.16.1.129 aid:0.0.0.0 chk:782 aut:0 auk: from Ethernet0/1 *Mar 4 13:01:15.209: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.1.129 on Ethernet0/1 from EXCHANGE to LOADING, Exchange Done *Mar 4 13:01:15.209: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.1.129 on Ethernet0/1 from LOADING to FULL, Loading Done c. Then the process continues normally, until the next DD packet will = cause an error: *Mar 4 13:01:20.290: OSPF: rcv. v:2 t:1 l:48 rid:172.16.1.129 aid:0.0.0.0 chk:7EC6 aut:0 auk: from Ethernet0/1 *Mar 4 13:01:30.287: OSPF: rcv. v:2 t:1 l:48 rid:172.16.1.129 aid:0.0.0.0 chk:7EC6 aut:0 auk: from Ethernet0/1 I cannot use a protocol analyzer to see the exact content of each packet = and determine where is the mismatch, because I am in a remote location and I have to figure out what's happening from here. There is no MTU mismatch and the neighbors (there's only one neighbor, actually) are always in FULL. The loading is minimal. Do I miss anything? Razvan ----- Original Message ----- From: "Erblichs" To: Sent: Thursday, November 18, 2004 7:00 AM Subject: Re: SeqNumberMismatch problem > Group, > > First are you implimenting the MANET extensions??? > > What is the key to 1 hour? Are you doing something > verifying that the link is up every hour via the > RFC1793 Demand Circuit, DNA LSAs, and probing? > > Wireless ethernet... Is it possible that multiple > nbr hellos are being sent basicly the same time? > Are they becoming synchronized? Do you send out > your first hellos when you see a hello pkt to get > to 2-way quickly? What happens if two nbrs send > hellos at the same time in your implimentation? > > Other than the above, I vote for the 2nd... > > Only a reseting of the adj would force repeated > initial database syncs. > > A MTU size mismatch would not force the adj to > reset. It would prevent a FULL adj from forming > in the first place during the initial database > exchange or hang depending on the config params. > > So, either a large number of hellos are being dropped > which is unlikely, because 1 should get thru in router > dead interval timeframe OR a hello is being sent that > removes a nbr that WAS Fully adjacent. This is more than > likely reseting the adj. > > Either way check the hellos router dead interval > timeframe prior to the EXCHANGE state. > > Mitchell Erblich > ------------------------ > > > > However, if a hello was sent > > "Mollin, Arvind - LiqwidKrystal" wrote: > > > > IMHO, One of the reason may be MTU size mismatch. Pls check that you have configured same MTU size on the both interfaces. > > Second thing may be that one of the router is missing hellos ( say router with lesser routerid misses the hello), but the router which is having higher routerid recieves hellos and assumes that the peer is = okay. Then the router with lesser id tries to go on adjacency after recieving = a hello, that time it sends itself as master, due to this router with = higher routerid throws seq mismatch. > > > > Quick Check : See that both routers are always on FULL state .. > > > > Arvind > > > > ________________________________ > > > > From: Mailing List on behalf of Razvan Bruma > > Sent: Wed 11/17/2004 7:54 AM > > To: OSPF@PEACH.EASE.LSOFT.COM > > Subject: SeqNumberMismatch problem > > > > Hello all, > > > > I have two cisco 2611 routers connected via a wireless ethernet = link. Every > > hour (more or less) one SeqNumberMismatch is recorded into the = logging > > buffer, with all the consequences: back to EXCHANGE, bring up the = backup > > line, etc. > > > > I know (theoretically) what causes this event. Any ideas on what > > (practically) can happen? What errors of transmission or otherwise = can > > produce the mismatch ? > > > > Thanks > > > > Razvan > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 18 10:35:45 2004 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 KAA04147 for ; Thu, 18 Nov 2004 10:35:43 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00EE5091@cherry.ease.lsoft.com>; Thu, 18 Nov 2004 10:35:38 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45585206 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 18 Nov 2004 10:35:35 -0500 Received: from 147.234.1.11 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 18 Nov 2004 10:35:34 -0400 X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 X-MIMETrack: Serialize by Router on ILSMTP01/ECI Telecom(Release 6.5.1|January 21, 2004) at 11/18/2004 17:39:35 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=4DBBE5C3DFC063C48f9e8a93df938690918c4DBBE5C3DFC063C4" Content-Disposition: inline Message-ID: Date: Thu, 18 Nov 2004 17:35:30 +0200 Reply-To: Mailing List Sender: Mailing List From: Ilan Bercovich Subject: Unnumbered interfaces To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --0__=4DBBE5C3DFC063C48f9e8a93df938690918c4DBBE5C3DFC063C4 Content-type: text/plain; charset=US-ASCII Hello, Can anyone please help with this one: In following part of configuration, 192.9.100.1 and 192.9.100.2 are unnumbered interfaces: (Embedded image moved to file: pic00555.jpg) Why doesn't R1 (Cisco1721) add 192.9.100.1 and 192.9.100.2 to it's routing table? While it does exist in it's database: " Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 192.9.100.1 (Link Data) Router Interface address: 0.0.0.0 Number of TOS metrics: 0 TOS 0 Metrics: 100 " Thanks, Ilan --0__=4DBBE5C3DFC063C48f9e8a93df938690918c4DBBE5C3DFC063C4 Content-type: image/jpeg; name="pic00555.jpg" Content-Disposition: attachment; filename="pic00555.jpg" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsK CwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQU FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAARCAD9ARUDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD7J+Ev wl0r4laBr2v6/r3jifUpfFviS2JtPHWt2cKRQa3ewQxpDBdpHGqRRRoFVQMKK7X/AIZp8I/9Bf4g f+HH8Q//ACdR+zT/AMk61f8A7HPxZ/6kOo16rQB5V/wzT4R/6C/xA/8ADj+If/k6j/hmnwj/ANBf 4gf+HH8Q/wDydXqtFAHlX/DNPhH/AKC/xA/8OP4h/wDk6j/hmnwj/wBBf4gf+HH8Q/8AydXqtFAH lX/DNPhH/oL/ABA/8OP4h/8Ak6j/AIZp8I/9Bf4gf+HH8Q//ACdXKftO+I7/AMDeI/h1qcvxe1D4 ZeFtY1ptF1WXGkR2cKDTtQukm869tJSkrTW8EXL7CpwEDNur0D4KeKdU8V+Fbqe+uv7a063vXttI 8TeWsX9v2QSMpe+WoCrlmkj3oBHP5P2iFUhniVQDK/4Zp8I/9Bf4gf8Ahx/EP/ydR/wzT4R/6C/x A/8ADj+If/k6j4F+IPF+q6t8T9L8Z61p+u3+g+Jo9PtrjS9MOn26QNpGnXIRImlmcfPcyEl5XJLH BVdqL6rQB5V/wzT4R/6C/wAQP/Dj+If/AJOo/wCGafCP/QX+IH/hx/EP/wAnV6rRQB5V/wAM0+Ef +gv8QP8Aw4/iH/5Oo/4Zp8I/9Bf4gf8Ahx/EP/ydXqtFAHlX/DNPhH/oL/ED/wAOP4h/+Tqtfsya tfa/+zb8KNT1O9uNR1K98JaTc3V5dytLNPK9nEzyO7ElmZiSWJJJJJr0uvKv2Tv+TWPg3/2Jmjf+ kMNAHqtFeafEfS/Fr6rqGtRfEG38A+E9F0xLyKb7PbSwzXCtM9y2pfaIyRaJGlsR9nmt5MNc7pF/ dsmtpPiTxV4y+C9lr+maLb+G/G2q+H0vrXRfEPm+TYahLbB0t7raqybY5WCPhVbCtgA8UAdrRXlX g7UNf8IfFNPA1/4n1Dx9aXWiza1LqmqQWkV5pLpPFDFDL9kghiMVyHmaHdGrhrG6+eYHbBa+I+l+ LX1XUNai+INv4B8J6LpiXkU32e2lhmuFaZ7ltS+0Rki0SNLYj7PNbyYa53SL+7ZAD0uiuK0nxJ4q 8ZfBey1/TNFt/DfjbVfD6X1roviHzfJsNQltg6W91tVZNscrBHwqthWwAeK5/wAHahr/AIQ+KaeB r/xPqHj60utFm1qXVNUgtIrzSXSeKGKGX7JBDEYrkPM0O6NXDWN188wO2AA9VooooAKKKKACiiig AooooAKKKKACiiigAooooA8q/Zp/5J1q/wD2Ofiz/wBSHUa9Vryr9mn/AJJ1q/8A2Ofiz/1IdRr1 WgAooooAKKKKAPH/AIz+G/iLr/jf4f6j4Q0PwvqOm+GNTfWZH1vxBc2E08r2F9ZGAJHYzgKFvEk8 zcSShXYOHroPhv4O1z4cXlx4at00+68Aw+fc6VcG6dL3T/Mm3rpwtxF5RtoQzrC6SJ5cSww+SfLM z+gUUAeafCnwl4q8N+N/irqOv2ej2+m+I/EEWq6W+m6jLczGJLC1sts6PbxiNitlHJhWkGZmXP7s PJ6XRRQAUUUUAFFFFABXlX7J3/JrHwb/AOxM0b/0hhr1WvKv2Tv+TWPg3/2Jmjf+kMNAFT4q+G/i Lrnj/SLrSND8L+J/B+mww3cGlaz4gudLJ1RZXYTzLHY3InWJVgaFSyKku+Rld0t3h6uOT4inwDcR yW/hdfGy+H4mguFuLk6a+tGKTzEaPYJFtFlERVg7SMruCqFAX7WigDxT4X6B8U/CH2+G+8NeD4oZ bK6vbm9Pii6v9R1vWW8kQy3M506BIYiiSIxSJwiiBIY0ihWOrfxV8N/EXXPH+kXWkaH4X8T+D9Nh hu4NK1nxBc6WTqiyuwnmWOxuROsSrA0KlkVJd8jK7pbvD7BRQBxUcnxFPgG4jkt/C6+Nl8PxNBcL cXJ019aMUnmI0ewSLaLKIirB2kZXcFUKAvynwZ8N/EXwtqrWviHQ/C+n6PcQz3ep6ra+ILnVtX1b VGaBUnmZrG0jRREkqlVUqqrbxxLFFEEr2CigAooooAKKKKACiiigAooooAKKKKACiiigAooooA8q /Zp/5J1q/wD2Ofiz/wBSHUa9Vryr9mn/AJJ1q/8A2Ofiz/1IdRr1WgAooooAKKKKACiiigAooooA KKKKACiiigAryr9k7/k1j4N/9iZo3/pDDXqteVfsnf8AJrHwb/7EzRv/AEhhoA9VorivGvxh8NeA dVi0zUTrF9qTwi5az0DQb/WJoImZlSSZLOCUwq7JIEaQKHMUgXd5b7d//hLND/4RX/hJ/wC2dP8A +Eb+xf2l/bH2pPsf2XZ5n2jzs7PK2fPvzt285xQBrUVxXgr4w+GvH2qy6Zpx1ix1JITcrZ6/oN/o 808SsqvJCl5BEZlRnjDtGGCGWMNt8xNx41+MPhrwDqsWmaidYvtSeEXLWegaDf6xNBEzMqSTJZwS mFXZJAjSBQ5ikC7vLfaAdrRVTSdWsdf0qy1PTL231HTb2FLm1vLSVZYZ4nUMkiOpIZWUghgSCCCK 5/4e/FXwh8WbPVL3wZ4j0/xRYabe/wBn3N7pcwntxP5MUxRJVykmEnjJKFgCSpO5WAAOrooooAKK KKACiiigAooooAKKKKACiiigAooooA801b9mT4Pa/qt7qep/CjwPqOpXsz3N1eXfhyzlmnldizyO 7RkszMSSxJJJJNVf+GTvgh/0Rv4f/wDhL2P/AMar1WigDyr/AIZO+CH/AERv4f8A/hL2P/xqj/hk 74If9Eb+H/8A4S9j/wDGq9VooA8q/wCGTvgh/wBEb+H/AP4S9j/8ao/4ZO+CH/RG/h//AOEvY/8A xqvVaKAPKv8Ahk74If8ARG/h/wD+EvY//Gq8/wDiX+zv8JPD/jT4T2Fh8Jfh/b2mueJp9P1CP/hE 9Pbz4F0bU7kJkwkr++toWyuD8mM4JB+la8q+Mn/JRfgT/wBjnc/+o9rNAB/wyd8EP+iN/D//AMJe x/8AjVH/AAyd8EP+iN/D/wD8Jex/+NV6rRQB5V/wyd8EP+iN/D//AMJex/8AjVH/AAyd8EP+iN/D /wD8Jex/+NV6rRQB5V/wyd8EP+iN/D//AMJex/8AjVH/AAyd8EP+iN/D/wD8Jex/+NV6rRQB5V/w yd8EP+iN/D//AMJex/8AjVelaTpNjoGlWWmaZZW+nabZQpbWtnaRLFDBEihUjRFACqqgAKAAAABV uigDz/46aTrms/DjUYtF8b6f8PI4sXGp67qNq8yRWEYL3Ch0ubdrfcow06yBo03lCj7JE1fhPff2 n8LPBt5/wjH/AAhX2jRbKX/hGfK8r+yN0CH7Hs2Jt8rPl42LjZjavQGv/CfwP4r8Vab4n1vwb4f1 nxJpvl/YdY1DS4J7y18tzJH5UzoXTa7F12kYYkjk1q6l4T0PWf7V+36Np99/a1kum6h9ptUk+2Wo 8zFvNkHzIh582EbK/vZOPmOQDyrwxba5pH7TWsQ69qOn+LZNS0W4vtPuLOwe2fwrYJcW8cNi4M0q t9sYzS+dthaV9PlBEiQxJa9X8dNJ1zWfhxqMWi+N9P8Ah5HFi41PXdRtXmSKwjBe4UOlzbtb7lGG nWQNGm8oUfZImroHwn8D+FPCupeGNE8G+H9G8N6l5n27R9P0uCCzuvMQRyebCiBH3IoRtwOVAB4F Gv8Awn8D+K/FWm+J9b8G+H9Z8Sab5f2HWNQ0uCe8tfLcyR+VM6F02uxddpGGJI5NAB8J77+0/hZ4 NvP+EY/4Qr7RotlL/wAIz5Xlf2RugQ/Y9mxNvlZ8vGxcbMbV6Dlfg3/yUX47f9jnbf8AqPaNXpUe k2MOq3Gpx2VumpXMMVtPeLEomlijaRo42fGWVGmlKqTgGRyMbjnK8N/D3wr4O1XWtT0Dwzo+h6lr c32nVLzTbCK3mv5dzt5k7ooMrbpJDuYk5dj3NAHQUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFfOvwl+EulfErQNe1/X9e8cT6lL4t8SWxNp461uzhSKDW72CGNIYLtI41SKKNAqqBhRXa/8M0+ Ef8AoL/ED/w4/iH/AOTqAPVaK8q/4Zp8I/8AQX+IH/hx/EP/AMnUf8M0+Ef+gv8AED/w4/iH/wCT qAPVaK8q/wCGafCP/QX+IH/hx/EP/wAnUf8ADNPhH/oL/ED/AMOP4h/+TqAPVa8q+Mn/ACUX4E/9 jnc/+o9rNH/DNPhH/oL/ABA/8OP4h/8Ak6ql7+yn4D1G5sLi7u/HF1cWExubOWb4heIHa2lMbxGS Mm+yjGOWRNwwdsjjoxBAPYKK8q/4Zp8I/wDQX+IH/hx/EP8A8nUf8M0+Ef8AoL/ED/w4/iH/AOTq APVaK8q/4Zp8I/8AQX+IH/hx/EP/AMnUf8M0+Ef+gv8AED/w4/iH/wCTqAPVaK8q/wCGafCP/QX+ IH/hx/EP/wAnUf8ADNPhH/oL/ED/AMOP4h/+TqAPVaK8q/4Zp8I/9Bf4gf8Ahx/EP/ydVr9mTVr7 X/2bfhRqep3txqOpXvhLSbm6vLuVpZp5Xs4meR3YkszMSSxJJJJNAGt41+MPhrwDqsWmaidYvtSe EXLWegaDf6xNBEzMqSTJZwSmFXZJAjSBQ5ikC7vLfbv/APCWaH/wiv8Awk/9s6f/AMI39i/tL+2P tSfY/suzzPtHnZ2eVs+ffnbt5ziuV+Omk65rPw41GLRfG+n/AA8jixcanruo2rzJFYRgvcKHS5t2 t9yjDTrIGjTeUKPskTV+E99/afws8G3n/CMf8IV9o0Wyl/4RnyvK/sjdAh+x7NibfKz5eNi42Y2r 0ABV8FfGHw14+1WXTNOOsWOpJCblbPX9Bv8AR5p4lZVeSFLyCIzKjPGHaMMEMsYbb5ibjxr8YfDX gHVYtM1E6xfak8IuWs9A0G/1iaCJmZUkmSzglMKuySBGkChzFIF3eW+3ifDFtrmkftNaxDr2o6f4 tk1LRbi+0+4s7B7Z/Ctglxbxw2LgzSq32xjNL522FpX0+UESJDElr1fx00nXNZ+HGoxaL430/wCH kcWLjU9d1G1eZIrCMF7hQ6XNu1vuUYadZA0abyhR9kiAHVf8JZof/CK/8JP/AGzp/wDwjf2L+0v7 Y+1J9j+y7PM+0ednZ5Wz59+du3nOKyvAvxO0D4i/bk0iTUIbuy2G4sNZ0m70u8jR93lym3uoopfK cpIqybdjNFIoYmNwMrwnfaHqfwC0a88T+GNP8FeG7jwzDLqnhnVokis9ItWtQZrOdJERFiiQtGwZ FUKhBVRwMrwv/wAVp8U9L8Zar/xIJo9Fv7Hw3oF5+51G6sJZ7J7u+uYXw8eXgsgkO0NCrgzkSz+R bgHqtFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHlX7NP/ACTrV/8Asc/Fn/qQ6jXqteVfs0/8 k61f/sc/Fn/qQ6jXqtABRRRQAUUUUAfP/wC074jv/A3iP4danL8XtQ+GXhbWNabRdVlxpEdnCg07 ULpJvOvbSUpK01vBFy+wqcBAzbq6vwB4p8X+K/hZ4jn0a60/WtTt/tNt4U8TatGYrPX0ECm2vZ44 QCsRmZo2eIBJ1hNxAqRTxKtT4z+G/iLr/jf4f6j4Q0PwvqOm+GNTfWZH1vxBc2E08r2F9ZGAJHYz gKFvEk8zcSShXYOHq3ofg7xx8ONC8Q+GvCCeH7rRYbK9ufC1xrF1Oh0+6kZnt9Omt44tpsYWYqjx SI0cCxQiEmPznADwdqGv+EPimnga/wDE+oePrS60WbWpdU1SC0ivNJdJ4oYoZfskEMRiuQ8zQ7o1 cNY3XzzA7YPVa8f+DPhv4i+FtVa18Q6H4X0/R7iGe71PVbXxBc6tq+raozQKk8zNY2kaKIklUqql VVbeOJYooglewUAFFFFABRRRQAV5V+yd/wAmsfBv/sTNG/8ASGGvVa8q/ZO/5NY+Df8A2Jmjf+kM NAHVa/8ACfwP4r8Vab4n1vwb4f1nxJpvl/YdY1DS4J7y18tzJH5UzoXTa7F12kYYkjk1q6l4T0PW f7V+36Np99/a1kum6h9ptUk+2Wo8zFvNkHzIh582EbK/vZOPmOdaigDlNA+E/gfwp4V1Lwxong3w /o3hvUvM+3aPp+lwQWd15iCOTzYUQI+5FCNuByoAPAo1/wCE/gfxX4q03xPrfg3w/rPiTTfL+w6x qGlwT3lr5bmSPypnQum12LrtIwxJHJrq6KAMnUvCeh6z/av2/RtPvv7Wsl03UPtNqkn2y1HmYt5s g+ZEPPmwjZX97Jx8xzgeCvgh8Ovhrqsup+EPAPhfwrqUsJtpLzRNGtrOZ4iysYy8aKSpZEO3OMqD 2FdrRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAeVfs0/8AJOtX/wCxz8Wf+pDqNeq15V+z T/yTrV/+xz8Wf+pDqNeq0AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFeVfsnf8msfBv/ALEzRv8A 0hhr1WvKv2Tv+TWPg3/2Jmjf+kMNAHqtFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFAHlX7NP8AyTrV/wDsc/Fn/qQ6jXqteVfs0/8AJOtX/wCxz8Wf+pDqNeq0AFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFeVfsnf8msfBv8A7EzRv/SGGvVa+X/2StWvvhn8F/hHZ6ze3E/gnxB4 S0E6VqF5K0507VJrZRLZSyscxwTM0Jtt25RK00AeMNZwEA918bfFXwh8N7zQrLxN4j0/Rr/Xr2LT 9KsriYC4v55JooVSGIZeTDzxBioIQPuYqoJFXx98ZPCXww1XSdP8SahcWNxqcNxdRPFp1zcQw28D QrcXFxLFGyW0EZuId80zJGofJYAEjn/2lv8AknWkf9jn4T/9SHTq5/48atffBjVdT+JWiXujyalr OmW3h19J1mVhNdS27XlxZjTYkKm8uy1zcqLHdGbkmILPb+WxkAPQPGvxk8JfDzVYtP1zULiC4MIu rh7bTrm6h0+3LMouL2WGN0s4CUlxNcNHGRDMd2IpCva14V4B0m++E/gHwJ8OdEstH1L4qWfhLSdJ 1HU0iaS0sbW1iaJbq6cBJHgEv2n7PBlHncyhfKRbiaDqtJ+FXhXX/wBm2y+Gumavcaj4JvfCSeHb XVrS5ilmn097MW6TpKqmNmaIhg4UqSQQuOKANb4X/GTwl8ZNKOoeFdQuLu38mC6VL3Trmwme3mUt BcJFcxxu0EgV9kyqY3McgViUYC142+KvhD4b3mhWXibxHp+jX+vXsWn6VZXEwFxfzyTRQqkMQy8m HniDFQQgfcxVQSPIPhnq3ir4iftJTanqd74X1DTfA/h+/wDDt1eeGZZZ4Z9Qury1ZwzsSIZ0XTCZ bElmthNbkz3Hn/uu1/aW/wCSdaR/2OfhP/1IdOoA6rx18UvDHw1+w/8ACRan9g+173XbbyzeVDHt 865m8tW8m2i3x+ZcybYYvMTe671yeOvil4Y+Gv2H/hItT+wfa97rtt5ZvKhj2+dczeWreTbRb4/M uZNsMXmJvdd654qPVrHwp+0l4/1PW7230fTZPA2jXKXl/KsELRWd5q7XkgdyAVgW6tjK2cRi4iLY 3rnzX9mD/i2v9jf8Jd/xSv2b4M+EPP8A7b/0PyvsP9pfb93mbdv2b7Tb+dn/AFXnxb9u9cgH1VXK fD34q+EPizZ6pe+DPEen+KLDTb3+z7m90uYT24n8mKYokq5STCTxklCwBJUncrAc/wDsyaTfaB+z b8KNM1OyuNO1Ky8JaTbXVndxNFNBKlnErxujAFWVgQVIBBBBqr8G/wDkovx2/wCxztv/AFHtGoA9 VooooAKKKKACiiigAooooAKKKKAPCvBWifGH4a2OsaNpnhLwPremy+INZ1W1vrvxfeWczxXupXN4 ivCulyhGVbgKQJGGVJB5roP+Ej+N/wD0Tz4f/wDheX3/AMpq9VooA8q/4SP43/8ARPPh/wD+F5ff /Kaj/hI/jf8A9E8+H/8A4Xl9/wDKavVaKAPKv+Ej+N//AETz4f8A/heX3/ymo/4SP43/APRPPh// AOF5ff8Aymr1WigDyr/hI/jf/wBE8+H/AP4Xl9/8pqP+Ej+N/wD0Tz4f/wDheX3/AMpq9VooA8q/ 4SP43/8ARPPh/wD+F5ff/Kaj/hI/jf8A9E8+H/8A4Xl9/wDKavVaKAPKv+Ej+N//AETz4f8A/heX 3/ymo/4SP43/APRPPh//AOF5ff8Aymr1WigDyr/hI/jf/wBE8+H/AP4Xl9/8pqP+Ej+N/wD0Tz4f /wDheX3/AMpq9VooA8q/4SP43/8ARPPh/wD+F5ff/KatX4T/AAz/AOEU+AXg34e+J4NP1n+zfDNl oOqQbPPs7ry7VIJl2yKN8TbWGGUZU8jnFegUUAeKWvhPQ7qz0T4VfFjRtP8AHNpb7f8AhHNY8T2q agms+TCwHnGYMBqUcPmGT/nunmTxYH2iG29V/wCET0P/AISr/hJ/7G0//hJPsX9m/wBsfZU+2fZd /mfZ/Oxv8rf8+zO3dzjNVfHngqx+IPhmfRb+W4tkaa3u4Lu0ZRNa3VvOlxbTpuVkLRzRRSBXVkYo A6upZTleAfGt9qmq6t4V8RxW8HjDQ4be4vDYqwtL21naZbe8gBZjGsjW86mF2LxPFIu6RPKnmADx r8EPh18StVi1Pxf4B8L+KtSihFtHea3o1teTJEGZhGHkRiFDO525xlie5rVj+HvhWHSrjTI/DOjp ptzpkWiT2a2EQhl0+NZFjtGTbhoEWaULERtAkcADcc9BXmni39ofwf4J8ZHwrqcXiiTXfJa5S303 wfq9+s0SiLzJIpLe1dJVQzwq7IxCNIqthjigDtf+ET0P/hFf+EY/sbT/APhG/sX9m/2P9lT7H9l2 eX9n8nGzytnybMbdvGMVV8a/D3wr8StKi0zxf4Z0fxVpsUwuY7PW7CK8hSUKyiQJIrAMFdxuxnDE dzXKeLP2ivA3g258PxXd1rGop4hhS40i60Dw7qOr21+rxySqIZ7O3ljdjFDJLsDFvLUvjbg0eJP2 ivA3hXwzoviC9utYn0jV5vstvPpvh3Ub4x3Hnpb/AGedILd2t5/PdYfJmCSeaGj271ZQAdrr/hPQ /Ff9m/23o2n6z/Zt7HqVj/aFqk/2W6jz5dxFvB2SruO11wwycHmjX/Ceh+K/7N/tvRtP1n+zb2PU rH+0LVJ/st1Hny7iLeDslXcdrrhhk4PNVfBXjzRviDpUt/os9wyQTG2uLa+sp7K7tZQqt5c9tOiS wsUeNwsiKWSSNxlXUnoKAKkek2MOq3Gpx2VumpXMMVtPeLEomlijaRo42fGWVGmlKqTgGRyMbjnK 8N/D3wr4O1XWtT0Dwzo+h6lrc32nVLzTbCK3mv5dzt5k7ooMrbpJDuYk5dj3NdBRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFcp468C/8JV9h1LTb 7+w/Felb20vWVi83yd+3zIJo9y+dbS7EEkJZd2xHRo5YoZY+rooA5T4b+Ov+E80K4nuLH+yNa069 n0vVdLMvmG0uoW2sASqsYpF2Twu6I0kE8MmxRIAPNfize+KrD9pL4byeENG0fXNSPhLxIslvrery 6bCsX2zQ8uJI7a4JbcEG3YAQSdwwAe1+JHhbVLe8t/GfhC183xbYeRDc2iSKg1nTVm3TWcgcqjSq jzvbM7p5c7AGRIZrhZKmk/Dn4TfE7VbL4j2/grwvrOuyzJcR+ILvQof7SiuLdhGA7yRiaKeB4vLK PtkiaIoQrIQADzXx/wCDtc+F8HwP03w8mn+J/Ej/ABA1TVJRqd0+mWdxdXml67d3ZVkiuHhiD3Ex jQrKwVURnY5ko+L3g7XPCHwi1jWZU0++8Z+JviB4V1u5sEuni06K6GraPaw2yTmJpPKWK0gVpjGW dvMkESBlhT2Dxr8EPh18StVi1Pxf4B8L+KtSihFtHea3o1teTJEGZhGHkRiFDO525xlie5q146+E /gf4ofYf+Ey8G+H/ABb9h3/ZP7d0uC9+z79u/wAvzUbbu2JnGM7Vz0FAGV8PPB2uQeKte8beK00+ y8Sa1ZWWltpej3T3VnZ2to9y8IE8kUTzSs95cOz+XGoVo4whMbSy+gVU0nSbHQNKstM0yyt9O02y hS2tbO0iWKGCJFCpGiKAFVVAAUAAAACrdABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABXmni3Sb7wD4yPjrQ7K4vdIuoWi8UaLpsTST3R AiWDUoogCZZ7eONo3jjAlmhdQDK9rbQP6XRQBU0nVrHX9KstT0y9t9R029hS5tby0lWWGeJ1DJIj qSGVlIIYEgggirdeVXX/ABYvXdb1mXn4d61etqWoSj5R4cunVRNcFB8osZmUzTOAGhnlmnkLxTSy WvqtABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAVNW0mx1/Sr3TNTsrfUdNvYXtrqzu4llhnidSrxujAhlZSQVIIIJBrz/Q 9Wvvhh4m0fwdrd7catomszSWvhrWLqVprtZUgknbT7tiS8jLDBM8V0cmRImSc+cqy3fpdZPinwtp fjTQrrR9YtftdhcbSyrI0To6MHjljkQh4pUdUdJEKujorKysoIAOA/aB8QeL/Cmk+FtU8M61p+l2 B8TaJp+q29xphubi6gu9XsrZkhlMqpB8k0oYtFKSG+UxsA9ZPxM8Ra/cfFOfS7bx5/wrTRfD3hlv ELXd3a2k1nrDmd1k883CBhbWS28ZnEEsbldShzLAQjPgePo/HvivRX+HES6PqnjDR/EGka5Y3/iG 9fTF13SLG9tL03S/Z7aZPPE0a2kyIqhWZZ9kKTwQt2vxr+GeufF/7L4c8jw/p/huPZef8JFco93r FjdDzI9+nxbUS0uUR98V/wCbI0TjH2dgdwAOf07xN4t+KngHw78TYvGlv8LvCdx4SsPEcUG22u4V uJYnuLldSe4hBa0ij+zAG3ltpGBuSzp+7ZO1/wCFj65/woL/AIT7/hC9Q/4ST/hGf7d/4QzL/bPt X2Xzv7P/ANVv83f+6/1e7d/Bn5a5Tx/4F8cL4q8OWvhTwt4P1X4e6BZWzad4evtbn0aKC/idvLke KGwuEligRLcwJlFjkDyFHeO3eH0DRLnxxF4Vj/tfTvD9z4kj0W3kf7Ffzw2dxqux/PiG6F3htg4j 2S/vHKu2YwUHmAHmvwm8cajofj/w14C1P4kW/wAWLjXfCUnipdc8qyt5oliltIRJHHaKqNaXJuS8 JILIbeYGWcOPJ6D9oHxB4v8ACmk+FtU8M61p+l2B8TaJp+q29xphubi6gu9XsrZkhlMqpB8k0oYt FKSG+UxsA9VPh58Hb7wRqvizxtJpfhf/AITbWoZHg0rRrdrDTbeV2aaQPcbJJJJ55fKW4vREhnW0 tGNuphCnV/aA8JeKvGvgjTtO8IWej3mpQeINI1WRNb1GWyh8qyv4L0qHjt5yWdrZI8bQAJC2TsCM AVfFGseJ/GHxT1Twb4d8Q/8ACIf8I/othrzXq2UV5/aE11PexQ28ySD5bZPsEhkWNkml85Ak1v5b GXlPB/xS8T/tAf2D/wAI7qf/AAr7d4M0Pxq223i1L7RNqX2rybObzFXNtF9jk8zy/Lmm81Nktt5b eZ2vi3wV4q0/x/eeL/BMujyalrOmWmh6jFr7SiG0it5bmW3vIREuZWRry4D2zGMTAx4nt/LYy8/p PwU1z4S/2L/wra60+78nwzpfg2f/AISqRz9ntbDz/sl6nkIPOlT7VP5lufKWbdHtmtvLbzQDq/Cf jrXPih8AtG8ZeGLHT9M8SeIvDMOr6XZatK8tnb3VxaiWGOd41V2iV3UMyqGKgkAHisrwdqGv+EPi mnga/wDE+oePrS60WbWpdU1SC0ivNJdJ4oYoZfskEMRiuQ8zQ7o1cNY3XzzA7YNXRPB2ufDb4WR+ DfBKafL/AMI94Zt9L8N3uv3TyeddQwPFGL1IolxEPLtyzxtubfKAibFL8/8ABnw38RfC2qta+IdD 8L6fo9xDPd6nqtr4gudW1fVtUZoFSeZmsbSNFESSqVVSqqtvHEsUUQSgD2CiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooA+dfhL8JdK+JWga9r+v6944n1KXxb4ktibTx1rdnCkUGt3sEMaQw XaRxqkUUaBVUDCiu1/4Zp8I/9Bf4gf8Ahx/EP/ydR+zT/wAk61f/ALHPxZ/6kOo16rQB5V/wzT4R /wCgv8QP/Dj+If8A5Oo/4Zp8I/8AQX+IH/hx/EP/AMnV6rRQB5V/wzT4R/6C/wAQP/Dj+If/AJOo /wCGafCP/QX+IH/hx/EP/wAnV6rRQB5V/wAM0+Ef+gv8QP8Aw4/iH/5Oo/4Zp8I/9Bf4gf8Ahx/E P/ydXKftO+I7/wADeI/h1qcvxe1D4ZeFtY1ptF1WXGkR2cKDTtQukm869tJSkrTW8EXL7CpwEDNu rtfhV4k8ReMvAGryQ6lb3xhmmtfD3i67tA0OtW4iQw6g9tG0QZfMZ0JjaOO4EBnh8uKeIKAVf+Ga fCP/AEF/iB/4cfxD/wDJ1H/DNPhH/oL/ABA/8OP4h/8Ak6uf+DPjC51b4ueLvDWlfE+4+JekeGof smvvrB00XOnaozqYYIFsbeA7RGtz57TKy+YsKRNviukT3WgDyr/hmnwj/wBBf4gf+HH8Q/8AydR/ wzT4R/6C/wAQP/Dj+If/AJOr1WigDyr/AIZp8I/9Bf4gf+HH8Q//ACdR/wAM0+Ef+gv8QP8Aw4/i H/5Or1WigDyr/hmnwj/0F/iB/wCHH8Q//J1Wv2ZNWvtf/Zt+FGp6ne3Go6le+EtJubq8u5Wlmnle ziZ5HdiSzMxJLEkkkk16XXlX7J3/ACax8G/+xM0b/wBIYaAPVaKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKAPKv2af+Sdav/2Ofiz/ANSHUa9Vryr9mn/knWr/APY5+LP/AFId Rr1WgAooooAKKKKAPH/jP4b+Iuv+N/h/qPhDQ/C+o6b4Y1N9ZkfW/EFzYTTyvYX1kYAkdjOAoW8S TzNxJKFdg4etXwb4S8VfDK21Xw9odno+reE7eG6u9A+2ajLaT2kskheLTGjS3kRbSMsyRzRkGKEQ wi3fyjJJ6XRQB5p4S8JeKtc8f2fjbxtZ6PompaXpl3o2naVoGoy6hCYrmW2muJ5riW3gJYtZ26pG sQCBZGLy+aqw+l0UUAFFFFABRRRQAV5V+yd/yax8G/8AsTNG/wDSGGvVa8q/ZO/5NY+Df/YmaN/6 Qw0Aeq0UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAeVfs0/wDJOtX/AOxz 8Wf+pDqNeq15V+zT/wAk61f/ALHPxZ/6kOo16rQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAV5V+ yd/yax8G/wDsTNG/9IYa9Vryr9k7/k1j4N/9iZo3/pDDQB6rRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQB5V+zT/yTrV/+xz8Wf8AqQ6jXqtflXff8FW/+Ga/GPj74cf8Ku/4 SP8AsXxn4j/4mf8AwkP2XzvO1i7n/wBV9lfbjzdv3jnbnjOAf8Pzv+qJ/wDl1/8A3FQB+qlFflX/ AMPzv+qJ/wDl1/8A3FR/w/O/6on/AOXX/wDcVAH6qUV+Vf8Aw/O/6on/AOXX/wDcVH/D87/qif8A 5df/ANxUAfqpRX5V/wDD87/qif8A5df/ANxUf8Pzv+qJ/wDl1/8A3FQB+qlFflX/AMPzv+qJ/wDl 1/8A3FR/w/O/6on/AOXX/wDcVAH6qUV+Vf8Aw/O/6on/AOXX/wDcVH/D87/qif8A5df/ANxUAfqp RX5V/wDD87/qif8A5df/ANxUf8Pzv+qJ/wDl1/8A3FQB+qleVfsnf8msfBv/ALEzRv8A0hhr4A/4 fnf9UT/8uv8A+4q+/wD9k7/k1j4N/wDYmaN/6Qw0Aeq0UUUAFFFFABRRRQAUUUUAf//Z --0__=4DBBE5C3DFC063C48f9e8a93df938690918c4DBBE5C3DFC063C4-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 18 12:10:05 2004 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 MAA12347 for ; Thu, 18 Nov 2004 12:10:04 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00EE539C@cherry.ease.lsoft.com>; Thu, 18 Nov 2004 12:10:05 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45594831 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 18 Nov 2004 12:10:03 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 18 Nov 2004 12:10:01 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 18 Nov 2004 12:16:11 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAIHA274023547 for ; Thu, 18 Nov 2004 12:10:02 -0500 (EST) Received: from [128.107.177.103] (dhcp-128-107-177-103.cisco.com [128.107.177.103]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BDM01769; Thu, 18 Nov 2004 09:09:59 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <7549C475A1F3CF47ABCA660BF44738B3EFF7C6@legolas.rs.riverstonenet.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <419CD767.2040503@cisco.com> Date: Thu, 18 Nov 2004 12:09:59 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: SeqNumberMismatch problem To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <7549C475A1F3CF47ABCA660BF44738B3EFF7C6@legolas.rs.riverstonenet.com> Precedence: list Content-Transfer-Encoding: 7bit Mollin, Arvind - LiqwidKrystal wrote: >pls see ospf debugs in other router. I am sure that router is not misses hello and reintiates neighborship and adjacency. Other than this I don have any clue. > > I think you are on the right track. My suspicion is that the other router is experiencing some event (probably an interface flap) which causes it to lose the adjacency. It then receives a hello with it's own router ID before sending one of its own. It goes to ExchangeStart state and sends an initial DD packet causing the SeqNumber Mismatch. In any case debugging on the other router is necessary. Hope this helps, Acee > >Thanks >Arvind > > >________________________________ > >From: Mailing List on behalf of Razvan Bruma >Sent: Thu 11/18/2004 3:53 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: SeqNumberMismatch problem > > > >Hello, > >1. No, I am not implementing any MANET extensions, I'm not sure even if the >router supports them. The link is mainly a wireless bridge between the two >routers. > >2. There's no key to 1 hour. The link comes down for no apparent reason >every (roughly) one hour, but this is not a definitive rule. It happens that >everything is ok for 6 hours, let's say, and then I got ten >SeqNumberMismatches in the following 30 minutes. > > >>From what I can see from the various debug outputs that I could get, >something like this happens: > >a. Normal hellos are received every 10 sec: > >*Mar 4 13:00:50.289: OSPF: rcv. v:2 t:1 l:48 rid:172.16.1.129 > aid:0.0.0.0 chk:7EC6 aut:0 auk: from Ethernet0/1 >*Mar 4 13:01:00.289: OSPF: rcv. v:2 t:1 l:48 rid:172.16.1.129 > aid:0.0.0.0 chk:7EC6 aut:0 auk: from Ethernet0/1 >*Mar 4 13:01:10.289: OSPF: rcv. v:2 t:1 l:48 rid:172.16.1.129 > aid:0.0.0.0 chk:7EC6 aut:0 auk: from Ethernet0/1 > >b. Suddenly I have a DD packet that resets the whole damn thing: > >*Mar 4 13:01:15.173: OSPF: rcv. v:2 t:2 l:32 rid:172.16.1.129 > aid:0.0.0.0 chk:EA06 aut:0 auk: from Ethernet0/1 >*Mar 4 13:01:15.173: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.1.129 on >Ethernet0/1 from FULL to EXSTART, SeqNumberMismatch >*Mar 4 13:01:15.185: OSPF: rcv. v:2 t:2 l:1432 rid:172.16.1.129 > aid:0.0.0.0 chk:8DFF aut:0 auk: from Ethernet0/1 >*Mar 4 13:01:15.185: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.1.129 on >Ethernet0/1 from EXSTART to EXCHANGE, Negotiation Done >*Mar 4 13:01:15.201: OSPF: rcv. v:2 t:2 l:32 rid:172.16.1.129 > aid:0.0.0.0 chk:783 aut:0 auk: from Ethernet0/1 >*Mar 4 13:01:15.205: OSPF: rcv. v:2 t:2 l:32 rid:172.16.1.129 > aid:0.0.0.0 chk:782 aut:0 auk: from Ethernet0/1 >*Mar 4 13:01:15.209: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.1.129 on >Ethernet0/1 from EXCHANGE to LOADING, Exchange Done >*Mar 4 13:01:15.209: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.1.129 on >Ethernet0/1 from LOADING to FULL, Loading Done > >c. Then the process continues normally, until the next DD packet will cause >an error: > >*Mar 4 13:01:20.290: OSPF: rcv. v:2 t:1 l:48 rid:172.16.1.129 > aid:0.0.0.0 chk:7EC6 aut:0 auk: from Ethernet0/1 >*Mar 4 13:01:30.287: OSPF: rcv. v:2 t:1 l:48 rid:172.16.1.129 > aid:0.0.0.0 chk:7EC6 aut:0 auk: from Ethernet0/1 > >I cannot use a protocol analyzer to see the exact content of each packet and >determine where is the mismatch, because I am in a remote location and I >have to figure out what's happening from here. > >There is no MTU mismatch and the neighbors (there's only one neighbor, >actually) are always in FULL. The loading is minimal. > >Do I miss anything? > >Razvan > > > > >----- Original Message ----- >From: "Erblichs" >To: >Sent: Thursday, November 18, 2004 7:00 AM >Subject: Re: SeqNumberMismatch problem > > > > >>Group, >> >> First are you implimenting the MANET extensions??? >> >> What is the key to 1 hour? Are you doing something >> verifying that the link is up every hour via the >> RFC1793 Demand Circuit, DNA LSAs, and probing? >> >> Wireless ethernet... Is it possible that multiple >> nbr hellos are being sent basicly the same time? >> Are they becoming synchronized? Do you send out >> your first hellos when you see a hello pkt to get >> to 2-way quickly? What happens if two nbrs send >> hellos at the same time in your implimentation? >> >> Other than the above, I vote for the 2nd... >> >> Only a reseting of the adj would force repeated >> initial database syncs. >> >> A MTU size mismatch would not force the adj to >> reset. It would prevent a FULL adj from forming >> in the first place during the initial database >> exchange or hang depending on the config params. >> >> So, either a large number of hellos are being dropped >> which is unlikely, because 1 should get thru in router >> dead interval timeframe OR a hello is being sent that >> removes a nbr that WAS Fully adjacent. This is more than >> likely reseting the adj. >> >> Either way check the hellos router dead interval >> timeframe prior to the EXCHANGE state. >> >> Mitchell Erblich >> ------------------------ >> >> >> >>However, if a hello was sent >> >>"Mollin, Arvind - LiqwidKrystal" wrote: >> >> >>>IMHO, One of the reason may be MTU size mismatch. Pls check that you >>> >>> >have configured same MTU size on the both interfaces. > > >>>Second thing may be that one of the router is missing hellos ( say >>> >>> >router with lesser routerid misses the hello), but the router which is >having higher routerid recieves hellos and assumes that the peer is okay. >Then the router with lesser id tries to go on adjacency after recieving a >hello, that time it sends itself as master, due to this router with higher >routerid throws seq mismatch. > > >>>Quick Check : See that both routers are always on FULL state .. >>> >>>Arvind >>> >>>________________________________ >>> >>>From: Mailing List on behalf of Razvan Bruma >>>Sent: Wed 11/17/2004 7:54 AM >>>To: OSPF@PEACH.EASE.LSOFT.COM >>>Subject: SeqNumberMismatch problem >>> >>>Hello all, >>> >>>I have two cisco 2611 routers connected via a wireless ethernet link. >>> >>> >Every > > >>>hour (more or less) one SeqNumberMismatch is recorded into the logging >>>buffer, with all the consequences: back to EXCHANGE, bring up the backup >>>line, etc. >>> >>>I know (theoretically) what causes this event. Any ideas on what >>>(practically) can happen? What errors of transmission or otherwise can >>>produce the mismatch ? >>> >>>Thanks >>> >>>Razvan >>> >>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 18 12:18:26 2004 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 MAA13206 for ; Thu, 18 Nov 2004 12:18:25 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00EE53BE@cherry.ease.lsoft.com>; Thu, 18 Nov 2004 12:18:27 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45595345 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 18 Nov 2004 12:18:24 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 18 Nov 2004 12:18:02 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 18 Nov 2004 12:24:12 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAIHI0Wf019136 for ; Thu, 18 Nov 2004 12:18:00 -0500 (EST) Received: from [128.107.177.103] (dhcp-128-107-177-103.cisco.com [128.107.177.103]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BDM02360; Thu, 18 Nov 2004 09:18:00 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 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: <419CD948.1060300@cisco.com> Date: Thu, 18 Nov 2004 12:18:00 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Unnumbered interfaces To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Ilan, Type 1 router links carry intra-area topological information and do not result in routes being added to the routing table. If this is desired I suggest you add the numbered interface to your OSPF configuration. If it is not a loopback you should also configure it as passive. Hope this helps, Acee Ilan Bercovich wrote: > > >Hello, > >Can anyone please help with this one: > >In following part of configuration, >192.9.100.1 and 192.9.100.2 are unnumbered interfaces: > >(Embedded image moved to file: pic00555.jpg) > >Why doesn't R1 (Cisco1721) add 192.9.100.1 and 192.9.100.2 to it's routing >table? > >While it does exist in it's database: > > " Link connected to: another Router (point-to-point) > (Link ID) Neighboring Router ID: 192.9.100.1 > (Link Data) Router Interface address: 0.0.0.0 > Number of TOS metrics: 0 > TOS 0 Metrics: 100 " > >Thanks, >Ilan > > > ------------------------------------------------------------------------ > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 19 04:50:14 2004 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 EAA10585 for ; Fri, 19 Nov 2004 04:50:14 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00EE69F6@cherry.ease.lsoft.com>; Fri, 19 Nov 2004 4:50:14 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45682409 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 19 Nov 2004 04:50:13 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 19 Nov 2004 04:50:13 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: Minutes from OSPF WG Meeting in Washington, DC thread-index: AcTNH7+fvSUzWvMZTmuRuWI2AIvOigA/V1Mw Message-ID: Date: Fri, 19 Nov 2004 01:56:35 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Minutes from OSPF WG Meeting in Washington, DC To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi, Reading the minutes I figured out some work is being planned for simulation evaluation of flooding alternatives. We may want to have a look at http://www.watersprings.org/pub/id/draft-choudhury-manral-flooding-simul ation-00.txt ,on which we worked on quiet a while back. One of the things I recollect while working on OSPF and IS-IS, was that OSPF required the entire database of the neighbor before it could figure-out which LSA's were missing, in IS-IS this was pretty simple and straight forward. If we defined an order of sending LSA's this restriction could be easily got over. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem Sent: Thursday, November 18, 2004 8:49 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Minutes from OSPF WG Meeting in Washington, DC Thanks to Richard Rabbat for taking the detailed minutes. Acee From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 22 17:12:33 2004 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 RAA27843 for ; Mon, 22 Nov 2004 17:12:33 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00EEB405@cherry.ease.lsoft.com>; Mon, 22 Nov 2004 17:12:33 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 46238599 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 22 Nov 2004 17:12:28 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 22 Nov 2004 17:12:28 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 22 Nov 2004 17:19:25 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAMMCTgl026727 for ; Mon, 22 Nov 2004 17:12:30 -0500 (EST) Received: from [64.102.198.227] (dhcp-64-102-198-227.cisco.com [64.102.198.227]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BDO10557; Mon, 22 Nov 2004 14:12:27 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <60fc97be041115050276c794ef@mail.gmail.com> <60fc97be041119005778c1b763@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41A2644B.8010201@cisco.com> Date: Mon, 22 Nov 2004 17:12:27 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Graceful restart helper question To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <60fc97be041119005778c1b763@mail.gmail.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Sanjay, Sanjay BM wrote: >---------- Forwarded message ---------- >From: Sanjay BM >Date: Mon, 15 Nov 2004 18:32:12 +0530 >Subject: Graceful restart helper question >To: ospf@peach.ease.lsoft.com > > >Hi, > >Please see the following lines from the graceful restart rfc. > >=-=-=-=-=-=-=-=- >RFC3623 >Section 3.1 "Entering Helper Mode" >Page 8: >If Y was already helping X on the associated network segment, the new >grace-LSA should be accepted and the grace period should be updated >accordingly. >=-=-=-=-=-=-=-=- > >I had few questions relating to these lines. > >1. Why should a helper accept new grace LSAs? > > It is to handle the case where the OSPF routing software wants override an existing grace LSA (e.g., if it restarts more than once while preserving the data plane). It is the responsibility of the restarting router to assure this capability is not abused. Note that this was originally discussed as far back as the 01 version of the draft. However, there was not much discussion then as to why the override option was selected. http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0112&L=ospf&P=R96&I=-3 >2. Should the helper reset its grace-period timer to the grace-period >value received in this new grace LSA? > > Yes. >3. What should happen if the local policy on the helper had accepted >the grace-period value of the earlier received grace LSA and hence >entered helper mode, but now the policy rejects the grace-period value >set in the new grace LSA? Should the behavior in this case be >implementation specific? The policies could reject other parameters >for that matter, ex: grace-restart-reason. > > The RFC doesn't specify how local policies are handled. Hence it is an implementation decision. However, my opinion would be to apply the policy terminate the graceful restart since the latest grace LSA was rejected. >Kindly let me know. > >Thanx, >Sanjay > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 23 22:48:05 2004 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 WAA09648 for ; Tue, 23 Nov 2004 22:48:04 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00EED314@cherry.ease.lsoft.com>; Tue, 23 Nov 2004 22:48:01 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 46428794 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 23 Nov 2004 22:47:48 -0500 Received: from 208.17.35.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 23 Nov 2004 22:47:44 -0400 Received: from ([147.191.89.203]) by paoakoavas05.cable.comcast.com with ESMTP id KP-TDCG9.6304450; Tue, 23 Nov 2004 22:43:45 -0500 Received: by entexchimc01.broadband.att.com with Internet Mail Service (5.5.2657.72) id ; Tue, 23 Nov 2004 20:47:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Message-ID: <6FEB46B4943AA348B0776325DA8EC37F027B37D0@entcoexch01.broadband.att.com> Date: Tue, 23 Nov 2004 20:47:19 -0700 Reply-To: Mailing List Sender: Mailing List From: "Field, Brian" Subject: router LSA with unknown link type To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list If a router receives a router LSA that contains several links and for one of the links, the link type field is not known, should the router ignore the entire router LSA or just skip this one link? Thanks Brian From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 24 11:06:48 2004 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 LAA06376 for ; Wed, 24 Nov 2004 11:06:48 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00EEE086@cherry.ease.lsoft.com>; Wed, 24 Nov 2004 11:06:48 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 46519417 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 24 Nov 2004 11:06:46 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 24 Nov 2004 11:06:46 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 24 Nov 2004 11:13:59 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAOG6jFL015061 for ; Wed, 24 Nov 2004 11:06:45 -0500 (EST) Received: from [64.102.198.231] (dhcp-64-102-198-231.cisco.com [64.102.198.231]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BDP27896; Wed, 24 Nov 2004 08:06:44 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <6FEB46B4943AA348B0776325DA8EC37F027B37D0@entcoexch01.broadband.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41A4B194.80509@cisco.com> Date: Wed, 24 Nov 2004 11:06:44 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: router LSA with unknown link type To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <6FEB46B4943AA348B0776325DA8EC37F027B37D0@entcoexch01.broadband.att.com> Precedence: list Content-Transfer-Encoding: 7bit Field, Brian wrote: >If a router receives a router LSA that contains several links and >for one of the links, the link type field is not known, should the >router ignore the entire router LSA or just skip this one link? > > Hi Brian, Unfortunately, the handling of unknown link types is not specifically defined in RFC 2328. Since links types 1-4 are the only ones defined an implementation should probably log the invalid link type (with rate limiting). Whether it ignores the LSA or just the unknown link is implementation specific. If we were to move forward with link type extension it would not be backward compatible (at least not without knobs or other mechanisms). Thanks, Acee >Thanks >Brian > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Nov 24 23:04:46 2004 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 XAA06380 for ; Wed, 24 Nov 2004 23:04:45 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00EEEBD1@cherry.ease.lsoft.com>; Wed, 24 Nov 2004 23:04:44 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 46576455 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 24 Nov 2004 23:03:00 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 24 Nov 2004 23:03:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: router LSA with unknown link type thread-index: AcTSQKoDhufxlVI1Sq2jT/oAbvgnBwAY7K6w Message-ID: Date: Wed, 24 Nov 2004 20:09:35 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: router LSA with unknown link type To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Acee, I think we cannot leave this to an implementation, as it can cause routing loops if different routers have different assumptions and hence different Router LSA's on which to build the routing table. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem Sent: Wednesday, November 24, 2004 9:37 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: router LSA with unknown link type Field, Brian wrote: >If a router receives a router LSA that contains several links and >for one of the links, the link type field is not known, should the >router ignore the entire router LSA or just skip this one link? > > Hi Brian, Unfortunately, the handling of unknown link types is not specifically defined in RFC 2328. Since links types 1-4 are the only ones defined an implementation should probably log the invalid link type (with rate limiting). Whether it ignores the LSA or just the unknown link is implementation specific. If we were to move forward with link type extension it would not be backward compatible (at least not without knobs or other mechanisms). Thanks, Acee >Thanks >Brian > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 25 00:35:33 2004 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 AAA14153 for ; Thu, 25 Nov 2004 00:35:31 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00EEED58@cherry.ease.lsoft.com>; Thu, 25 Nov 2004 0:35:29 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 46583598 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 25 Nov 2004 00:35:24 -0500 Received: from 203.199.83.135 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 25 Nov 2004 00:35:24 -0400 Received: (qmail 16224 invoked by uid 510); 25 Nov 2004 05:34:48 -0000 Received: from unknown (203.126.136.223) by rediffmail.com via HTTP; 25 nov 2004 05:34:48 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1101360888---0-203.199.83.135-16217" Message-ID: <20041125053448.16223.qmail@webmail45.rediffmail.com> Date: Thu, 25 Nov 2004 05:34:48 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: draft-vasseur-ospf-te-caps-00 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart mime message --Next_1101360888---0-203.199.83.135-16217 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Few questions:=0A1)Section 3.2. =0A DATA-PLANE-CAPABILITY sub-TLV =0A LEN= GTH: Variable (N*8)=0A=0A The CONTROL-PLANE-CAPABILITY sub-TLV =A0=0A LE= NGTH: Variable (N*8) =0A=0Avivek> Value of N=3D1. Length =3D 8 bytes.=0A = Is there any requirement to allocate 8 bytes for capability =0A = flags. Allocation of 4 bytes should be good enough.=0A=0A2)Section 6.1=0A = The TE-NODE-CAP may be carried within a type 10 or 11 router =0A informati= on LSA depending on the MPLS Traffic Engineering =0A capability. =0A=0A D= raft: draft-ietf-ospf-cap-03=0A Section 2.3=0A If a type 11 opaque LSA is= chosen, the originating router should =0A also advertise type 10 LSA(s) i= nto any attached NSSA/stub area(s).=0A=0Avivek> Following from above, if su= b-tlv scope is Type 11 opaque LSA,=0A does statement from draft-ietf-= ospf-cap-03 mentioned above =0A holds. More clarity is required as pe= r flooding scopes in the =0A draft.=0A=0AThanks=0AVivek=0A=0A=0A =0A= =0A=0A =0A --Next_1101360888---0-203.199.83.135-16217 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AFew questions:
=0A1)Section 3.2.
=0A  DATA-PLANE-CAPABILI= TY sub-TLV
=0A  LENGTH: Variable (N*8)
=0A
=0A  The CON= TROL-PLANE-CAPABILITY sub-TLV  =A0
=0A  LENGTH: Variable (N*8)=  
=0A
=0Avivek> Value of N=3D1. Length =3D 8 bytes.
=0A&n= bsp;     Is there any requirement to allocate 8 bytes for capabi= lity
=0A      flags. Allocation of 4 bytes should be go= od enough.
=0A
=0A2)Section 6.1
=0A  The TE-NODE-CAP may be c= arried within a type 10 or 11 router
=0A  information LSA dependin= g on the MPLS Traffic Engineering
=0A  capability.
=0A
=0A&= nbsp; Draft: draft-ietf-ospf-cap-03
=0A  Section 2.3
=0A  I= f a type 11 opaque LSA is chosen, the originating router should
=0A&nbs= p; also advertise type 10 LSA(s) into any attached NSSA/stub area(s).
= =0A
=0Avivek> Following from above, if sub-tlv scope is Type 11 opaqu= e LSA,
=0A      does statement from draft-ietf-ospf-cap-= 03 mentioned above
=0A      holds. More clarity is requ= ired as per flooding scopes in the
=0A      draft.
= =0A
=0AThanks
=0AVivek
=0A
=0A
=0A 
=0A
=0A
= =0A 
=0A=0A

=0A

=0A=0A --Next_1101360888---0-203.199.83.135-16217-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 25 01:34:04 2004 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 BAA18681 for ; Thu, 25 Nov 2004 01:34:03 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00EEEEC0@cherry.ease.lsoft.com>; Thu, 25 Nov 2004 1:34:00 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 46586199 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 25 Nov 2004 01:33:59 -0500 Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 25 Nov 2004 01:33:58 -0400 Received: from smirtoraw2k03 (sjc-vpn4-220.cisco.com [10.21.80.220]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id iAP6Xui21700 for ; Wed, 24 Nov 2004 22:33:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal Message-ID: <07c501c4d2b8$be046130$b5a16440@amer.cisco.com> Date: Thu, 25 Nov 2004 01:33:56 -0500 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: router LSA with unknown link type To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: quoted-printable Vishwas, -> ->Hi Acee, -> ->I think we cannot leave this to an implementation, as it can=20 ->cause routing loops if different routers have different=20 ->assumptions and hence different Router LSA's on which to=20 ->build the routing table. If we are talking about an action in the future, that is an extension = which add or use a new link type, then the specification should handle = backward compatibility problem. If we are talking about present and say a bug which introduces an = unknown link in Router LSA, then since there is nothing specified in 2328, = different implementation could handle unknown link differently and yes this could cause problem. We don't have much choice to leave to implementation in = this case because there are implementation already out there ;-) Sina -> ->Thanks, ->Vishwas -> ->-----Original Message----- ->From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On=20 ->Behalf Of Acee Lindem ->Sent: Wednesday, November 24, 2004 9:37 PM ->To: OSPF@PEACH.EASE.LSOFT.COM ->Subject: Re: router LSA with unknown link type -> ->Field, Brian wrote: -> ->>If a router receives a router LSA that contains several=20 ->links and for=20 ->>one of the links, the link type field is not known, should=20 ->the router=20 ->>ignore the entire router LSA or just skip this one link? ->> ->> ->Hi Brian, ->Unfortunately, the handling of unknown link types is not=20 ->specifically defined in RFC 2328. Since links types 1-4 are=20 ->the only ones defined an implementation should probably log=20 ->the invalid link type (with rate limiting). Whether it=20 ->ignores the LSA or just the unknown link is implementation=20 ->specific. If we were to move forward with link type extension=20 ->it would not be backward compatible (at least not without=20 ->knobs or other mechanisms). -> ->Thanks, ->Acee -> ->>Thanks ->>Brian ->> ->> ->> -> From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 25 01:47:24 2004 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 BAA19874 for ; Thu, 25 Nov 2004 01:47:22 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00EEEF9A@cherry.ease.lsoft.com>; Thu, 25 Nov 2004 1:47:18 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 46586944 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 25 Nov 2004 01:47:17 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 25 Nov 2004 01:47:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: router LSA with unknown link type thread-index: AcTSudEddz5gEGP8QF+qlAp/TIw1cAAALqvg Message-ID: Date: Wed, 24 Nov 2004 22:53:49 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: router LSA with unknown link type To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Sina, I believe specifying one behavior as right will at-least make the vendors change at some point of time. Leaving it to the implementation I think is not right. I think we need to fill the crack and specify a correct behavior. Also I think we need to specify the behavior for RFC2740, as Acee intends to re-spin it. Similar case with unknown options etc. Acee you might want to add these to your list. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Sina Mirtorabi Sent: Thursday, November 25, 2004 12:04 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: router LSA with unknown link type Vishwas, -> ->Hi Acee, -> ->I think we cannot leave this to an implementation, as it can=20 ->cause routing loops if different routers have different=20 ->assumptions and hence different Router LSA's on which to=20 ->build the routing table. If we are talking about an action in the future, that is an extension which add or use a new link type, then the specification should handle backward compatibility problem. If we are talking about present and say a bug which introduces an unknown link in Router LSA, then since there is nothing specified in 2328, different implementation could handle unknown link differently and yes this could cause problem. We don't have much choice to leave to implementation in this case because there are implementation already out there ;-) Sina -> ->Thanks, ->Vishwas -> ->-----Original Message----- ->From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On=20 ->Behalf Of Acee Lindem ->Sent: Wednesday, November 24, 2004 9:37 PM ->To: OSPF@PEACH.EASE.LSOFT.COM ->Subject: Re: router LSA with unknown link type -> ->Field, Brian wrote: -> ->>If a router receives a router LSA that contains several=20 ->links and for=20 ->>one of the links, the link type field is not known, should=20 ->the router=20 ->>ignore the entire router LSA or just skip this one link? ->> ->> ->Hi Brian, ->Unfortunately, the handling of unknown link types is not=20 ->specifically defined in RFC 2328. Since links types 1-4 are=20 ->the only ones defined an implementation should probably log=20 ->the invalid link type (with rate limiting). Whether it=20 ->ignores the LSA or just the unknown link is implementation=20 ->specific. If we were to move forward with link type extension=20 ->it would not be backward compatible (at least not without=20 ->knobs or other mechanisms). -> ->Thanks, ->Acee -> ->>Thanks ->>Brian ->> From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 25 02:25:17 2004 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 CAA07257 for ; Thu, 25 Nov 2004 02:25:15 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00EEEF1C@cherry.ease.lsoft.com>; Thu, 25 Nov 2004 2:25:11 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 46588148 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 25 Nov 2004 02:25:05 -0500 Received: from 171.68.10.86 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 25 Nov 2004 02:15:05 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 24 Nov 2004 23:15:42 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from [192.168.0.2] (sjc-vpn5-629.cisco.com [10.21.90.117]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id iAP7F2Yr010251; Wed, 24 Nov 2004 23:15:03 -0800 (PST) User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) 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 Message-ID: <41A58675.9050709@cisco.com> Date: Wed, 24 Nov 2004 23:15:01 -0800 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: router LSA with unknown link type To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Hi Vishwas, Vishwas Manral wrote: >Hi Sina, > >I believe specifying one behavior as right will at-least make the >vendors change at some point of time. Leaving it to the implementation I >think is not right. I think we need to fill the crack and specify a >correct behavior. > > > The problem is to determine what should be the "correct" behavior when dealing with older code - dropping or accepting the LSA, because of an unknown link, might both cause loops At this point, we cannot specify what should be done, it is best left to the implementation (eventually with knobs .. sigh!) to deal with. "Be liberal in what you accept and conservative with what you send " is to me the best course of action. Padma >Also I think we need to specify the behavior for RFC2740, as Acee >intends to re-spin it. Similar case with unknown options etc. Acee you >might want to add these to your list. > >Thanks, >Vishwas > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Sina >Mirtorabi >Sent: Thursday, November 25, 2004 12:04 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: router LSA with unknown link type > >Vishwas, > >-> >->Hi Acee, >-> >->I think we cannot leave this to an implementation, as it can >->cause routing loops if different routers have different >->assumptions and hence different Router LSA's on which to >->build the routing table. > >If we are talking about an action in the future, that is an extension >which >add or use a new link type, then the specification should handle >backward >compatibility problem. > >If we are talking about present and say a bug which introduces an >unknown >link in Router LSA, then since there is nothing specified in 2328, >different >implementation could handle unknown link differently and yes this could >cause problem. We don't have much choice to leave to implementation in >this >case because there are implementation already out there ;-) > > >Sina > >-> >->Thanks, >->Vishwas >-> >->-----Original Message----- >->From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On >->Behalf Of Acee Lindem >->Sent: Wednesday, November 24, 2004 9:37 PM >->To: OSPF@PEACH.EASE.LSOFT.COM >->Subject: Re: router LSA with unknown link type >-> >->Field, Brian wrote: >-> >->>If a router receives a router LSA that contains several >->links and for >->>one of the links, the link type field is not known, should >->the router >->>ignore the entire router LSA or just skip this one link? >->> >->> >->Hi Brian, >->Unfortunately, the handling of unknown link types is not >->specifically defined in RFC 2328. Since links types 1-4 are >->the only ones defined an implementation should probably log >->the invalid link type (with rate limiting). Whether it >->ignores the LSA or just the unknown link is implementation >->specific. If we were to move forward with link type extension >->it would not be backward compatible (at least not without >->knobs or other mechanisms). >-> >->Thanks, >->Acee >-> >->>Thanks >->>Brian >->> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 25 05:07:38 2004 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 FAA23869 for ; Thu, 25 Nov 2004 05:07:38 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00EEF145@cherry.ease.lsoft.com>; Thu, 25 Nov 2004 5:07:36 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 46595117 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 25 Nov 2004 05:07:31 -0500 Received: from 216.37.114.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 25 Nov 2004 05:07:31 -0400 Received: (qmail 24425 invoked from network); 25 Nov 2004 10:07:30 -0000 Received: from unknown (HELO xebeo.com) (172.16.104.130) by lxmail.nj.us.utstar.com with SMTP; 25 Nov 2004 10:07:30 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <41A58675.9050709@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41A5AEE4.1030106@xebeo.com> Date: Thu, 25 Nov 2004 11:07:32 +0100 Reply-To: Mailing List Sender: Mailing List From: Tony Przygienda Subject: Re: router LSA with unknown link type To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <41A58675.9050709@cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Padma Pillay-Esnault wrote: > Hi Vishwas, > > Vishwas Manral wrote: > >> Hi Sina, >> >> I believe specifying one behavior as right will at-least make the >> vendors change at some point of time. Leaving it to the implementation I >> think is not right. I think we need to fill the crack and specify a >> correct behavior. >> >> >> > The problem is to determine what should be the "correct" behavior when > dealing with older code > - dropping or accepting the LSA, because of an unknown link, might > both cause loops > So this is a discussion that triggered my interest. I partially agree & disagree with all parties here ;-) My observations from quite a couple of specs and their deployment would be: . It is a sign of a good protocol spec that it specifies very tightly behavior when unexpected, corrupt data is received. One implementatoin taking the last elements vs. another taking the first of unexpected duplicates can loop as we all know. Given that IP is becoming such a critical infrastructure piece in the world and routing is holding lots of it together, I think that this request will show up more and more until it happens (ye all remember happy times where security sections were a sign of cluelessness and RFC boilerplates were smaller than a license plate). . The issue is becoming more urgent when the protocol leaves its original simplicitiy and purpose (and actually, this is a sign of a successfull protocol, only dead ones remain symmetric, static and beautifull) and people start to use it to paint cars, nail coffins and educate their kids. Just look @ IP. Can't squeeze a vague bit out in the header anywhere anymore (if we could, SPAM would be using it already ;-). . The problem with being tight on specification of behavior in such scenarios is that it blows up the spec very much and those redundant pieces need carefull maintainance since when broken become meta-confusing. The other problem is that a certain vagueness gives better implementations and sometimes a little hatch to cheat things out later in the protocol behavior. As last argument, on the other hand, being left with implementatoins hiding a zoo of behavior-changing knobs can become quite, let's say, undesirable and we all know good examples I guess. Ultimately, it's a philosophical decision with a good shot of real-world politics and pressure influencing it. --- tony >> > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 25 05:45:24 2004 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 FAA27414 for ; Thu, 25 Nov 2004 05:45:23 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00EEF089@cherry.ease.lsoft.com>; Thu, 25 Nov 2004 5:45:24 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 46596371 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 25 Nov 2004 05:45:18 -0500 Received: from 61.144.161.53 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 25 Nov 2004 05:45:16 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I7Q00LIZDTW2Z@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 25 Nov 2004 18:44:20 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar3 2004)) with ESMTP id <0I7Q00E81DTW1L@szxga01-in.huawei.com> forOSPF@PEACH.EASE.LSOFT.COM; Thu, 25 Nov 2004 18:44:20 +0800 (CST) Received: from NitinKCL7064 ([10.18.4.174]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar3 2004)) with ESMTPA id <0I7Q00IIZDUE8Y@szxml02-in.huawei.com> forOSPF@PEACH.EASE.LSOFT.COM; Thu, 25 Nov 2004 18:44:39 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-imss-version: 2.007 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com Message-ID: <000a01c4d2dc$bad69680$ae04120a@in.huawei.com> Date: Thu, 25 Nov 2004 16:21:33 +0530 Reply-To: Mailing List Sender: Mailing List From: Nitin Kakkar Subject: Re: router LSA with unknown link type To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <41A4B194.80509@cisco.com> Precedence: list Content-Transfer-Encoding: 7BIT IMHO I can think of two possibilities for this condition 1) Some error in LSA creation, which overwrite link type field. : This should be reflected in checksum error and should be handled such. 2) Some new invension which adds to the existing 4 types of Link Types (or support for unknown link types): This Needs to have some common understanding (RFC etc) to handle this. I feel that they can be handled like unknwon LSA's (store & forward only, no routing calc's) HTH Nitin -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Acee Lindem Sent: 2004Ae11OA24EO 21:37 To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: router LSA with unknown link type Field, Brian wrote: >If a router receives a router LSA that contains several links and >for one of the links, the link type field is not known, should the >router ignore the entire router LSA or just skip this one link? > > Hi Brian, Unfortunately, the handling of unknown link types is not specifically defined in RFC 2328. Since links types 1-4 are the only ones defined an implementation should probably log the invalid link type (with rate limiting). Whether it ignores the LSA or just the unknown link is implementation specific. If we were to move forward with link type extension it would not be backward compatible (at least not without knobs or other mechanisms). Thanks, Acee >Thanks >Brian > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 25 12:13:43 2004 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 MAA00574 for ; Thu, 25 Nov 2004 12:13:43 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00EEF7DC@cherry.ease.lsoft.com>; Thu, 25 Nov 2004 12:13:43 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 46664670 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 25 Nov 2004 12:13:41 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 25 Nov 2004 12:13:41 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 25 Nov 2004 12:13:43 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAPHDegl020342 for ; Thu, 25 Nov 2004 12:13:40 -0500 (EST) Received: from [192.168.2.6] (rtp-vpn3-342.cisco.com [10.82.217.88]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BDP74809; Thu, 25 Nov 2004 09:13:39 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000a01c4d2dc$bad69680$ae04120a@in.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41A612C3.8@cisco.com> Date: Thu, 25 Nov 2004 12:13:39 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: router LSA with unknown link type To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000a01c4d2dc$bad69680$ae04120a@in.huawei.com> Precedence: list Content-Transfer-Encoding: 7bit All, While it would have been better if RFC 2328 did precisely specify what to do with unknown link types the fact of the matter is that it doesn't. IMHO, we'd need a short draft in order to formally specify this (or concensus and inclusion in the RFC 2740 respin). At this point, the implementation(s) that generate(s) the unknown link types is/are the ones in violation of the protocol. Speaking as a WG member, I really don't like the idea of extending the protocol using unknown link types UNLESS the new types are in fact a different type of intra-area topological edge in the SPF graph. Once we open it up I can envision people trying to cram all sorts of non-link data in the router LSA. If we want to extend the protocol past what it does today there are cleaner ways of doing it (e.g., new LSA types supporting TLVs). Thanks, Acee Nitin Kakkar wrote: >IMHO I can think of two possibilities for this condition > >1) Some error in LSA creation, which overwrite link type field. : This >should be reflected in checksum error and should be handled such. > >2) Some new invension which adds to the existing 4 types of Link Types (or >support for unknown link types): This Needs to have some common >understanding (RFC etc) to handle this. I feel that they can be handled like >unknwon LSA's (store & forward only, no routing calc's) > >HTH >Nitin > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Acee >Lindem >Sent: 2004Ae11OA24EO 21:37 >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: router LSA with unknown link type > > >Field, Brian wrote: > > > >>If a router receives a router LSA that contains several links and >>for one of the links, the link type field is not known, should the >>router ignore the entire router LSA or just skip this one link? >> >> >> >> >Hi Brian, >Unfortunately, the handling of unknown link types is not specifically >defined in RFC 2328. >Since links types 1-4 are the only ones defined an implementation should >probably log >the invalid link type (with rate limiting). Whether it ignores the LSA >or just the unknown link is >implementation specific. If we were to move forward with link type >extension it would not be >backward compatible (at least not without knobs or other mechanisms). > >Thanks, >Acee > > > >>Thanks >>Brian >> >> >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 25 14:37:26 2004 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 OAA10065 for ; Thu, 25 Nov 2004 14:37:26 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00EEFA21@cherry.ease.lsoft.com>; Thu, 25 Nov 2004 14:37:25 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 46671249 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 25 Nov 2004 14:37:21 -0500 Received: from 47.129.242.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 25 Nov 2004 14:27:21 -0400 Received: from zbl6c004.us.nortel.com (zbl6c004.corpeast.baynetworks.com [132.245.205.54]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iAPJRLE15773 for ; Thu, 25 Nov 2004 14:27:21 -0500 (EST) Received: by zbl6c004.corpeast.baynetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Nov 2004 14:27:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4D324.C41291F2" Message-ID: <6204FDDE129D364D8040A98BCCB290EF0FF6E83A@zbl6c004.corpeast.baynetworks.com> Date: Thu, 25 Nov 2004 14:27:13 -0500 Reply-To: Mailing List Sender: Mailing List From: Piotr Galecki Subject: Re: router LSA with unknown link type 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_01C4D324.C41291F2 Content-Type: text/plain Hi Brian, I would use a common approach in protocol development, where you are strict in what you send and liberate in what you accept, This ensures the best interoperability. - Piotr ------------------------------ Date: Wed, 24 Nov 2004 20:09:35 -0800 From: Vishwas Manral Subject: Re: router LSA with unknown link type Hi Acee, I think we cannot leave this to an implementation, as it can cause routing loops if different routers have different assumptions and hence different Router LSA's on which to build the routing table. Thanks, Vishwas ------_=_NextPart_001_01C4D324.C41291F2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: router LSA with unknown link type

Hi Brian,

I would use a common approach in protocol = development,
where you are strict in what you send
and liberate in what you accept,
This ensures the best interoperability.

- Piotr


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

Date:    Wed, 24 Nov 2004 20:09:35 = -0800
From:    Vishwas Manral = <Vishwas@SINETT.COM>
Subject: Re: router LSA with unknown link = type

Hi Acee,

I think we cannot leave this to an implementation, as = it can cause routing loops if different routers have different = assumptions and hence different Router LSA's on which to build the = routing table.

Thanks,
Vishwas

------_=_NextPart_001_01C4D324.C41291F2-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Nov 25 19:22:16 2004 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 TAA29223 for ; Thu, 25 Nov 2004 19:22:16 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00EEFC6F@cherry.ease.lsoft.com>; Thu, 25 Nov 2004 19:22:18 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 46686279 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 25 Nov 2004 19:22:15 -0500 Received: from 216.37.114.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 25 Nov 2004 19:22:15 -0400 Received: (qmail 22285 invoked from network); 26 Nov 2004 00:22:16 -0000 Received: from unknown (HELO xebeo.com) (172.16.104.132) by lxmail.nj.us.utstar.com with SMTP; 26 Nov 2004 00:22:16 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <6204FDDE129D364D8040A98BCCB290EF0FF6E83A@zbl6c004.corpeast.baynetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41A677EE.5060100@xebeo.com> Date: Fri, 26 Nov 2004 01:25:18 +0100 Reply-To: Mailing List Sender: Mailing List From: Tony Przygienda Subject: Re: router LSA with unknown link type To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <6204FDDE129D364D8040A98BCCB290EF0FF6E83A@zbl6c004.corpeast.baynetworks.com> Precedence: list Content-Transfer-Encoding: 7bit Piotr Galecki wrote: > Hi Brian, > > I would use a common approach in protocol development, > where you are strict in what you send > and liberate in what you accept, > This ensures the best interoperability. > > - Piotr > that's just gibberish in the context of this discussion (unknown link types). Link-state rouing loop-freeness depends on all people interpreting the information received the same way and sometimes there is no 'liberal' way to interpret. Example: 2 routers send 2 instances of the exactly same link, once with a short, once with a long metric. If they take the 2nd instance to compute and you take the first, things will loop. If you ignore both, things may loop. You just don't know what they used to compute and their computation may influence the traffic they forward towards you. There is no 'liberal' way here. Things will not loop only if everyone interprets such a case in the same way or routers know how other routers interpret this information (it's much more complex than that actually but that would only cloud the discussion here). In other contextes, the statement makes lots of sense of course thanks -- tony From owner-ospf@PEACH.EASE.LSOFT.COM Fri Nov 26 00:41:44 2004 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 AAA25043 for ; Fri, 26 Nov 2004 00:41:44 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00EF0377@cherry.ease.lsoft.com>; Fri, 26 Nov 2004 0:41:45 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 46702839 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 26 Nov 2004 00:41:28 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 26 Nov 2004 00:41:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: router LSA with unknown link type thread-index: AcTTEy7iFelQ7CUKTu6ch92O3iR6ZAAXVgAQ Message-ID: Date: Thu, 25 Nov 2004 21:48:07 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: router LSA with unknown link type To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Acee, I think we must not forget there can be malicious violations of the protocol too, as Tony rightly specified we need to specify the behavior when unexpected or corrupt data is received. As you stated, I intend to post a short draft on this soon. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem Sent: Thursday, November 25, 2004 10:44 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: router LSA with unknown link type All, While it would have been better if RFC 2328 did precisely specify what to do with unknown link types the fact of the matter is that it doesn't. IMHO, we'd need a short draft in order to formally specify this (or concensus and inclusion in the RFC 2740 respin). At this point, the implementation(s) that generate(s) the unknown link types is/are the ones in violation of the protocol. Speaking as a WG member, I really don't like the idea of extending the protocol using unknown link types UNLESS the new types are in fact a different type of intra-area topological edge in the SPF graph. Once we open it up I can envision people trying to cram all sorts of non-link data in the router LSA. If we want to extend the protocol past what it does today there are cleaner ways of doing it (e.g., new LSA types supporting TLVs). Thanks, Acee Nitin Kakkar wrote: >IMHO I can think of two possibilities for this condition > >1) Some error in LSA creation, which overwrite link type field. : This >should be reflected in checksum error and should be handled such. > >2) Some new invension which adds to the existing 4 types of Link Types (or >support for unknown link types): This Needs to have some common >understanding (RFC etc) to handle this. I feel that they can be handled like >unknwon LSA's (store & forward only, no routing calc's) > >HTH >Nitin > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Acee >Lindem >Sent: 2004Ae11OA24EO 21:37 >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: router LSA with unknown link type > > >Field, Brian wrote: > > > >>If a router receives a router LSA that contains several links and >>for one of the links, the link type field is not known, should the >>router ignore the entire router LSA or just skip this one link? >> >> >> >> >Hi Brian, >Unfortunately, the handling of unknown link types is not specifically >defined in RFC 2328. >Since links types 1-4 are the only ones defined an implementation should >probably log >the invalid link type (with rate limiting). Whether it ignores the LSA >or just the unknown link is >implementation specific. If we were to move forward with link type >extension it would not be >backward compatible (at least not without knobs or other mechanisms). > >Thanks, >Acee > > > >>Thanks >>Brian >> >> >> From owner-ospf@PEACH.EASE.LSOFT.COM Mon Nov 29 22:15:50 2004 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 WAA13662 for ; Mon, 29 Nov 2004 22:15:48 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00EF526B@cherry.ease.lsoft.com>; Mon, 29 Nov 2004 22:15:43 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47264390 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 29 Nov 2004 22:15:39 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 29 Nov 2004 22:15:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4D68B.F3FD26CE" Thread-Topic: router LSA with unknown link type thread-index: AcTTEy7iFelQ7CUKTu6ch92O3iR6ZAAXVgAQAMbLoWs= Message-ID: Date: Mon, 29 Nov 2004 19:21:40 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: router LSA with unknown link type To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C4D68B.F3FD26CE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Acee, =20 Here goes the link: - http://www.ietf.org/internet-drafts/draft-manral-ospf-router-lsa-unknown-= type-00.txt =20 Do let me know your views? =20 Thanks, Vishwas ________________________________ From: Mailing List on behalf of Vishwas Manral Sent: Thu 11/25/2004 9:48 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: router LSA with unknown link type Hi Acee, I think we must not forget there can be malicious violations of the protocol too, as Tony rightly specified we need to specify the behavior when unexpected or corrupt data is received. As you stated, I intend to post a short draft on this soon. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem Sent: Thursday, November 25, 2004 10:44 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: router LSA with unknown link type All, While it would have been better if RFC 2328 did precisely specify what to do with unknown link types the fact of the matter is that it doesn't. IMHO, we'd need a short draft in order to formally specify this (or concensus and inclusion in the RFC 2740 respin). At this point, the implementation(s) that generate(s) the unknown link types is/are the ones in violation of the protocol. Speaking as a WG member, I really don't like the idea of extending the protocol using unknown link types UNLESS the new types are in fact a different type of intra-area topological edge in the SPF graph. Once we open it up I can envision people trying to cram all sorts of non-link data in the router LSA. If we want to extend the protocol past what it does today there are cleaner ways of doing it (e.g., new LSA types supporting TLVs). Thanks, Acee Nitin Kakkar wrote: >IMHO I can think of two possibilities for this condition > >1) Some error in LSA creation, which overwrite link type field. : This >should be reflected in checksum error and should be handled such. > >2) Some new invension which adds to the existing 4 types of Link Types (or >support for unknown link types): This Needs to have some common >understanding (RFC etc) to handle this. I feel that they can be handled like >unknwon LSA's (store & forward only, no routing calc's) > >HTH >Nitin > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Acee >Lindem >Sent: 2004Ae11OA24EO 21:37 >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: router LSA with unknown link type > > >Field, Brian wrote: > > > >>If a router receives a router LSA that contains several links and >>for one of the links, the link type field is not known, should the >>router ignore the entire router LSA or just skip this one link? >> >> >> >> >Hi Brian, >Unfortunately, the handling of unknown link types is not specifically >defined in RFC 2328. >Since links types 1-4 are the only ones defined an implementation should >probably log >the invalid link type (with rate limiting). Whether it ignores the LSA >or just the unknown link is >implementation specific. If we were to move forward with link type >extension it would not be >backward compatible (at least not without knobs or other mechanisms). > >Thanks, >Acee > > > >>Thanks >>Brian >> >> >> ------_=_NextPart_001_01C4D68B.F3FD26CE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: router LSA with unknown link type=0A= =0A= =0A=
=0A=
Hi = Acee,
=0A=
 
=0A=
Here goes the = link: =0A= -
=0A= =0A=
 
=0A=
Do let me know your views?
=0A=
 
=0A=
Thanks,
=0A=
Vishwas
=0A=

=0A=
=0A= From: Mailing List on behalf of = Vishwas =0A= Manral
Sent: Thu 11/25/2004 9:48 PM
To: =0A= OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: router LSA with unknown = link =0A= type

=0A=
=0A=

Hi Acee,

I think we must not forget there can = be =0A= malicious violations of the
protocol too, as Tony rightly specified = we need =0A= to specify the behavior
when unexpected or corrupt data is =0A= received.

As you stated, I intend to post a short draft on this =0A= soon.

Thanks,
Vishwas
-----Original Message-----
From: = Mailing =0A= List [mailto:OSPF@PEACH.EASE.LSOFT.CO= M] On =0A= Behalf Of Acee
Lindem
Sent: Thursday, November 25, 2004 10:44 = PM
To: =0A= OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: router LSA with unknown link =0A= type

All,
While it would have been better if RFC 2328 did = precisely =0A= specify what
to do with unknown link types the fact of the matter is = that it =0A= doesn't.
IMHO,
we'd need a short draft in order to formally = specify this =0A= (or concensus
and inclusion
in the RFC 2740 respin). At this = point, the =0A= implementation(s) that
generate(s)
the unknown link types is/are = the ones =0A= in violation of the protocol.

Speaking as a WG member, I really = don't =0A= like the idea of extending the
protocol
using unknown link types = UNLESS =0A= the new types are in fact a different
type of
intra-area = topological edge =0A= in the SPF graph. Once we open it up I can
envision people
trying = to cram =0A= all sorts of non-link data in the router LSA. If we want
to extend =0A= the
protocol past what it does today there are cleaner ways of doing =0A= it
(e.g., new LSA types
supporting =0A= TLVs).

Thanks,
Acee


Nitin Kakkar = wrote:

>IMHO I =0A= can think of two possibilities for this condition
>
>1) Some = error =0A= in LSA creation, which overwrite link type field. : This
>should = be =0A= reflected in checksum error and should be handled = such.
>
>2) Some =0A= new invension which adds to the existing 4 types of Link =0A= Types
(or
>support for unknown link types): This Needs to have = some =0A= common
>understanding (RFC etc) to handle this. I feel that they = can be =0A= handled
like
>unknwon LSA's (store & forward only, no = routing =0A= calc's)
>
>HTH
>Nitin
>
>-----Original =0A= Message-----
>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.CO= M]On =0A= Behalf Of Acee
>Lindem
>Sent: 2004Ae11OA24EO = 21:37
>To: =0A= OSPF@PEACH.EASE.LSOFT.COM
>Subject: Re: router LSA with unknown = link =0A= type
>
>
>Field, Brian =0A= wrote:
>
>
>
>>If a router receives a router = LSA that =0A= contains several links and
>>for one of the links, the link = type field =0A= is not known, should the
>>router ignore the entire router LSA = or just =0A= skip this one = link?
>>
>>
>>
>>
>Hi =0A= Brian,
>Unfortunately, the handling of unknown link types is not =0A= specifically
>defined in RFC 2328.
>Since links types 1-4 = are the =0A= only ones defined an implementation
should
>probably = log
>the =0A= invalid link type (with rate limiting). Whether it ignores the = LSA
>or =0A= just the unknown link is
>implementation specific. If we were to = move =0A= forward with link type
>extension it would not be
>backward =0A= compatible (at least not without knobs or other =0A= mechanisms).
>
>Thanks,
>Acee
>
>
>>>Thanks
>>Brian
>>
>>
>>
=

=0A= =0A= =0A= ------_=_NextPart_001_01C4D68B.F3FD26CE-- From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 30 08:00:17 2004 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 IAA14399 for ; Tue, 30 Nov 2004 08:00:16 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00EF5CF1@cherry.ease.lsoft.com>; Tue, 30 Nov 2004 8:00:10 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47339213 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 30 Nov 2004 08:00:04 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 30 Nov 2004 08:00:00 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 30 Nov 2004 08:08:19 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAUD01FL006983 for ; Tue, 30 Nov 2004 07:00:01 -0500 (EST) Received: from [192.168.2.6] (rtp-vpn1-201.cisco.com [10.82.224.201]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BDR15350; Tue, 30 Nov 2004 05:00:00 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) 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 Message-ID: <41AC6ECF.1040405@cisco.com> Date: Tue, 30 Nov 2004 07:59:59 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: router LSA with unknown link type To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Vishwas Manral wrote: > Hi Acee, > > Here goes the link: - > http://www.ietf.org/internet-drafts/draft-manral-ospf-router-lsa-unknown-type-00.txt > > Do let me know your views? Hi Vishwas, I feel we should move forward with support for the "silently ignore" option. I think that you should add a section with a caveat that states that the addition of new link types will still have compatibility implications since there is the potential for routing loops if some routers in the area support the new types and others ignore them. However, the situation is better than what we have today. Thanks, Acee > > Thanks, > Vishwas > > ------------------------------------------------------------------------ > *From:* Mailing List on behalf of Vishwas Manral > *Sent:* Thu 11/25/2004 9:48 PM > *To:* OSPF@PEACH.EASE.LSOFT.COM > *Subject:* Re: router LSA with unknown link type > > Hi Acee, > > I think we must not forget there can be malicious violations of the > protocol too, as Tony rightly specified we need to specify the behavior > when unexpected or corrupt data is received. > > As you stated, I intend to post a short draft on this soon. > > Thanks, > Vishwas > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee > Lindem > Sent: Thursday, November 25, 2004 10:44 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: router LSA with unknown link type > > All, > While it would have been better if RFC 2328 did precisely specify what > to do with unknown link types the fact of the matter is that it doesn't. > IMHO, > we'd need a short draft in order to formally specify this (or concensus > and inclusion > in the RFC 2740 respin). At this point, the implementation(s) that > generate(s) > the unknown link types is/are the ones in violation of the protocol. > > Speaking as a WG member, I really don't like the idea of extending the > protocol > using unknown link types UNLESS the new types are in fact a different > type of > intra-area topological edge in the SPF graph. Once we open it up I can > envision people > trying to cram all sorts of non-link data in the router LSA. If we want > to extend the > protocol past what it does today there are cleaner ways of doing it > (e.g., new LSA types > supporting TLVs). > > Thanks, > Acee > > > Nitin Kakkar wrote: > > >IMHO I can think of two possibilities for this condition > > > >1) Some error in LSA creation, which overwrite link type field. : This > >should be reflected in checksum error and should be handled such. > > > >2) Some new invension which adds to the existing 4 types of Link Types > (or > >support for unknown link types): This Needs to have some common > >understanding (RFC etc) to handle this. I feel that they can be handled > like > >unknwon LSA's (store & forward only, no routing calc's) > > > >HTH > >Nitin > > > >-----Original Message----- > >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Acee > >Lindem > >Sent: 2004Ae11OA24EO 21:37 > >To: OSPF@PEACH.EASE.LSOFT.COM > >Subject: Re: router LSA with unknown link type > > > > > >Field, Brian wrote: > > > > > > > >>If a router receives a router LSA that contains several links and > >>for one of the links, the link type field is not known, should the > >>router ignore the entire router LSA or just skip this one link? > >> > >> > >> > >> > >Hi Brian, > >Unfortunately, the handling of unknown link types is not specifically > >defined in RFC 2328. > >Since links types 1-4 are the only ones defined an implementation > should > >probably log > >the invalid link type (with rate limiting). Whether it ignores the LSA > >or just the unknown link is > >implementation specific. If we were to move forward with link type > >extension it would not be > >backward compatible (at least not without knobs or other mechanisms). > > > >Thanks, > >Acee > > > > > > > >>Thanks > >>Brian > >> > >> > >> > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 30 08:02:06 2004 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 IAA14532 for ; Tue, 30 Nov 2004 08:02:04 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00EF5C59@cherry.ease.lsoft.com>; Tue, 30 Nov 2004 8:01:58 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47339376 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 30 Nov 2004 08:01:53 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 30 Nov 2004 08:01:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C4D6DD.DB0CB0D8" X-MS-Has-Attach: yes Thread-Topic: router LSA with unknown link type thread-index: AcTW3Z5kaco4f6njSLuUP9jRYUTHiwAAALYw Message-ID: Date: Tue, 30 Nov 2004 05:08:39 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: router LSA with unknown link type To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C4D6DD.DB0CB0D8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Acee, I am attaching the document where I have added, exactly what you have stated. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem Sent: Tuesday, November 30, 2004 6:30 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: router LSA with unknown link type Vishwas Manral wrote: > Hi Acee, > > Here goes the link: - > http://www.ietf.org/internet-drafts/draft-manral-ospf-router-lsa-unknown -type-00.txt > > Do let me know your views? Hi Vishwas, I feel we should move forward with support for the "silently ignore" option. I think that you should add a section with a caveat that states that the addition of new link types will still have compatibility implications since there is the potential for routing loops if some routers in the area support the new types and others ignore them. However, the situation is better than what we have today. Thanks, Acee > > Thanks, > Vishwas > > ------------------------------------------------------------------------ > *From:* Mailing List on behalf of Vishwas Manral > *Sent:* Thu 11/25/2004 9:48 PM > *To:* OSPF@PEACH.EASE.LSOFT.COM > *Subject:* Re: router LSA with unknown link type > > Hi Acee, > > I think we must not forget there can be malicious violations of the > protocol too, as Tony rightly specified we need to specify the behavior > when unexpected or corrupt data is received. > > As you stated, I intend to post a short draft on this soon. > > Thanks, > Vishwas > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee > Lindem > Sent: Thursday, November 25, 2004 10:44 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: router LSA with unknown link type > > All, > While it would have been better if RFC 2328 did precisely specify what > to do with unknown link types the fact of the matter is that it doesn't. > IMHO, > we'd need a short draft in order to formally specify this (or concensus > and inclusion > in the RFC 2740 respin). At this point, the implementation(s) that > generate(s) > the unknown link types is/are the ones in violation of the protocol. > > Speaking as a WG member, I really don't like the idea of extending the > protocol > using unknown link types UNLESS the new types are in fact a different > type of > intra-area topological edge in the SPF graph. Once we open it up I can > envision people > trying to cram all sorts of non-link data in the router LSA. If we want > to extend the > protocol past what it does today there are cleaner ways of doing it > (e.g., new LSA types > supporting TLVs). > > Thanks, > Acee > > > Nitin Kakkar wrote: > > >IMHO I can think of two possibilities for this condition > > > >1) Some error in LSA creation, which overwrite link type field. : This > >should be reflected in checksum error and should be handled such. > > > >2) Some new invension which adds to the existing 4 types of Link Types > (or > >support for unknown link types): This Needs to have some common > >understanding (RFC etc) to handle this. I feel that they can be handled > like > >unknwon LSA's (store & forward only, no routing calc's) > > > >HTH > >Nitin > > > >-----Original Message----- > >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Acee > >Lindem > >Sent: 2004Ae11OA24EO 21:37 > >To: OSPF@PEACH.EASE.LSOFT.COM > >Subject: Re: router LSA with unknown link type > > > > > >Field, Brian wrote: > > > > > > > >>If a router receives a router LSA that contains several links and > >>for one of the links, the link type field is not known, should the > >>router ignore the entire router LSA or just skip this one link? > >> > >> > >> > >> > >Hi Brian, > >Unfortunately, the handling of unknown link types is not specifically > >defined in RFC 2328. > >Since links types 1-4 are the only ones defined an implementation > should > >probably log > >the invalid link type (with rate limiting). Whether it ignores the LSA > >or just the unknown link is > >implementation specific. If we were to move forward with link type > >extension it would not be > >backward compatible (at least not without knobs or other mechanisms). > > > >Thanks, > >Acee > > > > > > > >>Thanks > >>Brian > >> > >> > >> > ------_=_NextPart_001_01C4D6DD.DB0CB0D8 Content-Type: text/plain; name="draft-manral-ospf-router-lsa-unknown-type-01.txt" Content-Description: draft-manral-ospf-router-lsa-unknown-type-01.txt Content-Disposition: attachment; filename="draft-manral-ospf-router-lsa-unknown-type-01.txt" Content-Transfer-Encoding: base64 SW5kaXZpZHVhbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBWaXNod2FzIE1hbnJhbCAgIA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFNpTmV0dCBDb3JwLiAgDQpFeHBpcmVzOiBNYXkgMzAs IDIwMDUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5vdmVtYmVyIDMwLCAy MDA0DQoNCg0KDQogICAgICAgICAgICAgICAgICBUcmVhdGluZyB1bmtub3duIFJvdXRlci1MU0Eg bGluayB0eXBlcyANCiAgICAgICAgICAgICAgICAgICAgZHJhZnQtbWFucmFsLW9zcGYtcm91dGVy LWxzYS11bmtub3duLXR5cGUtMDENCg0KDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCg0KICAgVGhp cyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgc3ViamVjdCB0byBhbGwgcHJv dmlzaW9ucw0KICAgb2Ygc2VjdGlvbiAzIG9mIFJGQyAzNjY3LiAgQnkgc3VibWl0dGluZyB0aGlz IEludGVybmV0LURyYWZ0LCBlYWNoDQogICBhdXRob3IgcmVwcmVzZW50cyB0aGF0IGFueSBhcHBs aWNhYmxlIHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mDQogICB3aGljaCBoZSBvciBzaGUg aXMgYXdhcmUgaGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55IG9mDQogICB3 aGljaCBoZSBvciBzaGUgYmVjb21lIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2VkLCBpbiBhY2NvcmRh bmNlIHdpdGgNCiAgIFJGQyAzNjY4Lg0KDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2lu ZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJ RVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0DQogICBv dGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcw0KICAg SW50ZXJuZXQtRHJhZnRzLg0KDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1l bnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAgYW5kIG1heSBiZSB1cGRh dGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAg IHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVm ZXJlbmNlDQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBp biBwcm9ncmVzcy4iDQoNCg0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMg Y2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3Ry YWN0cy50eHQuDQoNCg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVj dG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cu aHRtbC4NCg0KDQogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEFwcmlsIDQs IDIwMDUuDQoNCg0KQ29weXJpZ2h0IE5vdGljZQ0KDQoNCiAgIENvcHlyaWdodCAoQykgVGhlIElu dGVybmV0IFNvY2lldHkgKDIwMDQpLg0KDQoNCkFic3RyYWN0DQoNCiAgIFRoaXMgZG9jdW1lbnQg YXR0ZW1wdHMgdG8gZGlzY3VzcyBhbmQgY2xhcmlmeSB0aGUgdGV4dCBpbiBbT1NQRnYyXSBhbmQN CiAgIFtPU1BGdjNdLCBhYm91dCBkZWFsaW5nIHdpdGggdW5rbm93biBsaW5rIHR5cGVzIGluIHJv dXRlciBMU0Ency4NCg0KDQoNCg0KIA0KTWFucmFsLCAgICAgICAgICAgIEV4cGlyZXMgTWF5IDI2 LCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDFdDQpJbnRlcm5ldC1EcmFmdCAg ICAgVHJlYXRpbmcgdW5rbm93biBSb3V0ZXItTFNBIGxpbmsgdHlwZXMgICBOb3ZlbWJlciAyMDA0 DQoNCg0KICAgDQoxLiAgUHJvYmxlbSBEZWZpbml0aW9uDQoNCiAgIFRoZSB0ZXh0IGluIFtPU1BG djJdIGFuZCBbT1NQRnYzXSBkb2VzIG5vdCBzdGF0ZSBob3cgdG8gdHJlYXQgdW5rbm93biANCiAg IGxpbmsgdHlwZXMgd2hlbiBwcmVzZW50IGluIFJvdXRlciBMU0Ency4NCg0KICAgTGluay1zdGF0 ZSBSb3V0aW5nIGFzc3VtZXMgdGhhdCBhbiBPU1BGIHJvdXRlciBtYWludGFpbnMgYW4gaWRlbnRp Y2FsDQogICBkYXRhYmFzZSBkZXNjcmliaW5nIHRoZSBBdXRvbm9tb3VzIFN5c3RlbSdzIHRvcG9s b2d5LiBJbmNhc2UgdGhlIGEgDQogICBSb3V0ZXIgTFNBIHdpdGggYW4gdW5rbm93biBsaW5rIHR5 cGUgaXMgcmVjZWl2ZWQgaW1wbGVtZW50YXRpb25zIHRyZWF0DQogICB0aGUgTFNBIGRpZmZlcmVu dGx5LiBXaGlsZSBzb21lIGltcGxlbWVudGF0aW9ucyBjYW4gaWdub3JlIHRoZSBsaW5rIA0KICAg eWV0IHByb2Nlc3MgdGhlIHJlc3Qgb2YgdGhlIExTQSBvdGhlcnMgY2FuIHNpbXBseSBpZ25vcmUg dGhlIExTQS4gVGhpcyANCiAgIGxlYWRzIHRvIGRpZmZlcmVudCBkYXRhYmFzZXMgaW4gdGhlIHJv dXRlcnMgYW5kIGhlbmNlIGRpZmZlcmVudCByb3V0aW5nDQogICB0YWJsZXMuICANCg0KDQoNCjIu ICBDaGFuZ2VzIGZvciBPU1BGdjINCg0KDQogICBTZWN0aW9uIDEyLjQuMSBbT1NQRnYyXSBkZXNj cmliZXMgdGhlIHZhcmlvdXMgdmFsdWVzIHVzZWQgdG8gTGluay10eXBlcyANCiAgIGluIFJvdXRl ciBMU0Ency4gVGhlIHZhbHVlcyAxLCAyLCAzIGFuZCA0IGFyZSBkZWZpbmVkLiANCg0KICAgSWYg YSBSb3V0ZXIgTFNBIHdpdGggYW4gdW5rbm93biBsaW5rLXR5cGUgaXMgYmVpbmcgcHJvY2Vzc2Vk LCB0aGUgbGluayANCiAgIGlzIGlnbm9yZWQgYW5kIHRoZSByZXN0IG9mIHRoZSByb3V0ZXIgTFNB IGlzIHByb2Nlc3NlZCBub3JtYWxseS4NCiAgIA0KICAgU2VjdGlvbiAxNi4xICgyKShhKSBbT1NQ RnYyXSAgc2hvdWxkIG5vdyByZWFkDQoNCiAgICAgICAgICAgICAgICBJZiB0aGlzIGlzIGEgbGlu ayB0byBhIHN0dWIgbmV0d29yaywgZXhhbWluZSB0aGUgbmV4dA0KICAgICAgICAgICAgICAgIGxp bmsgaW4gVidzIExTQS4gIExpbmtzIHRvIHN0dWIgbmV0d29ya3Mgd2lsbCBiZQ0KICAgICAgICAg ICAgICAgIGNvbnNpZGVyZWQgaW4gdGhlIHNlY29uZCBzdGFnZSBvZiB0aGUgc2hvcnRlc3QgcGF0 aA0KICAgICAgICAgICAgICAgIGNhbGN1bGF0aW9uLiBJZiB0aGUgbGluayB0eXBlIGlzIHVua25v d24gZXhhbWluZSB0aGUNCiAgICAgICAgICAgICAgICBuZXh0IGxpbmsgaW4gVidzIExTQS4gVW5r bm93biBMaW5rIFR5cGVzIGFyZSBpZ25vcmVkLg0KDQoNCg0KMy4gIENoYW5nZXMgZm9yIE9TUEZ2 Mw0KDQogICAgDQogICAgU2VjdGlvbiBBLjQuMyBbT1NQRnYzXSBkZXNjcmliZWQgdGhlIHZhcmlv dXMgdmFsdWVzIG9mIExpbmstdHlwZXMgaW4gDQogICAgUm91dGVyIExTQSdzLyBUaGUgdmFsdWVz IDEsIDIgYW5kIDQgYXJlIGRlZmluZWQgdG8gYmUgdXNlZCBpbiByb3V0aW5nIA0KICAgIHRhYmxl IGNhbGN1bGF0aW9ucywgd2hpbGUgMyBpcyByZXNlcnZlZC4NCg0KDQoNCk1hbnJhbCwgICAgICAg ICAgICBFeHBpcmVzIE1heSAyNiwgMjAwNSAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAy XQ0KSW50ZXJuZXQtRHJhZnQgICAgIFRyZWF0aW5nIHVua25vd24gUm91dGVyLUxTQSBsaW5rIHR5 cGVzICAgTm92ZW1iZXIgMjAwNA0KDQoNCg0KICAgIElmIGEgUm91dGVyLUxTQSB3aXRoIGFuIHVu a25vd24gb3IgcmVzZXJ2ZWQgbGluay10eXBlIGlzIGJlaW5nIHByb2Nlc3NlZCwgDQogICAgdGhl IGxpbmsgaXMgaWdub3JlZCBhbmQgdGhlIHJlc3Qgb2YgdGhlIHJvdXRlciBMU0EgaXMgcHJvY2Vz c2VkIG5vcm1hbGx5Lg0KDQogICAgU2VjdGlvbiAzLjguMSBbT1NQRnYzXSByZW1haW5zIHVuY2hh bmdlZCBhcyBpdCBSZWZlcnMgdG8gU2VjdGlvbiAxNi4xLA0KICAgIFtPU1BGdjJdLg0KDQo0LiBG dXR1cmUgRXh0ZW5zaW9ucyB0byBMaW5rLXR5cGUNCg0KDQogICBBcyB0aGUgYmVoYXZpb3IgZm9y IHRyZWF0aW5nIGFuIHVua25vd24gTGluay10eXBlIGlzIGRlZmluZWQsIGV4dGVuc2lvbnMgdG8N CiAgIExpbmstdHlwZSBhcmUgbm93IHBvc3NpYmxlLg0KDQogICBBbnkgZnV0dXJlIGV4dGVuc2lv bnMgU0hPVUxEIG5vdCBjYXVzZSBhbnkgY2hhbmdlIGluIHJvdXRpbmcgdGFibGUgDQogICBjYWxj dWxhdGlvbnMuIFN1Y2ggYSBjaGFuZ2UgY2FuIHJlc3VsdCBpbiByb3V0aW5nIGxvb3BzIGJlY2F1 c2UgdGhlIHJvdXRlcnMNCiAgIHVuYXdhcmUgb2YgdGhlIGV4dGVuc2lvbiB3aWxsIGlnbm9yZSB0 aGUgbGluay4NCg0KDQo1LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KDQogICBUaGlzIGRv Y3VtZW50IGRvZXNuJ3QgcmFpc2UgYW55IG5ldyBzZWN1cml0eSBjb25jZXJucyBvdGhlciB0aGFu DQogICB0aG9zZSBjb3ZlcmVkIGluIFtPU1BGdjJdIGFuZCBbT1NQRnYzXS4NCg0KDQo2LiAgSUFO QSBDb25zaWRlcmF0aW9ucw0KDQogICAgDQogICAgVGhpcyBkb2N1bWVudCBkb2Vzbid0IHJhaXNl IGFueSBuZXcgSUFOQSBjb25zaWRlcmF0aW9ucy4NCiAgICANCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KTWFucmFsLCAgICAgICAgICAgIEV4cGlyZXMgTWF5IDI2LCAyMDA1ICAgICAg ICAgICAgICAgICAgICAgICAgIFtQYWdlIDNdDQpJbnRlcm5ldC1EcmFmdCAgICAgVHJlYXRpbmcg dW5rbm93biBSb3V0ZXItTFNBIGxpbmsgdHlwZXMgICBOb3ZlbWJlciAyMDA0DQoNCg0KNy4gIE5v cm1hdGl2ZSBSZWZlcmVuY2VzDQoNCg0KICAgW09TUEZ2Ml0gICBNb3ksIEouLCAiT1NQRiBWZXJz aW9uIDIiLCBSRkMgMjMyOCwgQXByaWwgMTk5OC4NCg0KDQogICBbT1NQRnYzXSAgIE1veSwgSi4s IEZlcmd1c29uLCBELiBhbmQgUi4gQ29sdG9uLCAiT1NQRiBmb3IgSVB2NiIsIFJGQw0KICAgICAg ICAgICAgICAyNzQwLCBEZWNlbWJlciAxOTk5Lg0KDQoNCg0KQXV0aG9ycycgQWRkcmVzc2VzDQoN Cg0KICAgVmlzaHdhcyBNYW5yYWwNCiAgIFNpTmV0dCBDb3JwDQogICBCYW5nYWxvcmUNCiAgIElu ZGlhDQoNCiAgIEVNYWlsOiB2aXNod2FzQHNpbmV0dC5jb20NCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpNYW5yYWwsICAgICAgICAgICAgRXhwaXJl cyBNYXkgMjYsIDIwMDUgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0NCkludGVybmV0 LURyYWZ0ICAgICBUcmVhdGluZyB1bmtub3duIFJvdXRlci1MU0EgbGluayB0eXBlcyAgIE5vdmVt YmVyIDIwMDQNCg0KDQoNCkFwcGVuZGl4IEEuICBBY2tub3dsZWRnbWVudHMNCg0KDQogICBNYW55 IHRoYW5rcyB0byBBY2VlIExpbmRlbSwgVG9ueSBQcnp5Z2llbmRhLCBQYWRtYSBQLiBhbmQgU2lu YSBNaXJ0b3JhYmkNCiAgIGZvciBpbml0aWF0aW5nIHRoZSBkaXNjdXNzaW9uLg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpNYW5yYWwsICAgICAgICAgICAgRXhwaXJlcyBNYXkg MjYsIDIwMDUgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNV0NCkludGVybmV0LURyYWZ0 ICAgICBUcmVhdGluZyB1bmtub3duIFJvdXRlci1MU0EgbGluayB0eXBlcyAgIE5vdmVtYmVyIDIw MDQNCg0KDQoNCkludGVsbGVjdHVhbCBQcm9wZXJ0eSBTdGF0ZW1lbnQNCg0KDQogICBUaGUgSUVU RiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9mIGFu eQ0KICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBvdGhlciByaWdodHMgdGhhdCBt aWdodCBiZSBjbGFpbWVkIHRvDQogICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1 c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVkIGluDQogICB0aGlzIGRvY3VtZW50IG9yIHRo ZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMNCiAgIG1pZ2h0 IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5vciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0 IGhhcw0KICAgbWFkZSBhbnkgaW5kZXBlbmRlbnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNo IHJpZ2h0cy4gIEluZm9ybWF0aW9uDQogICBvbiB0aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3Qg dG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2FuIGJlDQogICBmb3VuZCBpbiBCQ1AgNzggYW5k IEJDUCA3OS4NCg0KDQogICBDb3BpZXMgb2YgSVBSIGRpc2Nsb3N1cmVzIG1hZGUgdG8gdGhlIElF VEYgU2VjcmV0YXJpYXQgYW5kIGFueQ0KICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBt YWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbg0KICAgYXR0ZW1wdCBtYWRlIHRvIG9i dGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mDQogICBz dWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRlcnMgb3IgdXNlcnMgb2YgdGhpcw0K ICAgc3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQ UiByZXBvc2l0b3J5IGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL2lwci4NCg0KDQogICBUaGUg SUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRvIGJyaW5nIHRvIGl0cyBhdHRlbnRp b24gYW55DQogICBjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9y IG90aGVyIHByb3ByaWV0YXJ5DQogICByaWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0 aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1lbnQNCiAgIHRoaXMgc3RhbmRhcmQuICBQbGVh c2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIElFVEYgYXQNCiAgIGlldGYtaXByQGll dGYub3JnLg0KDQoNCg0KRGlzY2xhaW1lciBvZiBWYWxpZGl0eQ0KDQoNCiAgIFRoaXMgZG9jdW1l bnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGFyZSBwcm92aWRlZCBvbiBh bg0KICAgIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFUSU9O IEhFL1NIRSBSRVBSRVNFTlRTDQogICBPUiBJUyBTUE9OU09SRUQgQlkgKElGIEFOWSksIFRIRSBJ TlRFUk5FVCBTT0NJRVRZIEFORCBUSEUgSU5URVJORVQNCiAgIEVOR0lORUVSSU5HIFRBU0sgRk9S Q0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MgT1IgSU1QTElFRCwNCiAgIElOQ0xV RElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiBUSEUN CiAgIElORk9STUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFO WSBJTVBMSUVEDQogICBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZP UiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4NCg0KDQoNCkNvcHlyaWdodCBTdGF0ZW1lbnQNCg0KDQog ICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA0KS4gIFRoaXMgZG9jdW1l bnQgaXMgc3ViamVjdA0KICAgdG8gdGhlIHJpZ2h0cywgbGljZW5zZXMgYW5kIHJlc3RyaWN0aW9u cyBjb250YWluZWQgaW4gQkNQIDc4LCBhbmQNCiAgIGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVp biwgdGhlIGF1dGhvcnMgcmV0YWluIGFsbCB0aGVpciByaWdodHMuDQoNCg0KDQpBY2tub3dsZWRn bWVudA0KDQoNCiAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9yIGZ1bmN0aW9uIGlzIGN1cnJl bnRseSBwcm92aWRlZCBieSB0aGUNCiAgIEludGVybmV0IFNvY2lldHkuDQoNCg0KDQoNCg0KTWFu cmFsLCAgICAgICAgICAgIEV4cGlyZXMgTWF5IDI2LCAyMDA1ICAgICAgICAgICAgICAgICAgICAg ICAgIFtQYWdlIDZdDQo= ------_=_NextPart_001_01C4D6DD.DB0CB0D8-- From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 30 11:42:03 2004 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 LAA05315 for ; Tue, 30 Nov 2004 11:42:03 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00EF60E8@cherry.ease.lsoft.com>; Tue, 30 Nov 2004 11:42:03 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47358685 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 30 Nov 2004 11:42:01 -0500 Received: from 207.217.121.184 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 30 Nov 2004 11:42:01 -0400 Received: from user-2ivfj3a.dialup.mindspring.com ([165.247.204.106] helo=earthlink.net) by pop-a065c10.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1CZB4i-0004hQ-00 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 30 Nov 2004 08:42:00 -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: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <41ACA33E.6646D8CB@earthlink.net> Date: Tue, 30 Nov 2004 08:43:42 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: router LSA with unknown link type To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Vishwas & Acee, Are we viewing a area that has a mix of routers that understand some link-types beyond 4 and some routers that don't understand them???? In the perfect world shouldn't all the routers within a area treat anything beyond 4 the same way? If this is the case, some option must be created that is communicated that identifies the area's link-types attributes. However... that seemed to be mentioned and dropped.. I aggree the non-stated default should be "ignore". 1) However, should the adj be dropped upon receipt of recv a unknown LSA? This would remove inconsistencies within a area vs allowing the issue to exist in later implimentations. 2) "silently ignored" ; Else should a log entry be present that a LSDB inconsistency exists within the LSDB? To prevent a circular buffer from potentially filling with this msg type, only every so X entries be logged. So, I question what is ment by "silently ignored" and why? IMO, "silently ignore" is probably not appropriate due to the reasons for not knowing why routing Loops can/are existing in the selected routes. 3) should it be mentioned that a DR/BDR be always fully aware of a super-set of link-types, and thus accept them? If not then only the subset will be communicated to "others". Mitchell Erblich ----------------- Vishwas Manral wrote: > > Hi Acee, > > I am attaching the document where I have added, exactly what you have > stated. > > Thanks, > Vishwas > > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee > Lindem > Sent: Tuesday, November 30, 2004 6:30 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: router LSA with unknown link type > > Vishwas Manral wrote: > > > Hi Acee, > > > > Here goes the link: - > > > http://www.ietf.org/internet-drafts/draft-manral-ospf-router-lsa-unknown > -type-00.txt > > > > Do let me know your views? > > Hi Vishwas, > > I feel we should move forward with support for the "silently ignore" > option. I think > that you should add a section with a caveat that states that the > addition of new link types > will still have compatibility implications since there is the potential > for routing loops if > some routers in the area support the new types and others ignore them. > However, > the situation is better than what we have today. > > Thanks, > Acee > > > > > Thanks, > > Vishwas > > > > > ------------------------------------------------------------------------ > > *From:* Mailing List on behalf of Vishwas Manral > > *Sent:* Thu 11/25/2004 9:48 PM > > *To:* OSPF@PEACH.EASE.LSOFT.COM > > *Subject:* Re: router LSA with unknown link type > > > > Hi Acee, > > > > I think we must not forget there can be malicious violations of the > > protocol too, as Tony rightly specified we need to specify the > behavior > > when unexpected or corrupt data is received. > > > > As you stated, I intend to post a short draft on this soon. > > > > Thanks, > > Vishwas > > -----Original Message----- > > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > Acee > > Lindem > > Sent: Thursday, November 25, 2004 10:44 PM > > To: OSPF@PEACH.EASE.LSOFT.COM > > Subject: Re: router LSA with unknown link type > > > > All, > > While it would have been better if RFC 2328 did precisely specify what > > to do with unknown link types the fact of the matter is that it > doesn't. > > IMHO, > > we'd need a short draft in order to formally specify this (or > concensus > > and inclusion > > in the RFC 2740 respin). At this point, the implementation(s) that > > generate(s) > > the unknown link types is/are the ones in violation of the protocol. > > > > Speaking as a WG member, I really don't like the idea of extending the > > protocol > > using unknown link types UNLESS the new types are in fact a different > > type of > > intra-area topological edge in the SPF graph. Once we open it up I can > > envision people > > trying to cram all sorts of non-link data in the router LSA. If we > want > > to extend the > > protocol past what it does today there are cleaner ways of doing it > > (e.g., new LSA types > > supporting TLVs). > > > > Thanks, > > Acee > > > > > > Nitin Kakkar wrote: > > > > >IMHO I can think of two possibilities for this condition > > > > > >1) Some error in LSA creation, which overwrite link type field. : > This > > >should be reflected in checksum error and should be handled such. > > > > > >2) Some new invension which adds to the existing 4 types of Link > Types > > (or > > >support for unknown link types): This Needs to have some common > > >understanding (RFC etc) to handle this. I feel that they can be > handled > > like > > >unknwon LSA's (store & forward only, no routing calc's) > > > > > >HTH > > >Nitin > > > > > >-----Original Message----- > > >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of > Acee > > >Lindem > > >Sent: 2004Ae11OA24EO 21:37 > > >To: OSPF@PEACH.EASE.LSOFT.COM > > >Subject: Re: router LSA with unknown link type > > > > > > > > >Field, Brian wrote: > > > > > > > > > > > >>If a router receives a router LSA that contains several links and > > >>for one of the links, the link type field is not known, should the > > >>router ignore the entire router LSA or just skip this one link? > > >> > > >> > > >> > > >> > > >Hi Brian, > > >Unfortunately, the handling of unknown link types is not specifically > > >defined in RFC 2328. > > >Since links types 1-4 are the only ones defined an implementation > > should > > >probably log > > >the invalid link type (with rate limiting). Whether it ignores the > LSA > > >or just the unknown link is > > >implementation specific. If we were to move forward with link type > > >extension it would not be > > >backward compatible (at least not without knobs or other mechanisms). > > > > > >Thanks, > > >Acee > > > > > > > > > > > >>Thanks > > >>Brian > > >> > > >> > > >> > > > > ------------------------------------------------------------------------ > Name: draft-manral-ospf-router-lsa-unknown-type-01.txt > draft-manral-ospf-router-lsa-unknown-type-01.txt Type: Plain Text (text/plain) > Encoding: base64 > Description: draft-manral-ospf-router-lsa-unknown-type-01.txt From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 30 11:54:06 2004 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 LAA06372 for ; Tue, 30 Nov 2004 11:54:04 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00EF60D3@cherry.ease.lsoft.com>; Tue, 30 Nov 2004 11:54:02 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47359379 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 30 Nov 2004 11:53:59 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 30 Nov 2004 11:53:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4D6FE.45E81E36" Thread-Topic: router LSA with unknown link type thread-index: AcTW/Jy91SMTy0UsRhKeNOSE+DnlswAAQ7L6 Message-ID: Date: Tue, 30 Nov 2004 08:57:26 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: router LSA with unknown link type To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C4D6FE.45E81E36 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mitchell, =20 Good to hear from you and thanks for the comments. The basic idea is = that the flooding happens normally, as is(we do not check if we = understand a link type before flooding forward). This allows new = link-types. =20 The change done is to explicitly state that while doing the routing = table calculations the link needs to be ignored. Maybe I will change the = text to further clarify this. =20 Thanks, Vishwas ________________________________ From: Mailing List on behalf of Erblichs Sent: Tue 11/30/2004 8:43 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: router LSA with unknown link type Vishwas & Acee, Are we viewing a area that has a mix of routers that understand some link-types beyond 4 and some routers that don't understand them???? In the perfect world shouldn't all the routers within a area treat anything beyond 4 the same way? If this is the case, some option must be created that is communicated that identifies the area's link-types attributes. However... that seemed to be mentioned and dropped.. I aggree the non-stated default should be "ignore". 1) However, should the adj be dropped upon receipt of recv a unknown LSA? This would remove inconsistencies within a area vs allowing the issue to exist in later implimentations. 2) "silently ignored" ; Else should a log entry be present that a LSDB inconsistency exists within the LSDB? To prevent a circular buffer from potentially filling with this msg type, only every so X entries be logged. So, I question what is ment by "silently ignored" and why? IMO, "silently ignore" is probably not appropriate due to the reasons for not knowing why routing Loops can/are existing in the selected routes. 3) should it be mentioned that a DR/BDR be always fully aware of a super-set of link-types, and thus accept them? If not then only the subset will be communicated to "others". Mitchell Erblich ----------------- Vishwas Manral wrote: > > Hi Acee, > > I am attaching the document where I have added, exactly what you have > stated. > > Thanks, > Vishwas > > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of = Acee > Lindem > Sent: Tuesday, November 30, 2004 6:30 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: router LSA with unknown link type > > Vishwas Manral wrote: > > > Hi Acee, > > > > Here goes the link: - > > > = http://www.ietf.org/internet-drafts/draft-manral-ospf-router-lsa-unknown > -type-00.txt > > > > Do let me know your views? > > Hi Vishwas, > > I feel we should move forward with support for the "silently ignore" > option. I think > that you should add a section with a caveat that states that the > addition of new link types > will still have compatibility implications since there is the = potential > for routing loops if > some routers in the area support the new types and others ignore them. > However, > the situation is better than what we have today. > > Thanks, > Acee > > > > > Thanks, > > Vishwas > > > > > = ------------------------------------------------------------------------ > > *From:* Mailing List on behalf of Vishwas Manral > > *Sent:* Thu 11/25/2004 9:48 PM > > *To:* OSPF@PEACH.EASE.LSOFT.COM > > *Subject:* Re: router LSA with unknown link type > > > > Hi Acee, > > > > I think we must not forget there can be malicious violations of the > > protocol too, as Tony rightly specified we need to specify the > behavior > > when unexpected or corrupt data is received. > > > > As you stated, I intend to post a short draft on this soon. > > > > Thanks, > > Vishwas > > -----Original Message----- > > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > Acee > > Lindem > > Sent: Thursday, November 25, 2004 10:44 PM > > To: OSPF@PEACH.EASE.LSOFT.COM > > Subject: Re: router LSA with unknown link type > > > > All, > > While it would have been better if RFC 2328 did precisely specify = what > > to do with unknown link types the fact of the matter is that it > doesn't. > > IMHO, > > we'd need a short draft in order to formally specify this (or > concensus > > and inclusion > > in the RFC 2740 respin). At this point, the implementation(s) that > > generate(s) > > the unknown link types is/are the ones in violation of the protocol. > > > > Speaking as a WG member, I really don't like the idea of extending = the > > protocol > > using unknown link types UNLESS the new types are in fact a = different > > type of > > intra-area topological edge in the SPF graph. Once we open it up I = can > > envision people > > trying to cram all sorts of non-link data in the router LSA. If we > want > > to extend the > > protocol past what it does today there are cleaner ways of doing it > > (e.g., new LSA types > > supporting TLVs). > > > > Thanks, > > Acee > > > > > > Nitin Kakkar wrote: > > > > >IMHO I can think of two possibilities for this condition > > > > > >1) Some error in LSA creation, which overwrite link type field. : > This > > >should be reflected in checksum error and should be handled such. > > > > > >2) Some new invension which adds to the existing 4 types of Link > Types > > (or > > >support for unknown link types): This Needs to have some common > > >understanding (RFC etc) to handle this. I feel that they can be > handled > > like > > >unknwon LSA's (store & forward only, no routing calc's) > > > > > >HTH > > >Nitin > > > > > >-----Original Message----- > > >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of > Acee > > >Lindem > > >Sent: 2004Ae11OA24EO 21:37 > > >To: OSPF@PEACH.EASE.LSOFT.COM > > >Subject: Re: router LSA with unknown link type > > > > > > > > >Field, Brian wrote: > > > > > > > > > > > >>If a router receives a router LSA that contains several links and > > >>for one of the links, the link type field is not known, should the > > >>router ignore the entire router LSA or just skip this one link? > > >> > > >> > > >> > > >> > > >Hi Brian, > > >Unfortunately, the handling of unknown link types is not = specifically > > >defined in RFC 2328. > > >Since links types 1-4 are the only ones defined an implementation > > should > > >probably log > > >the invalid link type (with rate limiting). Whether it ignores the > LSA > > >or just the unknown link is > > >implementation specific. If we were to move forward with link type > > >extension it would not be > > >backward compatible (at least not without knobs or other = mechanisms). > > > > > >Thanks, > > >Acee > > > > > > > > > > > >>Thanks > > >>Brian > > >> > > >> > > >> > > > > = ------------------------------------------------------------------------ > Name: = draft-manral-ospf-router-lsa-unknown-type-01.txt > draft-manral-ospf-router-lsa-unknown-type-01.txt Type: Plain = Text (text/plain) > Encoding: base64 > Description: = draft-manral-ospf-router-lsa-unknown-type-01.txt ------_=_NextPart_001_01C4D6FE.45E81E36 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: router LSA with unknown link type=0A= =0A= =0A=
=0A=
Hi = Mitchell,
=0A=
 
=0A=
Good to hear from you and = thanks for the =0A= comments. The basic idea is that the flooding happens normally, = as is(we =0A= do not check if we understand a link type before flooding forward). This = allows =0A= new link-types.
=0A=
 
=0A=
The change done is to explicitly state that while = doing the =0A= routing table calculations the link needs to be ignored. Maybe I will = change the =0A= text to further clarify this.
=0A=
 
=0A=
Thanks,
=0A=
Vishwas
=0A=
=0A=
=0A=
=0A=
From: Mailing List on = behalf of =0A= Erblichs
Sent: Tue 11/30/2004 8:43 AM
To: =0A= OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: router LSA with unknown = link =0A= type

=0A=
=0A=

Vishwas & =0A= Acee,

        Are we viewing a = area =0A= that has a mix of routers
        = that =0A= understand some link-types beyond 4 and =0A= some
        routers that don't = understand =0A= them????

        In the = perfect world =0A= shouldn't all the routers
        = within a =0A= area treat anything beyond 4 the same =0A= way?

        If this is the = case, some =0A= option must be created
        = that is =0A= communicated that identifies the =0A= area's
        link-types = attributes. =0A= However... that seemed to
        = be =0A= mentioned and = dropped..

        I =0A= aggree the non-stated default should be =0A= "ignore".
        1) However, = should the =0A= adj be dropped upon receipt = of
        =0A= recv a unknown LSA? This would remove =0A= inconsistencies
        within a = area vs =0A= allowing the issue to exist in =0A= later
        =0A= implimentations.

        2) = "silently =0A= ignored" ; Else should a log entry be =0A= present
         that a LSDB =0A= inconsistency exists within the LSDB? =0A= To
        prevent a circular = buffer from =0A= potentially filling with
        = this msg =0A= type, only every so X entries be logged. So, =0A= I
        question what is ment by =0A= "silently ignored" and why? = IMO,
        =0A= "silently ignore" is probably not appropriate due to =0A= the
        reasons for not = knowing why =0A= routing Loops can/are = existing
        in =0A= the selected routes.

        = 3) should =0A= it be mentioned that a DR/BDR be always =0A= fully
        aware of a super-set = of =0A= link-types, and thus = accept
        them? =0A= If not then only the subset will be =0A= communicated
        to =0A= "others".

        Mitchell =0A= Erblich
        =0A= -----------------


Vishwas Manral wrote:
>
> Hi =0A= Acee,
>
> I am attaching the document where I have added, = exactly =0A= what you have
> stated.
>
> Thanks,
> =0A= Vishwas
>
> -----Original Message-----
> From: Mailing = List =0A= [mailto:OSPF@PEACH.EASE.LSOFT.CO= M] On =0A= Behalf Of Acee
> Lindem
> Sent: Tuesday, November 30, 2004 = 6:30 =0A= PM
> To: OSPF@PEACH.EASE.LSOFT.COM
> Subject: Re: router LSA = with =0A= unknown link type
>
> Vishwas Manral wrote:
>
> = > Hi =0A= Acee,
> >
> > Here goes the link: -
> = >
> http://www.ietf.org/internet-drafts/draft-manral-ospf-router-lsa= -unknown
> =0A= -type-00.txt
> >
> > Do let me know your =0A= views?
>
> Hi Vishwas,
>
> I feel we should move = forward =0A= with support for the "silently ignore"
> option. I think
> = that you =0A= should add a section with a caveat that states that the
> addition = of new =0A= link types
> will still have compatibility implications since = there is the =0A= potential
> for routing loops if
> some routers in the area = support =0A= the new types and others ignore them.
> However,
> the = situation is =0A= better than what we have today.
>
> Thanks,
> =0A= Acee
>
> >
> > Thanks,
> > = Vishwas
> =0A= >
> >
> =0A= ------------------------------------------------------------------------<= BR>> =0A= > *From:* Mailing List on behalf of Vishwas Manral
> > = *Sent:* Thu =0A= 11/25/2004 9:48 PM
> > *To:* OSPF@PEACH.EASE.LSOFT.COM
> = > =0A= *Subject:* Re: router LSA with unknown link type
> >
> = > Hi =0A= Acee,
> >
> > I think we must not forget there can be =0A= malicious violations of the
> > protocol too, as Tony rightly = specified =0A= we need to specify the
> behavior
> > when unexpected or = corrupt =0A= data is received.
> >
> > As you stated, I intend to = post a =0A= short draft on this soon.
> >
> > Thanks,
> > =0A= Vishwas
> > -----Original Message-----
> > From: = Mailing List =0A= [mailto:OSPF@PEACH.EASE.LSOFT.CO= M] On =0A= Behalf Of
> Acee
> > Lindem
> > Sent: Thursday, = November =0A= 25, 2004 10:44 PM
> > To: OSPF@PEACH.EASE.LSOFT.COM
> = > =0A= Subject: Re: router LSA with unknown link type
> >
> > =0A= All,
> > While it would have been better if RFC 2328 did = precisely =0A= specify what
> > to do with unknown link types the fact of the = matter =0A= is that it
> doesn't.
> > IMHO,
> > we'd need a = short =0A= draft in order to formally specify this (or
> concensus
> = > and =0A= inclusion
> > in the RFC 2740 respin). At this point, the =0A= implementation(s) that
> > generate(s)
> > the unknown = link =0A= types is/are the ones in violation of the protocol.
> >
> = > =0A= Speaking as a WG member, I really don't like the idea of extending = the
> =0A= > protocol
> > using unknown link types UNLESS the new types = are in =0A= fact a different
> > type of
> > intra-area = topological edge =0A= in the SPF graph. Once we open it up I can
> > envision = people
> =0A= > trying to cram all sorts of non-link data in the router LSA. If = we
> =0A= want
> > to extend the
> > protocol past what it does = today =0A= there are cleaner ways of doing it
> > (e.g., new LSA = types
> =0A= > supporting TLVs).
> >
> > Thanks,
> > =0A= Acee
> >
> >
> > Nitin Kakkar wrote:
> =0A= >
> > >IMHO I can think of two possibilities for this =0A= condition
> > >
> > >1) Some error in LSA = creation, =0A= which overwrite link type field. :
> This
> > >should = be =0A= reflected in checksum error and should be handled such.
> > =0A= >
> > >2) Some new invension which adds to the existing 4 = types =0A= of Link
> Types
> > (or
> > >support for = unknown link =0A= types): This Needs to have some common
> > >understanding = (RFC etc) =0A= to handle this. I feel that they can be
> handled
> > =0A= like
> > >unknwon LSA's (store & forward only, no = routing =0A= calc's)
> > >
> > >HTH
> > = >Nitin
> =0A= > >
> > >-----Original Message-----
> > = >From: =0A= Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.CO= M]On =0A= Behalf Of
> Acee
> > >Lindem
> > >Sent: =0A= 2004Ae11OA24EO 21:37
> > >To: = OSPF@PEACH.EASE.LSOFT.COM
> > =0A= >Subject: Re: router LSA with unknown link type
> > = >
> =0A= > >
> > >Field, Brian wrote:
> > >
> = > =0A= >
> > >
> > >>If a router receives a = router LSA =0A= that contains several links and
> > >>for one of the = links, the =0A= link type field is not known, should the
> > >>router = ignore the =0A= entire router LSA or just skip this one link?
> > = >>
> > =0A= >>
> > >>
> > >>
> > >Hi =0A= Brian,
> > >Unfortunately, the handling of unknown link = types is not =0A= specifically
> > >defined in RFC 2328.
> > = >Since links =0A= types 1-4 are the only ones defined an implementation
> > =0A= should
> > >probably log
> > >the invalid link = type =0A= (with rate limiting). Whether it ignores the
> LSA
> > = >or =0A= just the unknown link is
> > >implementation specific. If we = were to =0A= move forward with link type
> > >extension it would not = be
> =0A= > >backward compatible (at least not without knobs or other =0A= mechanisms).
> > >
> > >Thanks,
> > =0A= >Acee
> > >
> > >
> > >
> = > =0A= >>Thanks
> > >>Brian
> > >>
> = > =0A= >>
> > >>
> >
>
>   =0A= ------------------------------------------------------------------------<= BR>>           =             &= nbsp;           &n= bsp;           &nb= sp;           =0A= Name: = draft-manral-ospf-router-lsa-unknown-type-01.txt
>   = ; =0A= draft-manral-ospf-router-lsa-unknown-type-01.txt    &= nbsp;  =0A= Type: Plain Text =0A= (text/plain)
>         = ;            =             &= nbsp;           &n= bsp;         =0A= Encoding: =0A= base64
>          = ;            =             &= nbsp;           &n= bsp;     =0A= Description: =0A= draft-manral-ospf-router-lsa-unknown-type-01.txt

=0A= =0A= =0A= ------_=_NextPart_001_01C4D6FE.45E81E36-- From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 30 14:24:38 2004 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 OAA22667 for ; Tue, 30 Nov 2004 14:24:38 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00EF62FB@cherry.ease.lsoft.com>; Tue, 30 Nov 2004 14:24:35 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47374053 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 30 Nov 2004 14:24:31 -0500 Received: from 207.217.121.183 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 30 Nov 2004 14:24:30 -0400 Received: from user-2ivfj3a.dialup.mindspring.com ([165.247.204.106] helo=earthlink.net) by pop-a065c05.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1CZDby-000634-00 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 30 Nov 2004 11:24:30 -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: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <41ACC953.253F37B@earthlink.net> Date: Tue, 30 Nov 2004 11:26:11 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: router LSA with unknown link type To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Vishwas Manral, Oooo.. Yes, it will be a bit more work, but yes, the acceptance and flooding of unknowns should be limited to Opaque LSAs, IMO, Why?? Answer: -------- 1) The removal of unknown Link-types should decrease the size of the LSDB.. This becomes most important with stub, etc routers/areas. 2) It should reduce the size of bandwidth due to flooding with a large number of LSAs with unknown link-types. This does increase the amount of work to rebuild the LSA. 3) if 1 router has unknown link-types then all the routers within the area are required to alloc mem for the useless info. 4) We have 0 chance to do a minimal amount of due-diligence to verify the data. Don't insert garbage (useless info) into the LSDB. 5) You are populating the LSDB with unknown link-types and each time you run your SPF calcs, you need to skip unknown link-types? ***6) If some routers include unknowns (beyond #4) in the calcs(because they understand) a superset and some don't, their could be routing issues. 7) You can log and flag unknown values as they arrive if you do #4. Thus, if you don't flood known link-types, etc via the DR/BDR the LSDB shouldn't become mixed with unknowns on the non-orginating routers. Ex: So, only a flag NEED be used on these two non-other routers to determine the acceptance of unknowns in this environment with respect to flooding and initial database synch. I think this forces a full-restart if/when the router's capability is changed to include/exclude the unknowns in the LSDB. Thus, IMO a unknown flag should be supported. ---------------- Mitchell Erblich ----------------- > Vishwas Manral wrote: > > Hi Mitchell, > > Good to hear from you and thanks for the comments. The basic idea is > that the flooding happens normally, as is(we do not check if we > understand a link type before flooding forward). This allows new > link-types. > > The change done is to explicitly state that while doing the routing > table calculations the link needs to be ignored. Maybe I will change > the text to further clarify this. > > Thanks, > Vishwas > ---------------------------------------------------------------------- > From: Mailing List on behalf of Erblichs > Sent: Tue 11/30/2004 8:43 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: router LSA with unknown link type > > Vishwas & Acee, > > Are we viewing a area that has a mix of routers > that understand some link-types beyond 4 and some > routers that don't understand them???? > > In the perfect world shouldn't all the routers > within a area treat anything beyond 4 the same way? > > If this is the case, some option must be created > that is communicated that identifies the area's > link-types attributes. However... that seemed to > be mentioned and dropped.. > > I aggree the non-stated default should be "ignore". > 1) However, should the adj be dropped upon receipt of > recv a unknown LSA? This would remove inconsistencies > within a area vs allowing the issue to exist in later > implimentations. > > 2) "silently ignored" ; Else should a log entry be present > that a LSDB inconsistency exists within the LSDB? To > prevent a circular buffer from potentially filling with > this msg type, only every so X entries be logged. So, I > question what is ment by "silently ignored" and why? IMO, > "silently ignore" is probably not appropriate due to the > reasons for not knowing why routing Loops can/are existing > in the selected routes. > > 3) should it be mentioned that a DR/BDR be always fully > aware of a super-set of link-types, and thus accept > them? If not then only the subset will be communicated > to "others". > > Mitchell Erblich > ----------------- > > Vishwas Manral wrote: > > > > Hi Acee, > > > > I am attaching the document where I have added, exactly what you > have > > stated. > > > > Thanks, > > Vishwas > > > > -----Original Message----- > > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > Acee > > Lindem > > Sent: Tuesday, November 30, 2004 6:30 PM > > To: OSPF@PEACH.EASE.LSOFT.COM > > Subject: Re: router LSA with unknown link type > > > > Vishwas Manral wrote: > > > > > Hi Acee, > > > > > > Here goes the link: - > > > > > > http://www.ietf.org/internet-drafts/draft-manral-ospf-router-lsa-unknown > > -type-00.txt > > > > > > Do let me know your views? > > > > Hi Vishwas, > > > > I feel we should move forward with support for the "silently ignore" > > option. I think > > that you should add a section with a caveat that states that the > > addition of new link types > > will still have compatibility implications since there is the > potential > > for routing loops if > > some routers in the area support the new types and others ignore > them. > > However, > > the situation is better than what we have today. > > > > Thanks, > > Acee > > > > > > > > Thanks, > > > Vishwas > > > > > > > > > ------------------------------------------------------------------------ > > > *From:* Mailing List on behalf of Vishwas Manral > > > *Sent:* Thu 11/25/2004 9:48 PM > > > *To:* OSPF@PEACH.EASE.LSOFT.COM > > > *Subject:* Re: router LSA with unknown link type > > > > > > Hi Acee, > > > > > > I think we must not forget there can be malicious violations of > the > > > protocol too, as Tony rightly specified we need to specify the > > behavior > > > when unexpected or corrupt data is received. > > > > > > As you stated, I intend to post a short draft on this soon. > > > > > > Thanks, > > > Vishwas > > > -----Original Message----- > > > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > > Acee > > > Lindem > > > Sent: Thursday, November 25, 2004 10:44 PM > > > To: OSPF@PEACH.EASE.LSOFT.COM > > > Subject: Re: router LSA with unknown link type > > > > > > All, > > > While it would have been better if RFC 2328 did precisely specify > what > > > to do with unknown link types the fact of the matter is that it > > doesn't. > > > IMHO, > > > we'd need a short draft in order to formally specify this (or > > concensus > > > and inclusion > > > in the RFC 2740 respin). At this point, the implementation(s) that > > > generate(s) > > > the unknown link types is/are the ones in violation of the > protocol. > > > > > > Speaking as a WG member, I really don't like the idea of extending > the > > > protocol > > > using unknown link types UNLESS the new types are in fact a > different > > > type of > > > intra-area topological edge in the SPF graph. Once we open it up I > can > > > envision people > > > trying to cram all sorts of non-link data in the router LSA. If we > > want > > > to extend the > > > protocol past what it does today there are cleaner ways of doing > it > > > (e.g., new LSA types > > > supporting TLVs). > > > > > > Thanks, > > > Acee > > > > > > > > > Nitin Kakkar wrote: > > > > > > >IMHO I can think of two possibilities for this condition > > > > > > > >1) Some error in LSA creation, which overwrite link type field. : > > This > > > >should be reflected in checksum error and should be handled such. > > > > > > > >2) Some new invension which adds to the existing 4 types of Link > > Types > > > (or > > > >support for unknown link types): This Needs to have some common > > > >understanding (RFC etc) to handle this. I feel that they can be > > handled > > > like > > > >unknwon LSA's (store & forward only, no routing calc's) > > > > > > > >HTH > > > >Nitin > > > > > > > >-----Original Message----- > > > >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of > > Acee > > > >Lindem > > > >Sent: 2004Ae11OA24EO 21:37 > > > >To: OSPF@PEACH.EASE.LSOFT.COM > > > >Subject: Re: router LSA with unknown link type > > > > > > > > > > > >Field, Brian wrote: > > > > > > > > > > > > > > > >>If a router receives a router LSA that contains several links > and > > > >>for one of the links, the link type field is not known, should > the > > > >>router ignore the entire router LSA or just skip this one link? > > > >> > > > >> > > > >> > > > >> > > > >Hi Brian, > > > >Unfortunately, the handling of unknown link types is not > specifically > > > >defined in RFC 2328. > > > >Since links types 1-4 are the only ones defined an implementation > > > should > > > >probably log > > > >the invalid link type (with rate limiting). Whether it ignores > the > > LSA > > > >or just the unknown link is > > > >implementation specific. If we were to move forward with link > type > > > >extension it would not be > > > >backward compatible (at least not without knobs or other > mechanisms). > > > > > > > >Thanks, > > > >Acee > > > > > > > > > > > > > > > >>Thanks > > > >>Brian > > > >> > > > >> > > > >> > > > > > > > > ------------------------------------------------------------------------ > > Name: > draft-manral-ospf-router-lsa-unknown-type-01.txt > > draft-manral-ospf-router-lsa-unknown-type-01.txt Type: > Plain Text (text/plain) > > Encoding: > base64 > > Description: > draft-manral-ospf-router-lsa-unknown-type-01.txt From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 30 14:54:46 2004 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 OAA26942 for ; Tue, 30 Nov 2004 14:54:46 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00EF653E@cherry.ease.lsoft.com>; Tue, 30 Nov 2004 14:54:46 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47379196 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 30 Nov 2004 14:54:41 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 30 Nov 2004 14:54:41 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 30 Nov 2004 14:54:45 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAUJsfFL026956 for ; Tue, 30 Nov 2004 14:54:42 -0500 (EST) Received: from [64.102.48.185] (dhcp-64-102-48-185.cisco.com [64.102.48.185]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BDR52059; Tue, 30 Nov 2004 11:54:36 -0800 (PST) User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <41ACC953.253F37B@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41ACCFFC.9030600@cisco.com> Date: Tue, 30 Nov 2004 14:54:36 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: router LSA with unknown link type To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <41ACC953.253F37B@earthlink.net> Precedence: list Content-Transfer-Encoding: 7bit Erblichs wrote: >Vishwas Manral, > > Oooo.. > > Yes, it will be a bit more work, but yes, the > acceptance and flooding of unknowns should be > limited to Opaque LSAs, IMO, Why?? > > The reason for limiting this draft to unknown link types is that this has never been formally specified in the OSPFv2/OSPFv3 specification. The handling of unknown LSA types is defined in both the OSPFv2 and OSPFv3 specifications. The fact that we are discussing explicit defining what to do with unknown link types is not a license to change OSPFv2 unknown LSA type handling. > Answer: > -------- > > 1) The removal of unknown Link-types should > decrease the size of the LSDB.. This becomes most > important with stub, etc routers/areas. > > 2) It should reduce the size of bandwidth due > to flooding with a large number of LSAs with > unknown link-types. This does increase the > amount of work to rebuild the LSA. > > 3) if 1 router has unknown link-types then > all the routers within the area are > required to alloc mem for the useless > info. > > 4) We have 0 chance to do a minimal amount of > due-diligence to verify the data. Don't > insert garbage (useless info) into the LSDB. > > 5) You are populating the LSDB with unknown link-types > and each time you run your SPF calcs, you need to > skip unknown link-types? > > ***6) If some routers include unknowns (beyond #4) > in the calcs(because they understand) a > superset and some don't, their could be > routing issues. > > 7) You can log and flag unknown values as they > arrive if you do #4. > > Thus, if you don't flood known link-types, etc > via the DR/BDR the LSDB shouldn't become mixed > with unknowns on the non-orginating routers. > > Ex: > So, only a flag NEED be used on these two non-other > routers to determine the acceptance of unknowns in > this environment with respect to flooding and initial > database synch. > > I think this forces a full-restart if/when the router's > capability is changed to include/exclude the unknowns > in the LSDB. Thus, IMO a unknown flag should be > supported. > > ---------------- > > > Mitchell Erblich > ----------------- > > > > > >>Vishwas Manral wrote: >> >>Hi Mitchell, >> >>Good to hear from you and thanks for the comments. The basic idea is >>that the flooding happens normally, as is(we do not check if we >>understand a link type before flooding forward). This allows new >>link-types. >> >>The change done is to explicitly state that while doing the routing >>table calculations the link needs to be ignored. Maybe I will change >>the text to further clarify this. >> >>Thanks, >>Vishwas >>---------------------------------------------------------------------- >>From: Mailing List on behalf of Erblichs >>Sent: Tue 11/30/2004 8:43 AM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: router LSA with unknown link type >> >>Vishwas & Acee, >> >> Are we viewing a area that has a mix of routers >> that understand some link-types beyond 4 and some >> routers that don't understand them???? >> >> In the perfect world shouldn't all the routers >> within a area treat anything beyond 4 the same way? >> >> If this is the case, some option must be created >> that is communicated that identifies the area's >> link-types attributes. However... that seemed to >> be mentioned and dropped.. >> >> I aggree the non-stated default should be "ignore". >> 1) However, should the adj be dropped upon receipt of >> recv a unknown LSA? This would remove inconsistencies >> within a area vs allowing the issue to exist in later >> implimentations. >> >> 2) "silently ignored" ; Else should a log entry be present >> that a LSDB inconsistency exists within the LSDB? To >> prevent a circular buffer from potentially filling with >> this msg type, only every so X entries be logged. So, I >> question what is ment by "silently ignored" and why? IMO, >> "silently ignore" is probably not appropriate due to the >> reasons for not knowing why routing Loops can/are existing >> in the selected routes. >> >> 3) should it be mentioned that a DR/BDR be always fully >> aware of a super-set of link-types, and thus accept >> them? If not then only the subset will be communicated >> to "others". >> >> Mitchell Erblich >> ----------------- >> >>Vishwas Manral wrote: >> >> >>>Hi Acee, >>> >>>I am attaching the document where I have added, exactly what you >>> >>> >>have >> >> >>>stated. >>> >>>Thanks, >>>Vishwas >>> >>>-----Original Message----- >>>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >>> >>> >>Acee >> >> >>>Lindem >>>Sent: Tuesday, November 30, 2004 6:30 PM >>>To: OSPF@PEACH.EASE.LSOFT.COM >>>Subject: Re: router LSA with unknown link type >>> >>>Vishwas Manral wrote: >>> >>> >>> >>>>Hi Acee, >>>> >>>>Here goes the link: - >>>> >>>> >>>> >>http://www.ietf.org/internet-drafts/draft-manral-ospf-router-lsa-unknown >> >> >>>-type-00.txt >>> >>> >>>>Do let me know your views? >>>> >>>> >>>Hi Vishwas, >>> >>>I feel we should move forward with support for the "silently ignore" >>>option. I think >>>that you should add a section with a caveat that states that the >>>addition of new link types >>>will still have compatibility implications since there is the >>> >>> >>potential >> >> >>>for routing loops if >>>some routers in the area support the new types and others ignore >>> >>> >>them. >> >> >>>However, >>>the situation is better than what we have today. >>> >>>Thanks, >>>Acee >>> >>> >>> >>>>Thanks, >>>>Vishwas >>>> >>>> >>>> >>>> >>------------------------------------------------------------------------ >> >> >>>>*From:* Mailing List on behalf of Vishwas Manral >>>>*Sent:* Thu 11/25/2004 9:48 PM >>>>*To:* OSPF@PEACH.EASE.LSOFT.COM >>>>*Subject:* Re: router LSA with unknown link type >>>> >>>>Hi Acee, >>>> >>>>I think we must not forget there can be malicious violations of >>>> >>>> >>the >> >> >>>>protocol too, as Tony rightly specified we need to specify the >>>> >>>> >>>behavior >>> >>> >>>>when unexpected or corrupt data is received. >>>> >>>>As you stated, I intend to post a short draft on this soon. >>>> >>>>Thanks, >>>>Vishwas >>>>-----Original Message----- >>>>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >>>> >>>> >>>Acee >>> >>> >>>>Lindem >>>>Sent: Thursday, November 25, 2004 10:44 PM >>>>To: OSPF@PEACH.EASE.LSOFT.COM >>>>Subject: Re: router LSA with unknown link type >>>> >>>>All, >>>>While it would have been better if RFC 2328 did precisely specify >>>> >>>> >>what >> >> >>>>to do with unknown link types the fact of the matter is that it >>>> >>>> >>>doesn't. >>> >>> >>>>IMHO, >>>>we'd need a short draft in order to formally specify this (or >>>> >>>> >>>concensus >>> >>> >>>>and inclusion >>>>in the RFC 2740 respin). At this point, the implementation(s) that >>>>generate(s) >>>>the unknown link types is/are the ones in violation of the >>>> >>>> >>protocol. >> >> >>>>Speaking as a WG member, I really don't like the idea of extending >>>> >>>> >>the >> >> >>>>protocol >>>>using unknown link types UNLESS the new types are in fact a >>>> >>>> >>different >> >> >>>>type of >>>>intra-area topological edge in the SPF graph. Once we open it up I >>>> >>>> >>can >> >> >>>>envision people >>>>trying to cram all sorts of non-link data in the router LSA. If we >>>> >>>> >>>want >>> >>> >>>>to extend the >>>>protocol past what it does today there are cleaner ways of doing >>>> >>>> >>it >> >> >>>>(e.g., new LSA types >>>>supporting TLVs). >>>> >>>>Thanks, >>>>Acee >>>> >>>> >>>>Nitin Kakkar wrote: >>>> >>>> >>>> >>>>>IMHO I can think of two possibilities for this condition >>>>> >>>>>1) Some error in LSA creation, which overwrite link type field. : >>>>> >>>>> >>>This >>> >>> >>>>>should be reflected in checksum error and should be handled such. >>>>> >>>>>2) Some new invension which adds to the existing 4 types of Link >>>>> >>>>> >>>Types >>> >>> >>>>(or >>>> >>>> >>>>>support for unknown link types): This Needs to have some common >>>>>understanding (RFC etc) to handle this. I feel that they can be >>>>> >>>>> >>>handled >>> >>> >>>>like >>>> >>>> >>>>>unknwon LSA's (store & forward only, no routing calc's) >>>>> >>>>>HTH >>>>>Nitin >>>>> >>>>>-----Original Message----- >>>>>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of >>>>> >>>>> >>>Acee >>> >>> >>>>>Lindem >>>>>Sent: 2004Ae11OA24EO 21:37 >>>>>To: OSPF@PEACH.EASE.LSOFT.COM >>>>>Subject: Re: router LSA with unknown link type >>>>> >>>>> >>>>>Field, Brian wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>If a router receives a router LSA that contains several links >>>>>> >>>>>> >>and >> >> >>>>>>for one of the links, the link type field is not known, should >>>>>> >>>>>> >>the >> >> >>>>>>router ignore the entire router LSA or just skip this one link? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>Hi Brian, >>>>>Unfortunately, the handling of unknown link types is not >>>>> >>>>> >>specifically >> >> >>>>>defined in RFC 2328. >>>>>Since links types 1-4 are the only ones defined an implementation >>>>> >>>>> >>>>should >>>> >>>> >>>>>probably log >>>>>the invalid link type (with rate limiting). Whether it ignores >>>>> >>>>> >>the >> >> >>>LSA >>> >>> >>>>>or just the unknown link is >>>>>implementation specific. If we were to move forward with link >>>>> >>>>> >>type >> >> >>>>>extension it would not be >>>>>backward compatible (at least not without knobs or other >>>>> >>>>> >>mechanisms). >> >> >>>>>Thanks, >>>>>Acee >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Thanks >>>>>>Brian >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>> >>> >>------------------------------------------------------------------------ >> >> >>> Name: >>> >>> >>draft-manral-ospf-router-lsa-unknown-type-01.txt >> >> >>> draft-manral-ospf-router-lsa-unknown-type-01.txt Type: >>> >>> >>Plain Text (text/plain) >> >> >>> Encoding: >>> >>> >>base64 >> >> >>> Description: >>> >>> >>draft-manral-ospf-router-lsa-unknown-type-01.txt >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Nov 30 15:21:31 2004 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 PAA00280 for ; Tue, 30 Nov 2004 15:21:30 -0500 (EST) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00EF6400@cherry.ease.lsoft.com>; Tue, 30 Nov 2004 15:21:29 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47381319 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 30 Nov 2004 15:21:21 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 30 Nov 2004 15:11:21 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28927; Tue, 30 Nov 2004 15:11:16 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200411302011.PAA28927@ietf.org> Date: Tue, 30 Nov 2004 15:11:16 -0500 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-ospfv3-update-00.txt Comments: To: i-d-announce@ietf.org 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 : OSPF for IPv6 Author(s) : D. Ferguson, et al. Filename : draft-ietf-ospf-ospfv3-update-00.txt Pages : 82 Date : 2004-11-30 This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. Changes between OSPF for IPv4 and this document include the following. Addressing semantics have been removed from OSPF packets and the basic LSAs. New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis, instead of on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol itself, instead relying on IPv6's Authentication Header and Encapsulating Security Payload. Most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4, even with the larger IPv6 addresses. Most fields and packet-size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible. All of OSPF for IPv4's optional capabilities, including on-demand circuit support, NSSA areas, and the multicast extensions to OSPF (MOSPF) are also supported in OSPF for IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-update-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-ospfv3-update-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-ospfv3-update-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-30111345.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-update-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-update-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-30111345.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf*ospf-archive**LISTS*-IETF*-ORG@PEACH.EASE.LSOFT.COM Tue Nov 30 23:31:30 2004 Received: from grape.ease.lsoft.com (grape.ease.lsoft.com [209.119.1.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25966 for ; Tue, 30 Nov 2004 23:31:29 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <15.00521D43@grape.ease.lsoft.com>; Tue, 30 Nov 2004 23:31:31 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47431086 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 30 Nov 2004 23:31:27 -0500 Received: from 61.144.161.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 30 Nov 2004 23:31:21 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I81005B209WVB@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 01 Dec 2004 12:25:08 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar3 2004)) with ESMTP id <0I81008KM09WBE@szxga03-in.huawei.com> forOSPF@PEACH.EASE.LSOFT.COM; Wed, 01 Dec 2004 12:25:08 +0800 (CST) Received: from NitinKCL7064 ([10.18.4.174]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar3 2004)) with ESMTPA id <0I8100EVJ0B50X@szxml02-in.huawei.com> forOSPF@PEACH.EASE.LSOFT.COM; Wed, 01 Dec 2004 12:25:54 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-MS-TNEF-Correlator: 00000000E4FE19584F3DCD4683963B447AFB40CDC40B5B00 X-imss-version: 2.007 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE Message-ID: <000e01c4d75e$cbaff2e0$ae04120a@in.huawei.com> Date: Wed, 1 Dec 2004 10:02:41 +0530 Reply-To: Mailing List Sender: Mailing List From: Nitin Kakkar Subject: Re: router LSA with unknown link type To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: QUOTED-PRINTABLE IMHO as per the draft, a router will send all its links (irrespective= of LinkType) to all its peers. So if we have a router with say 100,000 interfaces of type unknown, i= t will send them to peers which in the end will be silently dropped. I am wondering will it be better to have an option in Hello where nei= ghbor can specify if he wants to receive unknown links and based on the opt= ion the sender can send unknown type links. Plus this mechanism will always b= e backward compatible with all existing implementations because they do= n't set any bit. Nitin -----Original Message----- =46rom: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of V= ishwas Manral Sent: 2004=C4=EA11=D4=C230=C8=D5 8:52 To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: router LSA with unknown link type Hi Acee, =20 Here goes the link: - http://www.ietf.org/internet-drafts/draft-manral-ospf-router-lsa-unkn= own-typ e-00.txt =20 =20 Do let me know your views? =20 Thanks, Vishwas _____ =20 =46rom: Mailing List on behalf of Vishwas Manral Sent: Thu 11/25/2004 9:48 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: router LSA with unknown link type Hi Acee, I think we must not forget there can be malicious violations of the protocol too, as Tony rightly specified we need to specify the behavi= or when unexpected or corrupt data is received. As you stated, I intend to post a short draft on this soon. Thanks, Vishwas -----Original Message----- =46rom: Mailing List [ mailto:OSPF@PEACH.EASE.LSOFT.COM ] On Behalf Of Acee Lindem Sent: Thursday, November 25, 2004 10:44 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: router LSA with unknown link type All, While it would have been better if RFC 2328 did precisely specify wha= t to do with unknown link types the fact of the matter is that it doesn= 't. IMHO, we'd need a short draft in order to formally specify this (or concens= us and inclusion in the RFC 2740 respin). At this point, the implementation(s) that generate(s) the unknown link types is/are the ones in violation of the protocol. Speaking as a WG member, I really don't like the idea of extending th= e protocol using unknown link types UNLESS the new types are in fact a different type of intra-area topological edge in the SPF graph. Once we open it up I ca= n envision people trying to cram all sorts of non-link data in the router LSA. If we wa= nt to extend the protocol past what it does today there are cleaner ways of doing it (e.g., new LSA types supporting TLVs). Thanks, Acee Nitin Kakkar wrote: >IMHO I can think of two possibilities for this condition > >1) Some error in LSA creation, which overwrite link type field. : Th= is >should be reflected in checksum error and should be handled such. > >2) Some new invension which adds to the existing 4 types of Link Typ= es (or >support for unknown link types): This Needs to have some common >understanding (RFC etc) to handle this. I feel that they can be hand= led like >unknwon LSA's (store & forward only, no routing calc's) > >HTH >Nitin > >-----Original Message----- >From: Mailing List [ mailto:OSPF@PEACH.EASE.LSOFT.COM ]On Behalf Of Acee >Lindem >Sent: 2004Ae11OA24EO 21:37 >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: router LSA with unknown link type > > >Field, Brian wrote: > > > >>If a router receives a router LSA that contains several links and >>for one of the links, the link type field is not known, should the >>router ignore the entire router LSA or just skip this one link? >> >> >> >> >Hi Brian, >Unfortunately, the handling of unknown link types is not specificall= y >defined in RFC 2328. >Since links types 1-4 are the only ones defined an implementation should >probably log >the invalid link type (with rate limiting). Whether it ignores the L= SA >or just the unknown link is >implementation specific. If we were to move forward with link type >extension it would not be >backward compatible (at least not without knobs or other mechanisms)= . > >Thanks, >Acee > > > >>Thanks >>Brian >> >> >>