From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 1 07:35:56 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21210 for ; Wed, 1 May 2002 07:35:55 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <12.FECFED71@PEAR.EASE.LSOFT.COM>; Wed, 1 May 2002 7:35:31 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 939020 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 1 May 2002 07:35:54 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 1 May 2002 07:25:53 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20170; Wed, 1 May 2002 07:25:50 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200205011125.HAA20170@ietf.org> Date: Wed, 1 May 2002 07:25:49 -0400 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-kini-traf-restore-nsp-00.txt Comments: cc: isis-wg@juniper.net To: OSPF@DISCUSS.MICROSOFT.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Traffic restoration in link state protocols using neighbor's shortest path Author(s) : S. Kini, Y. Yang Filename : draft-kini-traf-restore-nsp-00.txt Pages : 8 Date : 30-Apr-02 Traffic recovery time when a link (or node) fails is typically in the order of tens of seconds for a link state IGP. The recovery time is governed by factors like the time it takes to detect an adjacency down, the time taken to propagate link state database changes throughout the network and the time it takes to run the SPF algorithm and install the new routes in the FIB. Till this entire process is complete, traffic in the network can be blackholed. This draft describes a technique to reduce the time for which traffic is blackholed by routing the traffic through a neighbor's shortest path. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kini-traf-restore-nsp-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kini-traf-restore-nsp-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-kini-traf-restore-nsp-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: <20020430135733.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kini-traf-restore-nsp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kini-traf-restore-nsp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020430135733.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 1 10:03:30 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28297 for ; Wed, 1 May 2002 10:03:29 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <8.E6B6793F@PEAR.EASE.LSOFT.COM>; Wed, 1 May 2002 10:03:04 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 939276 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 1 May 2002 10:03:27 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 1 May 2002 10:03:27 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <2PDRJLTB>; Wed, 1 May 2002 10:03:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 1 May 2002 10:02:59 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: RFC vs. MIB internal metric contradiction To: OSPF@DISCUSS.MICROSOFT.COM Hi Magnus, I do not know any existing scenarios where a metric value of 0 is used in OSPF. However in ISIS a metric value of 0 is advertised in an interesting application. Check the draft http://www.ietf.org/internet-drafts/draft-ietf-isis-ext-lsp-frags-00.txt It could be used in OSPF for a similar purpose, though I do not assume such a thing would ever be required in OSPF. Thanks, Vishwas -----Original Message----- From: Magnus Andersson [mailto:magnus_o_andersson@HOTMAIL.COM] Sent: Tuesday, April 30, 2002 6:18 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: RFC vs. MIB internal metric contradiction After reading both RFC2328 and J.Moy(OSPF, Anatonomy of an Internet Routing protocol) I understand that 0 is not a valid number for the metric field in the router-LSA. However in the OSPFv2 MIB it seems that 0 is a valid value. Are there other situations where we allow a metric of 0, or why does the MIB say that we can use 0?? -- Note the OSPF Metric is defined as an unsigned value in the range Metric ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The OSPF Internal Metric." SYNTAX Integer32 (0..'FFFF'h) RFC2328: Interface output cost(s) The cost of sending a data packet on the interface, expressed in the link state metric. This is advertised as the link cost for this interface in the router-LSA. The cost of an interface must be greater than zero.Interface output cost(s) The cost of sending a data packet on the interface, expressed in the link state metric. This is advertised as the link cost for this interface in the router-LSA. The cost of an interface must be greater than zero. OSPF, Anatonomy of an Internet Routing protocol: Each link also contains a Metric field. This field ranging from 1 to 65535, indicates the relative cost of sending packets over the link. From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 1 10:18:33 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29141 for ; Wed, 1 May 2002 10:18:32 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <6.F94B4CFE@PEAR.EASE.LSOFT.COM>; Wed, 1 May 2002 10:18:08 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 939311 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 1 May 2002 10:18:31 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 1 May 2002 10:18:30 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA03931 for ; Wed, 1 May 2002 10:18:28 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18526 for ; Wed, 1 May 2002 10:18:29 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 1 May 2002 10:18:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC55763154@vie-msgusr-01.dc.fore.com> Date: Wed, 1 May 2002 10:18:26 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: RFC vs. MIB internal metric contradiction To: OSPF@DISCUSS.MICROSOFT.COM Vishwas & Magnus, -> I do not know any existing scenarios where a metric value of -> 0 is used in OSPF. OSPF loopback interfaces uses metric values of 0 (as per RFC2328). Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 3 00:06:14 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24912 for ; Fri, 3 May 2002 00:06:13 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <4.F02EF04F@PEAR.EASE.LSOFT.COM>; Fri, 3 May 2002 0:05:43 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 944404 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 3 May 2002 00:06:07 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Fri, 3 May 2002 00:06:07 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 964BAF2C40 for ; Thu, 2 May 2002 21:06:05 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3CD20C9B.4030701@redback.com> Date: Fri, 3 May 2002 00:05:47 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Demand Circuits Anomalies To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit I've been looking (actually implementing) demand circuits in the context of reduced flooding and OSPF PE/CE Sham Links and I seemed to have run across a situation that doesn't seem to be handled by RFC 1793. - You have two links in area 1 between routers A and B over which you establish adjacencies. One is configured as a demand circuit and one is not. - Router A is an ABR and is advertising a number of summary network advertisments. These are advertised as DoNotAge LSAs over the demand circuit and regular LSAs over the other circuit. - Over time (> 1800 seconds), all the DoNotAge LSAs are replaced with normal LSAs since they are not refreshed over the demand circuit but are refreshed over the non-demand circuit. - The non-demand circuit between A and B goes down indefinitely. - After MaxAge (3600 seconds), router B ages out the LSAs and they are unreachable even though the neighbor adjacency over the demand circuit is still up. Keep in mind that the summary network advertisements have not changed and there is no other path between routers A and B. Am I missing something here or isn't this case handled? Thanks, -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 3 01:01:57 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26241 for ; Fri, 3 May 2002 01:01:56 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <11.F9E562B7@PEAR.EASE.LSOFT.COM>; Fri, 3 May 2002 1:01:32 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 944482 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 3 May 2002 01:01:57 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Fri, 3 May 2002 00:51:56 -0400 Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with esmtp (Exim 3.36 #1) id 173V2x-000K9q-00; Thu, 02 May 2002 21:51:55 -0700 X-Mailer: The Bat! (v1.51) Personal X-Priority: 3 (Normal) References: <3CD20C9B.4030701@redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <183128924636.20020502215116@psg.com> Date: Thu, 2 May 2002 21:51:16 -0700 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: Demand Circuits Anomalies Comments: To: Acee Lindem To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3CD20C9B.4030701@redback.com> Content-Transfer-Encoding: 7bit Acee, Hmmm... In the last step below, when B ages the LSAs out, it will flush them by flooding the MaxAge version through all links, including the DC one (MaxAge is considered to be a change). This should trigger the 'self-originated' mechanism in A to reoriginate the LSAs and flood the new versions back. -- Alex Thursday, May 02, 2002, 9:05:47 PM, you wrote: > I've been looking (actually implementing) demand circuits in the context > of reduced flooding and OSPF PE/CE Sham Links and I seemed to have > run across a situation that doesn't seem to be handled > by RFC 1793. > - You have two links in area 1 between routers A and B over which > you establish adjacencies. One is configured as a demand > circuit and one is not. > - Router A is an ABR and is advertising a number of summary > network advertisments. These are advertised as DoNotAge > LSAs over the demand circuit and regular LSAs over the other > circuit. > - Over time (> 1800 seconds), all the DoNotAge LSAs are replaced > with normal LSAs since they are not refreshed over the demand > circuit but are refreshed over the non-demand circuit. > - The non-demand circuit between A and B goes down indefinitely. > - After MaxAge (3600 seconds), router B ages out the LSAs and > they are unreachable even though the neighbor adjacency over > the demand circuit is still up. Keep in mind that the summary > network advertisements have not changed and there is no other > path between routers A and B. > Am I missing something here or isn't this case handled? > Thanks, > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 3 01:33:02 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26636 for ; Fri, 3 May 2002 01:33:01 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <15.F6DC70F8@PEAR.EASE.LSOFT.COM>; Fri, 3 May 2002 1:32:37 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 944573 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 3 May 2002 01:33:02 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Fri, 3 May 2002 01:33:02 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 4E1E939B5B4; Thu, 2 May 2002 22:33:01 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3CD20C9B.4030701@redback.com> <183128924636.20020502215116@psg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3CD220FA.3000506@redback.com> Date: Fri, 3 May 2002 01:32:42 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Demand Circuits Anomalies Comments: To: Alex Zinin To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Alex Zinin wrote: > Acee, > > > Hmmm... In the last step below, when B ages the LSAs out, > it will flush them by flooding the MaxAge version through all > links, including the DC one (MaxAge is considered to be a change). > This should trigger the 'self-originated' mechanism in A to > reoriginate the LSAs and flood the new versions back. > Opps - that works. Thanks, -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 3 14:56:38 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24456 for ; Fri, 3 May 2002 14:56:37 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <7.FEBE5321@PEAR.EASE.LSOFT.COM>; Fri, 3 May 2002 14:56:13 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 946795 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 3 May 2002 14:56:39 -0400 Received: from 216.136.226.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Fri, 3 May 2002 14:56:39 -0400 Received: from [149.112.94.138] by web20306.mail.yahoo.com via HTTP; Fri, 03 May 2002 11:56:38 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020503185638.7364.qmail@web20306.mail.yahoo.com> Date: Fri, 3 May 2002 11:56:38 -0700 Reply-To: Mailing List Sender: Mailing List From: Ash he Subject: Routing config To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <183128924636.20020502215116@psg.com> Is it allowed theoretically to have the following configuration on a single router? Can you please give its implications if yes and the reasons if not? Intf1: 149.112.1.3/B Intf2: 149.112.2.4/C Any help appreciated. Thanks, Ash. __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 8 06:35:29 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00093 for ; Wed, 8 May 2002 06:35:29 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <11.F9E56492@PEAR.EASE.LSOFT.COM>; Wed, 8 May 2002 6:35:04 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 962242 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 8 May 2002 06:35:33 -0400 Received: from 192.91.191.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 8 May 2002 06:35:33 -0400 Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2655.55) id ; Wed, 8 May 2002 11:35:30 +0100 X-MS-TNEF-Correlator: <37701240971DD31193970000F6CCB9F70323C6B2@duke.datcon.co.uk> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <37701240971DD31193970000F6CCB9F70323C6B2@duke.datcon.co.uk> Date: Wed, 8 May 2002 11:35:20 +0100 Reply-To: Mailing List Sender: Mailing List From: Mark Mitchell Subject: Possible optimization to Hitless Restart draft To: OSPF@DISCUSS.MICROSOFT.COM Hi there, I have a proposal for a possible optimization to the OSPF Hitless Restart draft. I would welcome comments on whether the proposal is valid, worthwhile or otherwise. In section 2.1, the draft states that 'after the grace-LSAs have been sent, the router should store the fact that it is performing hitless restart along with the length of the requested grace period in non-volatile storage.'. We were wondering whether it is necessary to store the length of the grace period before restarting. Instead, our idea is that the restarting router discovers the grace period it requested from the grace LSAs it originated prior to the hitless restart and which it will receive during hitless restart (from its neighbors). At the same time it will be receiving the other LSAs that it originated prior to the restart and accepting them as current (until Hitless Restart is over). - Since the grace period should start at the time the grace LSA was originated, the remaining duration of the grace period can be calculated as the grace period requested in the LSA minus the age of the LSA itself. - Note that if the restarting router does not receive any grace LSAs, its neighbors cannot be helping it to undergo hitless restart and so hitless restart will soon end. - If the restarting router does not receive any grace LSAs or pre-start router or network LSAs from its neighbors, it might never exit hitless restart. This could be avoided by the restarting router assuming the default grace period until it receives its pre-start grace LSA containing the actual grace period. Obviously the proposal in the draft (of storing the grace period in non-volatile storage) is entirely valid, but this seemed like a possible enhancement to avoid needing to do this. As mentioned before, we would appreciate any comments. Thanks, Mark ------- Mark Mitchell DC-OSPF Development Manager Data Connection Ltd Tel: +44 20 8366 1177 Fax: +44 20 8363 1039 Email: mm@dataconnection.com Web: http://www.dataconnection.com From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 8 10:14:26 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08324 for ; Wed, 8 May 2002 10:14:25 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <2.FF1FB437@PEAR.EASE.LSOFT.COM>; Wed, 8 May 2002 10:14:03 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 963133 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 8 May 2002 10:14:32 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 8 May 2002 10:14:32 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 42B1B4BA21F for ; Wed, 8 May 2002 07:14:30 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <37701240971DD31193970000F6CCB9F70323C6B2@duke.datcon.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3CD932D5.2080407@redback.com> Date: Wed, 8 May 2002 10:14:45 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Possible optimization to Hitless Restart draft To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Mark, It seems like it would work ok but I don't see it as an optimization. Rather, it is an implementation tactic that may or may not be easier depending on the environment. Also, if you (or your marketing group ;-) wants to handle both planned and unplanned restarts you need to be able to determine this fact and are going to need to keep track of you restart reason (at a minimum) in non-volatile storage (with no restart reason defaulting to an unplanned restart). Note that in the case of the unplanned restart, the grace LSAs are sent when you come back up rather than when you are about to go down. Thanks, Acee Mark Mitchell wrote: > Hi there, > > I have a proposal for a possible optimization to the OSPF Hitless Restart > draft. I would welcome comments on whether the proposal is valid, worthwhile > or otherwise. > > In section 2.1, the draft states that 'after the grace-LSAs have been sent, > the router should store the fact that it is performing hitless restart along > with the length of the requested grace period in non-volatile storage.'. > > We were wondering whether it is necessary to store the length of the grace > period before restarting. Instead, our idea is that the restarting router > discovers the grace period it requested from the grace LSAs it originated > prior to the hitless restart and which it will receive during hitless > restart (from its neighbors). At the same time it will be receiving the > other LSAs that it originated prior to the restart and accepting them as > current (until Hitless Restart is over). > > - Since the grace period should start at the time the grace LSA was > originated, the remaining duration of the grace period can be calculated as > the grace period requested in the LSA minus the age of the LSA itself. > > - Note that if the restarting router does not receive any grace LSAs, its > neighbors cannot be helping it to undergo hitless restart and so hitless > restart will soon end. > > - If the restarting router does not receive any grace LSAs or pre-start > router or network LSAs from its neighbors, it might never exit hitless > restart. This could be avoided by the restarting router assuming the default > grace period until it receives its pre-start grace LSA containing the actual > grace period. > > Obviously the proposal in the draft (of storing the grace period in > non-volatile storage) is entirely valid, but this seemed like a possible > enhancement to avoid needing to do this. As mentioned before, we would > appreciate any comments. > > Thanks, > > > Mark > > ------- > Mark Mitchell > DC-OSPF Development Manager > Data Connection Ltd > Tel: +44 20 8366 1177 > Fax: +44 20 8363 1039 > Email: mm@dataconnection.com > Web: http://www.dataconnection.com > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 8 10:38:14 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09440 for ; Wed, 8 May 2002 10:38:14 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <1.FEA93B43@PEAR.EASE.LSOFT.COM>; Wed, 8 May 2002 10:37:51 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 963175 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 8 May 2002 10:38:20 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 8 May 2002 10:38:20 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA07352 for ; Wed, 8 May 2002 10:38:17 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA20398 for ; Wed, 8 May 2002 10:38:18 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 8 May 2002 10:38:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC5576317D@vie-msgusr-01.dc.fore.com> Date: Wed, 8 May 2002 10:38:16 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Possible optimization to Hitless Restart draft To: OSPF@DISCUSS.MICROSOFT.COM Mark, [clipped] -> We were wondering whether it is necessary to store the -> length of the grace period before restarting. Instead, -> our idea is that the restarting router -> discovers the grace period it requested from the grace LSAs -> it originated prior to the hitless restart and which it -> will receive during hitless restart (from its neighbors). You logic might work well. I would say, it is always better to trust your own machine timing than your neighbors. If you are going to derive the remaining time from old instances of Grate LSA then: - What if you get different Ages set from different neighbors - Which Grate LSA timing you prefer (first one, last one, least timed one, highest timed one) So, IMHO, better store the time (absolute/relative) in non-volatile storage and do the necessary timing computation. -- Venkata Naidu From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 8 11:08:35 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11145 for ; Wed, 8 May 2002 11:08:34 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <11.F9E564AC@PEAR.EASE.LSOFT.COM>; Wed, 8 May 2002 11:08:11 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 963305 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 8 May 2002 11:08:40 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 8 May 2002 11:08:40 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA11237 for ; Wed, 8 May 2002 11:08:29 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA29558 for ; Wed, 8 May 2002 11:08:25 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 8 May 2002 11:08:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC5576317E@vie-msgusr-01.dc.fore.com> Date: Wed, 8 May 2002 11:08:23 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Suggestion to Hitless Restart draft To: OSPF@DISCUSS.MICROSOFT.COM John & All, I have a small suggestion to appendix A in draft-ietf-ospf-hitless-restart-02.txt. (I already hinted in CCAMP WG discussion http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00694.html) Just like *Hitless restart reason (Type=2, length=1)*, it would be better to include addition TLV called: o Hitless Action Request (Type=4, length=1). Encodes the action requested from neighbor for the router restart. This TLV is *optional* in a grace-LSA. If not present in grace-LSA then default action will be performed by all the neighbors. The usefulness of this TLV is extensibility. If I know that, all of my neighbors are from same vendor, then I can implement my own proprietary mechanism in restart. As you all know, everyone has different opinions and ideas in implementing hitless restart - so it is better to allow some room for future action requests from neighbors (from routing, signaling, MPLS, GMPLS, TE, control, forwarding etc etc modules restarts perspective). -- Venkata From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 8 20:56:05 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27458 for ; Wed, 8 May 2002 20:56:05 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <4.F02EF281@PEAR.EASE.LSOFT.COM>; Wed, 8 May 2002 20:55:41 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 965713 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 8 May 2002 20:56:10 -0400 Received: from 207.217.120.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 8 May 2002 20:56:10 -0400 Received: from 209-239-196-84.oak.jps.net ([209.239.196.84] helo=earthlink.net) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 175cE4-0007k0-00 for ospf@discuss.microsoft.com; Wed, 08 May 2002 17:56:08 -0700 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3CD9CB10.421759C4@earthlink.net> Date: Wed, 8 May 2002 18:04:16 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: draft..-congest-control-01.txt : oob-resync++ To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Last 6 comments/suggestions... A) 4.1.1: There was an earlier draft Feb01 to Sept01 Out Of Band LSDB Resynch by Cisco Under the assumption that this functionality is supported in two OSPF routers for the use of OOB LSDB Resync. Due to the fact that most resynchronization work was already done with this adj.... I SUGGEST that this OOB adjacency should require less work for re-synchonization, thus these ADJs should not be considered as a single increment, as part of the MAX_ADJ_BUILD_CNT. I believe that since they do require some work, a value of .5 (partial weight) could be considered per OOB ADJ re-sync work... B) 4.1.3 My assumption is that a CLI command should allow or disallow this feature because it diverages from the OSPF Hello protocol. My suggestion is that the default should follow the standard of not allowing "OTHER CONTROL PACKETS" to detect Live-ness of the adjacency. This way if a router fails to send enough hellos or a router is dropping a significant number of hellos, then at least the debugging of adj is eased, the system follows the OSPF spec, the administrator is aware of this variance,, etc. C) 4.2.2.2 MAX_LSA_FLOOD for each interface This comment assumes a local (one interface) congestion setting vs global cong(some subset of the interfaces) are contributing towards congestion.. Would having a global value set that is NOT NECESSARILY the sum of each of these per interface local values make sense? My assumption is that if only 1 interface was having congestion, then its value could be set to a "localized congestion value", where if a number of its interfaces were having congestion then a "global congestion value" could be used and split among the congested interfaces. The localized value SHOULD be a higher value, since the router could devote temporaily more of its resources to just one or a few of its interfaces... Ex: If one interface has congestion then maybe its local value could be say 100, where if say 5 interfaces have congestion, then each should be set to 20.. This assumes a equal fair interface value setting... Some implimentation may have some interfaces be more important than others.. D) 4.2.2.4 nit.... "reduce the rate of the SPF computation" Should the word "frequency' be used instead of 'rate'? E) NEW Message Throttle Section... Under the assumption that internal logging messages consume resources, may overflow internal buffers, may obscure important mesages, and that congestion may generate a huge number of messages. Messages could play a role in determining the level of internal congestion. There COULD be a configurable variable that can be set for "Message Throttling". This assumes that messages will be placed in some form of FIFO and lower priority messages be pruned when more than x messages are awaiting transmission. F) Should their be a section on Random Early Discard for incoming or outgoing packets? From owner-ospf@DISCUSS.MICROSOFT.COM Thu May 9 06:55:29 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15474 for ; Thu, 9 May 2002 06:55:25 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <5.F3EA6161@PEAR.EASE.LSOFT.COM>; Thu, 9 May 2002 6:55:01 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 968127 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 9 May 2002 06:55:31 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 9 May 2002 06:55:31 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 06:51:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 9 May 2002 06:55:00 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: draft..-congest-control-01.txt : oob-resync++ To: OSPF@DISCUSS.MICROSOFT.COM Hi Mitchell, The general idea of the draft http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control -00.txt is to reduce the rate of flooding in case of congestion, which has been the cause of network collapses in the past(check draft for details). The draft simply proposes a method to signal congestion and the minimum requirements for putting in such a mechanism in place, to react to such a congestion and to prevent such collapses in the future. The exact implementations have been given as examples. My comments are inline. -----Original Message----- From: Erblichs [mailto:erblichs@EARTHLINK.NET] Sent: Thursday, May 09, 2002 6:34 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: draft..-congest-control-01.txt : oob-resync++ Last 6 comments/suggestions... A) 4.1.1: There was an earlier draft Feb01 to Sept01 Out Of Band LSDB Resynch by Cisco Under the assumption that this functionality is supported in two OSPF routers for the use of OOB LSDB Resync. Due to the fact that most resynchronization work was already done with this adj.... I SUGGEST that this OOB adjacency should require less work for re-synchonization, thus these ADJs should not be considered as a single increment, as part of the MAX_ADJ_BUILD_CNT. I believe that since they do require some work, a value of .5 (partial weight) could be considered per OOB ADJ re-sync work... VM> I guess that can be done. However I guess we will have various other scenarios where we could reduce or increase weight, say using different values in case of P2P and broadcast(DR/BDR/DR-other). We have tried to not get into this in detail and have assumed all adjacencies of equal values. However I am sure an implementation can always do things the way you have proposed. B) 4.1.3 My assumption is that a CLI command should allow or disallow this feature because it diverages from the OSPF Hello protocol. My suggestion is that the default should follow the standard of not allowing "OTHER CONTROL PACKETS" to detect Live-ness of the adjacency. This way if a router fails to send enough hellos or a router is dropping a significant number of hellos, then at least the debugging of adj is eased, the system follows the OSPF spec, the administrator is aware of this variance,, etc. VM> Well this does not create any problems. We are not proposing that in case a control packet has been sent within the hello interval, do not send the hello. The hellos are still sent as usual. This feature just improves things and does not create any problems. Someone could always have this feature as optional however(this is already done in existing implementations already). C) 4.2.2.2 MAX_LSA_FLOOD for each interface This comment assumes a local (one interface) congestion setting vs global cong(some subset of the interfaces) are contributing towards congestion.. Would having a global value set that is NOT NECESSARILY the sum of each of these per interface local values make sense? My assumption is that if only 1 interface was having congestion, then its value could be set to a "localized congestion value", where if a number of its interfaces were having congestion then a "global congestion value" could be used and split among the congested interfaces. The localized value SHOULD be a higher value, since the router could devote temporaily more of its resources to just one or a few of its interfaces... Ex: If one interface has congestion then maybe its local value could be say 100, where if say 5 interfaces have congestion, then each should be set to 20.. This assumes a equal fair interface value setting... Some implimentation may have some interfaces be more important than others.. VM>The mechanism given in the draft is just an example. It has been clearly stated that "However, a mechanism is discussed here to illustrate how such a mechanism might work." A person could always implement it the way you have put it. D) 4.2.2.4 nit.... "reduce the rate of the SPF computation" Should the word "frequency' be used instead of 'rate'? VM> Will do that. E) NEW Message Throttle Section... Under the assumption that internal logging messages consume resources, may overflow internal buffers, may obscure important mesages, and that congestion may generate a huge number of messages. Messages could play a role in determining the level of internal congestion. There COULD be a configurable variable that can be set for "Message Throttling". This assumes that messages will be placed in some form of FIFO and lower priority messages be pruned when more than x messages are awaiting transmission. VM> I agree with you. I have observed that during simulations, that putting the logging to minimum during congestion state helps. However I am not sure we can add such a thing to the draft, which is not very OSPF specific. F) Should their be a section on Random Early Discard for incoming or outgoing packets? VM> Random Early Discard(Detection) would be helpful in case, we were using discard(retransmission) as a method to reduce the rate of flooding. We are instead using explicit signalling as the method to do this, discard would only cause retransmissions, which only means additional traffic. Does it sound correct? Thanks a lot, Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Thu May 9 12:09:55 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27381 for ; Thu, 9 May 2002 12:09:54 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <3.F815664C@PEAR.EASE.LSOFT.COM>; Thu, 9 May 2002 12:09:31 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 969472 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 9 May 2002 12:10:01 -0400 Received: from 207.217.120.123 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 9 May 2002 12:10:01 -0400 Received: from 209-239-198-109.oak.jps.net ([209.239.198.109] helo=earthlink.net) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 175qUQ-0000cG-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 09 May 2002 09:09:59 -0700 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: <3CDAA144.DCA9C084@earthlink.net> Date: Thu, 9 May 2002 09:18:12 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: draft..-congest-control-01.txt : oob-resync++ To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Just followup within section F, and three more nits.. Lets assume in some implimentations that RED (Random Early Discard) drops protocol and data packets... * Not all OSPF routers will initially support your new signaling / ECN (?Explicit Congestion Notification) Internal nit... Why don't you mention the term ECN in this draft? I think there is a good paper by Sally Floyd in this area.. Alas, I think it is directed towards TCP/IP... * 4.1.3 Assumes that hellos are lost or significantly delayed. Assuming the former they are then lost, then they are lost at transmission or upon reception and are not retranmitted. Isn't this a form of RED? And they are not re-xmit'ed based on missing acks :-) .. * You implicitly specify the possibility of dropping of Database Description LSPs, when you Throttle Link Adjs in 4.1.1..? Isn't this a form of RED? So, my question should there be a section on what to do before you start sending your low congestion notification? Like RED. NIT... In 4.2.1 you mention "medium congestion", where as your signaling only speaks of heavy/high and low congestion signaling.. Did you mean "avoid flapping of a router between high and low congestion"? NIT2... 4.2.1 : For consistency sake, should "heavy" be changed to "high"? Statements: Its very difficult to determine the exact crossover point between high and low congestion. Whether the sustaining of high congestion is eqivalent to TCPs congestion avoidance code via the High_Congestion_Interval.. Should there be a Low_Congestion_Interval? If so, whether this would be the eqivalent to TCPs slow start phase? Mitchell Erblich ---------------------------------- "Manral, Vishwas" wrote: > > Hi Mitchell, > > The general idea of the draft > > http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control > -00.txt > > is to reduce the rate of flooding in case of congestion, which has been the > cause of network collapses in the past(check draft for details). The draft > simply proposes a method to signal congestion and the minimum requirements > for putting in such a mechanism in place, to react to such a congestion and > to prevent such collapses in the future. The exact implementations have been > given as examples. > > My comments are inline. > > -----Original Message----- > From: Erblichs [mailto:erblichs@EARTHLINK.NET] > Sent: Thursday, May 09, 2002 6:34 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: draft..-congest-control-01.txt : oob-resync++ > > Last 6 comments/suggestions... > > A) > 4.1.1: > There was an earlier draft Feb01 to Sept01 Out Of Band LSDB Resynch > by Cisco > Under the assumption that this functionality is > supported in two OSPF routers for the use of OOB LSDB Resync. > > Due to the fact that most resynchronization work was already > done with this adj.... > I SUGGEST that this OOB adjacency should require > less work for re-synchonization, thus these ADJs should not be > considered as a single increment, as part of the MAX_ADJ_BUILD_CNT. > I believe that since they do require some work, a value of .5 > (partial weight) could be considered per OOB ADJ re-sync work... > > VM> I guess that can be done. However I guess we will have various other > scenarios where we could reduce or increase weight, say using different > values in case of P2P and broadcast(DR/BDR/DR-other). We have tried to not > get into this in detail and have assumed all adjacencies of equal values. > > However I am sure an implementation can always do things the way you have > proposed. > > B) > 4.1.3 > My assumption is that a CLI command should allow or disallow > this feature because it diverages from the OSPF Hello protocol. > My suggestion is that the default should follow the standard of > not allowing "OTHER CONTROL PACKETS" to detect Live-ness of the > adjacency. > > This way if a router fails to send enough hellos or a router > is dropping a significant number of hellos, > then at least the debugging of adj is eased, > the system follows the OSPF spec, > the administrator is aware of this variance,, > etc. > VM> Well this does not create any problems. We are not proposing that in > case a control packet has been sent within the hello interval, do not send > the hello. The hellos are still sent as usual. This feature just improves > things and does not create any problems. Someone could always have this > feature as optional however(this is already done in existing implementations > already). > > C) > 4.2.2.2 MAX_LSA_FLOOD for each interface > This comment assumes a local (one interface) congestion setting > vs global cong(some subset of the interfaces) are contributing > towards congestion.. > > Would having a global value set that is NOT NECESSARILY the sum of > each of these per interface local values make sense? My assumption > is that if only 1 interface was having congestion, then its > value could be set to a "localized congestion value", where if a > number of its interfaces were having congestion then a "global > congestion value" could be used and split among the congested > interfaces. > > The localized value SHOULD > be a higher value, since the router could devote temporaily > more of its resources to just one or a few of its interfaces... > Ex: If one interface has congestion then maybe its local > value could be say 100, where if say 5 interfaces have congestion, > then each should be set to 20.. This assumes a equal fair > interface value setting... Some implimentation may have some > interfaces be more important than others.. > > VM>The mechanism given in the draft is just an example. It has been clearly > stated that > > "However, a mechanism is discussed here to illustrate how such a mechanism > might work." > > A person could always implement it the way you have put it. > > D) > 4.2.2.4 > nit.... "reduce the rate of the SPF computation" > Should the word "frequency' be used instead of 'rate'? > VM> Will do that. > > E) > NEW Message Throttle Section... > Under the assumption that internal logging messages consume > resources, may overflow internal buffers, may obscure > important mesages, and that congestion may > generate a huge number of messages. > > Messages could play a role in determining the > level of internal congestion. There COULD be a configurable > variable that can be set for "Message Throttling". This > assumes that messages will be placed in some form of FIFO > and lower priority messages be pruned when more than x > messages are awaiting transmission. > VM> I agree with you. I have observed that during simulations, that putting > the logging to minimum during congestion state helps. However I am not sure > we can add such a thing to the draft, which is not very OSPF specific. > > F) Should their be a section on Random Early Discard > for incoming or outgoing packets? > VM> Random Early Discard(Detection) would be helpful in case, we were using > discard(retransmission) as a method to reduce the rate of flooding. We are > instead using explicit signalling as the method to do this, discard would > only cause retransmissions, which only means additional traffic. Does it > sound correct? > > Thanks a lot, > Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 10 08:51:35 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19121 for ; Fri, 10 May 2002 08:51:34 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <9.FF43F9EA@PEAR.EASE.LSOFT.COM>; Fri, 10 May 2002 8:51:10 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 973292 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 10 May 2002 08:51:40 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Fri, 10 May 2002 08:51:40 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 08:47:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 10 May 2002 08:51:23 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: draft..-congest-control-01.txt : oob-resync++ To: OSPF@DISCUSS.MICROSOFT.COM Mitchell, The idea we have is to actively and explicitly signal congestion, rather than have an implicit control mechanism. The reason is that explicit signalling of congestion is better in case of delay sensitive applications(here a lot of rxmts would result in case we delayed), so if we suddenly were getting congested, then using explicit notification, we could actually signal such a thing soon enough. In case of implicit congestion notification, it would take a longer time to reduce flooding rates by neighbors. Also as we are using two levels of congestion "Low" and "High" we could signal low congestion well before we are heavily congested. My comments inline prefixed with a "VM>". -----Original Message----- From: Erblichs [mailto:erblichs@EARTHLINK.NET] Sent: Thursday, May 09, 2002 9:48 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: draft..-congest-control-01.txt : oob-resync++ Just followup within section F, and three more nits.. Lets assume in some implimentations that RED (Random Early Discard) drops protocol and data packets... * Not all OSPF routers will initially support your new signaling / ECN (?Explicit Congestion Notification) Internal nit... Why don't you mention the term ECN in this draft? I think there is a good paper by Sally Floyd in this area.. Alas, I think it is directed towards TCP/IP... VM> I guess we still can use the term ECN. That is exactly what we want, to have all routers have a common mechanism for congestion notification. We also reduce our own rate of flooding whenever we feel the network is congested. * 4.1.3 Assumes that hellos are lost or significantly delayed. Assuming the former they are then lost, then they are lost at transmission or upon reception and are not retranmitted. Isn't this a form of RED? And they are not re-xmit'ed based on missing acks :-) .. VM> As I told you we would rather have an explicit congestion mechanism than an implicit one. Also I do not know how many people would agree to drop hellos got from neighbors, after all we are trying to keep the adjacencies up, and dropping could have an adverse effect. Check section Appendix A, it talks about a very interesting proposal, which we had a lot of resistance to and had to remove from the main body of the draft(although we had experimental evidence to support the advantages). * You implicitly specify the possibility of dropping of Database Description LSPs, when you Throttle Link Adjs in 4.1.1..? Isn't this a form of RED? So, my question should there be a section on what to do before you start sending your low congestion notification? Like RED. VM> Having implicit congestion control can always be done on the router, even if we support an explicit mechanism. However I am not sure people would be happy about explicit drop of packets. We could however use delays in getting Acks and number of retransmits to reduce flooding rate, however a lot of protocol factors like delayed ack etc would come into picture. Dropping some packets so that we do not bring an adjacency up, would be different from the case where we use drop to signal congestion. NIT... In 4.2.1 you mention "medium congestion", where as your signaling only speaks of heavy/high and low congestion signaling.. Did you mean "avoid flapping of a router between high and low congestion"? VM> I guess we need to correct that. Initially we had thought of 3 levels of congestion, we later thought of just going in for 2. NIT2... 4.2.1 : For consistency sake, should "heavy" be changed to "high"? VM> Ok. Statements: Its very difficult to determine the exact crossover point between high and low congestion. Whether the sustaining of high congestion is eqivalent to TCPs congestion avoidance code via the High_Congestion_Interval.. Should there be a Low_Congestion_Interval? If so, whether this would be the eqivalent to TCPs slow start phase? VM> I guess that can be done too. Thanks, Vishwas "Manral, Vishwas" wrote: > > Hi Mitchell, > > The general idea of the draft > > http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control > -00.txt > > is to reduce the rate of flooding in case of congestion, which has been the > cause of network collapses in the past(check draft for details). The draft > simply proposes a method to signal congestion and the minimum requirements > for putting in such a mechanism in place, to react to such a congestion and > to prevent such collapses in the future. The exact implementations have been > given as examples. > > My comments are inline. > > -----Original Message----- > From: Erblichs [mailto:erblichs@EARTHLINK.NET] > Sent: Thursday, May 09, 2002 6:34 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: draft..-congest-control-01.txt : oob-resync++ > > Last 6 comments/suggestions... > > A) > 4.1.1: > There was an earlier draft Feb01 to Sept01 Out Of Band LSDB Resynch > by Cisco > Under the assumption that this functionality is > supported in two OSPF routers for the use of OOB LSDB Resync. > > Due to the fact that most resynchronization work was already > done with this adj.... > I SUGGEST that this OOB adjacency should require > less work for re-synchonization, thus these ADJs should not be > considered as a single increment, as part of the MAX_ADJ_BUILD_CNT. > I believe that since they do require some work, a value of .5 > (partial weight) could be considered per OOB ADJ re-sync work... > > VM> I guess that can be done. However I guess we will have various other > scenarios where we could reduce or increase weight, say using different > values in case of P2P and broadcast(DR/BDR/DR-other). We have tried to not > get into this in detail and have assumed all adjacencies of equal values. > > However I am sure an implementation can always do things the way you have > proposed. > > B) > 4.1.3 > My assumption is that a CLI command should allow or disallow > this feature because it diverages from the OSPF Hello protocol. > My suggestion is that the default should follow the standard of > not allowing "OTHER CONTROL PACKETS" to detect Live-ness of the > adjacency. > > This way if a router fails to send enough hellos or a router > is dropping a significant number of hellos, > then at least the debugging of adj is eased, > the system follows the OSPF spec, > the administrator is aware of this variance,, > etc. > VM> Well this does not create any problems. We are not proposing that in > case a control packet has been sent within the hello interval, do not send > the hello. The hellos are still sent as usual. This feature just improves > things and does not create any problems. Someone could always have this > feature as optional however(this is already done in existing implementations > already). > > C) > 4.2.2.2 MAX_LSA_FLOOD for each interface > This comment assumes a local (one interface) congestion setting > vs global cong(some subset of the interfaces) are contributing > towards congestion.. > > Would having a global value set that is NOT NECESSARILY the sum of > each of these per interface local values make sense? My assumption > is that if only 1 interface was having congestion, then its > value could be set to a "localized congestion value", where if a > number of its interfaces were having congestion then a "global > congestion value" could be used and split among the congested > interfaces. > > The localized value SHOULD > be a higher value, since the router could devote temporaily > more of its resources to just one or a few of its interfaces... > Ex: If one interface has congestion then maybe its local > value could be say 100, where if say 5 interfaces have congestion, > then each should be set to 20.. This assumes a equal fair > interface value setting... Some implimentation may have some > interfaces be more important than others.. > > VM>The mechanism given in the draft is just an example. It has been clearly > stated that > > "However, a mechanism is discussed here to illustrate how such a mechanism > might work." > > A person could always implement it the way you have put it. > > D) > 4.2.2.4 > nit.... "reduce the rate of the SPF computation" > Should the word "frequency' be used instead of 'rate'? > VM> Will do that. > > E) > NEW Message Throttle Section... > Under the assumption that internal logging messages consume > resources, may overflow internal buffers, may obscure > important mesages, and that congestion may > generate a huge number of messages. > > Messages could play a role in determining the > level of internal congestion. There COULD be a configurable > variable that can be set for "Message Throttling". This > assumes that messages will be placed in some form of FIFO > and lower priority messages be pruned when more than x > messages are awaiting transmission. > VM> I agree with you. I have observed that during simulations, that putting > the logging to minimum during congestion state helps. However I am not sure > we can add such a thing to the draft, which is not very OSPF specific. > > F) Should their be a section on Random Early Discard > for incoming or outgoing packets? > VM> Random Early Discard(Detection) would be helpful in case, we were using > discard(retransmission) as a method to reduce the rate of flooding. We are > instead using explicit signalling as the method to do this, discard would > only cause retransmissions, which only means additional traffic. Does it > sound correct? > > Thanks a lot, > Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 10 11:23:53 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28422 for ; Fri, 10 May 2002 11:23:51 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <0.EB65F848@PEAR.EASE.LSOFT.COM>; Fri, 10 May 2002 11:23:28 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 973742 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 10 May 2002 11:23:59 -0400 Received: from 207.217.120.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Fri, 10 May 2002 11:23:59 -0400 Received: from 209-239-201-138.oak.jps.net ([209.239.201.138] helo=earthlink.net) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 176CFR-00002e-00 for ospf@discuss.microsoft.com; Fri, 10 May 2002 08:23:57 -0700 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3CDBE805.2823777C@earthlink.net> Date: Fri, 10 May 2002 08:32:21 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Restart signaling, DR/BDR, and RouterDeadInterval To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit OSPF Restart Signaling.. Feb01 to Sept01 Hi Group, I didn't see if this became a standard, so this clarification / question could be moot.. Just thinking of the proper way to code this.. I assume that if a hello is recieved from a restart router within the RouterDeadInterval timeframe, then there is significantly less work... There was no intervening teardown.. However, what is not mentioned, and I want to clarify this.. Assume both routers support Restart.. If the restarting router was the DR or the BDR, there is no assumption that if the restart was done WITHIN the RouterDeadInterval timeframe, the adjacency is still up, that a restarting router would stay the BDR or DR... Assume both routers support restart.. Else, NOT WITHIN the RouterDeadInterval timeframe. We have to assume that there was a intervening election. Would we do another election? There is no mention of election effects / side-effects with respect to the restarting router, when all or some routers support restart? The non-restart supported routers would force a re-election. Thanks, Mitchell Erblich From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 10 11:37:01 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29257 for ; Fri, 10 May 2002 11:37:01 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <1.FEA93C71@PEAR.EASE.LSOFT.COM>; Fri, 10 May 2002 11:36:37 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 973860 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 10 May 2002 11:37:08 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Fri, 10 May 2002 11:37:08 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id DEE8BCAB61 for ; Fri, 10 May 2002 08:37:06 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3CDBE805.2823777C@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3CDBE917.5020400@redback.com> Date: Fri, 10 May 2002 11:36:55 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Restart signaling, DR/BDR, and RouterDeadInterval To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Michelle, Manral, There are two hitless restart drafts. Although I was not at the specific meeting, the one below is the one that was accepted by the OSPF work group. http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-02.txt IMHO, it does address your questions although there is currently no provision for a restart that doesn't proceed within the router dead interval. We are considering this for our implementation. Erblichs wrote: > OSPF Restart Signaling.. Feb01 to Sept01 > > Hi Group, > > I didn't see if this became a standard, so > this clarification / question could be moot.. > > Just thinking of the proper way to code > this.. > > I assume that if a hello is recieved from > a restart router within the RouterDeadInterval > timeframe, then there is significantly less > work... There was no intervening teardown.. > > However, what is not mentioned, and I want to > clarify this.. > > Assume both routers support Restart.. > If the restarting router was the DR or the BDR, > there is no assumption that if the restart was > done WITHIN the RouterDeadInterval timeframe, > the adjacency is still up, that a restarting > router would stay the BDR or DR... > > Assume both routers support restart.. > Else, NOT WITHIN the RouterDeadInterval timeframe. > We have to assume that there was a intervening > election. Would we do another election? > > There is no mention of election effects / side-effects > with respect to the restarting router, when all or > some routers support restart? The non-restart supported > routers would force a re-election. > > Thanks, > Mitchell Erblich > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 10 13:43:21 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07551 for ; Fri, 10 May 2002 13:43:19 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <9.FF43FA0E@PEAR.EASE.LSOFT.COM>; Fri, 10 May 2002 13:42:51 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 974620 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 10 May 2002 13:43:22 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Fri, 10 May 2002 13:43:22 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 13:39:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 10 May 2002 13:42:46 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Restart signaling, DR/BDR, and RouterDeadInterval To: OSPF@DISCUSS.MICROSOFT.COM Mitchell, I guess the "restart signaling" draft is now located at http://www.ietf.org/internet-drafts/draft-nguyen-ospf-restart-00.txt Though Alex, or some other draft author would give the exact details, I think this draft does not bother about keeping DR state, so if a DR router goes down, and comes up it may no longer be the DR after the DR election. Things I guess work as per the base RFC2328. Acee, Thanks for the information. (However I don't remember asking a question related to this. ;-)) Thanks, Vishwas -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Friday, May 10, 2002 9:07 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Restart signaling, DR/BDR, and RouterDeadInterval Michelle, Manral, There are two hitless restart drafts. Although I was not at the specific meeting, the one below is the one that was accepted by the OSPF work group. http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-02.txt IMHO, it does address your questions although there is currently no provision for a restart that doesn't proceed within the router dead interval. We are considering this for our implementation. Erblichs wrote: > OSPF Restart Signaling.. Feb01 to Sept01 > > Hi Group, > > I didn't see if this became a standard, so > this clarification / question could be moot.. > > Just thinking of the proper way to code > this.. > > I assume that if a hello is recieved from > a restart router within the RouterDeadInterval > timeframe, then there is significantly less > work... There was no intervening teardown.. > > However, what is not mentioned, and I want to > clarify this.. > > Assume both routers support Restart.. > If the restarting router was the DR or the BDR, > there is no assumption that if the restart was > done WITHIN the RouterDeadInterval timeframe, > the adjacency is still up, that a restarting > router would stay the BDR or DR... > > Assume both routers support restart.. > Else, NOT WITHIN the RouterDeadInterval timeframe. > We have to assume that there was a intervening > election. Would we do another election? > > There is no mention of election effects / side-effects > with respect to the restarting router, when all or > some routers support restart? The non-restart supported > routers would force a re-election. > > Thanks, > Mitchell Erblich > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 10 14:24:38 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10121 for ; Fri, 10 May 2002 14:24:37 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <14.F575AB66@PEAR.EASE.LSOFT.COM>; Fri, 10 May 2002 14:24:12 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 974769 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 10 May 2002 14:24:43 -0400 Received: from 216.136.173.241 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Fri, 10 May 2002 14:24:43 -0400 Received: from [130.30.33.116] by web12704.mail.yahoo.com via HTTP; Fri, 10 May 2002 11:24:42 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020510182443.28215.qmail@web12704.mail.yahoo.com> Date: Fri, 10 May 2002 11:24:42 -0700 Reply-To: Mailing List Sender: Mailing List From: Suvani Kaura Subject: IP Destination address of hello packets in point to multipoint mode To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Hi All, From reading RFC2328 (sections 8.1, 7.1 & 9.5), I interpreted that hello packets sent in point to multipoint mode should be sent directly to each of the neighbors as unicasts. However, I recently saw a commercial router send hellos to the AllSpfRouters multicast address. Which is the correct way? Thanks in advance, Suvani __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Mother's Day is May 12th! http://shopping.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 10 19:37:54 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22965 for ; Fri, 10 May 2002 19:37:54 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <11.F9E56608@PEAR.EASE.LSOFT.COM>; Fri, 10 May 2002 19:37:28 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 976130 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 10 May 2002 19:37:59 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Fri, 10 May 2002 19:37:59 -0400 Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with esmtp (Exim 3.36 #1) id 176JxV-000NT9-00; Fri, 10 May 2002 16:37:57 -0700 X-Mailer: The Bat! (v1.51) Personal X-Priority: 3 (Normal) References: <20020510182443.28215.qmail@web12704.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <742231796.20020510163655@psg.com> Date: Fri, 10 May 2002 16:36:55 -0700 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: IP Destination address of hello packets in point to multipoint mode Comments: To: Suvani Kaura To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20020510182443.28215.qmail@web12704.mail.yahoo.com> Content-Transfer-Encoding: 7bit Suvani, What you're seeing is broadcast emulation where the lack of broadcast capability of the cloud is hidden from the routing layer by replication of IP-multicast packets performed by the device driver. Following the tradition of referring people to books, please see section 9.2.9.4 of "Cisco IP Routing: Packet Forwarding & Intra-domain Routing Protocols" :) -- Alex Friday, May 10, 2002, 11:24:42 AM, you wrote: > Hi All, >>From reading RFC2328 (sections 8.1, 7.1 & 9.5), I interpreted that > hello packets sent in point to multipoint mode should be sent > directly to each of the neighbors as unicasts. However, I recently > saw a commercial router send hellos to the AllSpfRouters multicast > address. Which is the correct way? > Thanks in advance, > Suvani > __________________________________________________ > Do You Yahoo!? > Yahoo! Shopping - Mother's Day is May 12th! > http://shopping.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Sat May 11 09:31:26 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29182 for ; Sat, 11 May 2002 09:31:26 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <3.F8156730@PEAR.EASE.LSOFT.COM>; Sat, 11 May 2002 9:30:38 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 978319 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 11 May 2002 09:31:10 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Sat, 11 May 2002 09:31:09 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Sat, 11 May 2002 09:27:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Sat, 11 May 2002 07:47:12 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Restart signaling, DR/BDR, and RouterDeadInterval To: OSPF@DISCUSS.MICROSOFT.COM Folks, I had further thoughts, on this("restart signaling") and "hitless restart" in general. 1. I guess in case of "restart signalling" it could help to actually maintain DR state. This could be easily done by checking DR value from neighbors hellos on broadcast/nbma interfaces and using that value in the hellos, before sending own hellos. 2. I have been wondering about this for some time. If a router could make out that the other end is hitless restart capable and is going an unplanned restart, we could wait for some more time(HitlessRestartInterval > RouterDeadInterval) that could be signalled whenever the adjacencies were brought up at init time. The way to do this could be to check if pings are working, to the neighbors interface, but the OSPF process itself is not working. What I mean to say if the helper could be informed that the adjacent router is going an unplanned outage(by any method) it could actually wait for a longer period than the RouterDeadInterval in case of unplanned outage too. So couldn't we keep a provision for this. 3. Regarding the avoiding exit of hitless restart in case we know that routing loops would not occur. The conclusion I got to was that a) We could either have a helper H, exit hitless restart whenever a route to D in the helper H changed (as agreed before earlier on the list). (i.e. the route on atleast one of the neighbors would change for a route on the restarting router R to change) b) Or we could have if a changed PATH on helper H to the destination D, does not go thru the restarting router R, we need not exit hitless restart. However we need would require all routers H to have the same behaviour(a or b). My observation to the above is that, it would be easier to do a). Thanks, Vishwas -----Original Message----- From: Manral, Vishwas [mailto:VishwasM@NETPLANE.COM] Sent: Friday, May 10, 2002 11:13 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Restart signaling, DR/BDR, and RouterDeadInterval Mitchell, I guess the "restart signaling" draft is now located at http://www.ietf.org/internet-drafts/draft-nguyen-ospf-restart-00.txt Though Alex, or some other draft author would give the exact details, I think this draft does not bother about keeping DR state, so if a DR router goes down, and comes up it may no longer be the DR after the DR election. Things I guess work as per the base RFC2328. Acee, Thanks for the information. (However I don't remember asking a question related to this. ;-)) Thanks, Vishwas -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Friday, May 10, 2002 9:07 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Restart signaling, DR/BDR, and RouterDeadInterval Michelle, Manral, There are two hitless restart drafts. Although I was not at the specific meeting, the one below is the one that was accepted by the OSPF work group. http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-02.txt IMHO, it does address your questions although there is currently no provision for a restart that doesn't proceed within the router dead interval. We are considering this for our implementation. Erblichs wrote: > OSPF Restart Signaling.. Feb01 to Sept01 > > Hi Group, > > I didn't see if this became a standard, so > this clarification / question could be moot.. > > Just thinking of the proper way to code > this.. > > I assume that if a hello is recieved from > a restart router within the RouterDeadInterval > timeframe, then there is significantly less > work... There was no intervening teardown.. > > However, what is not mentioned, and I want to > clarify this.. > > Assume both routers support Restart.. > If the restarting router was the DR or the BDR, > there is no assumption that if the restart was > done WITHIN the RouterDeadInterval timeframe, > the adjacency is still up, that a restarting > router would stay the BDR or DR... > > Assume both routers support restart.. > Else, NOT WITHIN the RouterDeadInterval timeframe. > We have to assume that there was a intervening > election. Would we do another election? > > There is no mention of election effects / side-effects > with respect to the restarting router, when all or > some routers support restart? The non-restart supported > routers would force a re-election. > > Thanks, > Mitchell Erblich > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Sat May 11 17:14:35 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12592 for ; Sat, 11 May 2002 17:14:34 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <8.E6B67D8A@PEAR.EASE.LSOFT.COM>; Sat, 11 May 2002 17:14:10 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 979179 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 11 May 2002 17:14:42 -0400 Received: from 161.44.11.97 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Sat, 11 May 2002 17:14:42 -0400 Received: from rtp-iosxdm1.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4BLF7V4002794; Sat, 11 May 2002 17:15:08 -0400 (EDT) Received: (lhnguyen@localhost) by rtp-iosxdm1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA19585; Sat, 11 May 2002 17:14:41 -0400 (EDT) References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <20020511171441.A10597@rtp-iosxdm1.cisco.com> Date: Sat, 11 May 2002 17:14:41 -0400 Reply-To: Mailing List Sender: Mailing List From: Liem Nguyen Subject: Re: Restart signaling, DR/BDR, and RouterDeadInterval To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: ; from VishwasM@NETPLANE.COM on Sat, May 11, 2002 at 07:47:12AM -0400 On Sat, May 11, 2002 at 07:47:12AM -0400, Manral, Vishwas wrote: > Folks, > > I had further thoughts, on this("restart signaling") and "hitless restart" > in general. > > 1. I guess in case of "restart signalling" it could help to actually > maintain DR state. This could be easily done by checking DR value from > neighbors hellos on broadcast/nbma interfaces and using that value in the > hellos, before sending own hellos. If the neighbors are aware that you are restarting (via restart signaling), then DR/BDR can certainly be retained as you suggested. In fact, we do that in our implementation. > 2. I have been wondering about this for some time. > > If a router could make out that the other end is hitless restart capable and > is going an unplanned restart, we could wait for some more > time(HitlessRestartInterval > RouterDeadInterval) that could be signalled > whenever the adjacencies were brought up at init time. The way to do this > could be to check if pings are working, to the neighbors interface, but the > OSPF process itself is not working. > > What I mean to say if the helper could be informed that the adjacent router > is going an unplanned outage(by any method) it could actually wait for a > longer period than the RouterDeadInterval in case of unplanned outage too. > So couldn't we keep a provision for this. IMO, if hitless restart procedure isn't initiated (not necessarily finished) at RouterDeadInterval expiry, then hitless restart should be aborted. Liem > > 3. Regarding the avoiding exit of hitless restart in case we know that > routing loops would not occur. The conclusion I got to was that > a) We could either have a helper H, exit hitless restart whenever a route > to D in the helper H changed (as agreed before earlier on the list). (i.e. > the route on atleast one of the neighbors would change for a route on the > restarting router R to change) > b) Or we could have if a changed PATH on helper H to the destination D, > does not go thru the restarting router R, we need not exit hitless restart. > > However we need would require all routers H to have the same behaviour(a or > b). My observation to the above is that, it would be easier to do a). > > Thanks, > Vishwas > > -----Original Message----- > From: Manral, Vishwas [mailto:VishwasM@NETPLANE.COM] > Sent: Friday, May 10, 2002 11:13 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Restart signaling, DR/BDR, and RouterDeadInterval > > > Mitchell, > > I guess the "restart signaling" draft is now located at > http://www.ietf.org/internet-drafts/draft-nguyen-ospf-restart-00.txt > > Though Alex, or some other draft author would give the exact details, I > think this draft does not bother about keeping DR state, so if a DR router > goes down, and comes up it may no longer be the DR after the DR election. > Things I guess work as per the base RFC2328. > > Acee, > > Thanks for the information. (However I don't remember asking a question > related to this. ;-)) > > Thanks, > Vishwas > > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Friday, May 10, 2002 9:07 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Restart signaling, DR/BDR, and RouterDeadInterval > > > Michelle, Manral, > > There are two hitless restart drafts. Although I was not at > the specific meeting, the one below is the one that was accepted > by the OSPF work group. > > http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-02.txt > > IMHO, it does address your questions although there is > currently no provision for a restart that doesn't proceed within > the router dead interval. We are considering this for our > implementation. > > > Erblichs wrote: > > OSPF Restart Signaling.. Feb01 to Sept01 > > > > Hi Group, > > > > I didn't see if this became a standard, so > > this clarification / question could be moot.. > > > > Just thinking of the proper way to code > > this.. > > > > I assume that if a hello is recieved from > > a restart router within the RouterDeadInterval > > timeframe, then there is significantly less > > work... There was no intervening teardown.. > > > > However, what is not mentioned, and I want to > > clarify this.. > > > > Assume both routers support Restart.. > > If the restarting router was the DR or the BDR, > > there is no assumption that if the restart was > > done WITHIN the RouterDeadInterval timeframe, > > the adjacency is still up, that a restarting > > router would stay the BDR or DR... > > > > Assume both routers support restart.. > > Else, NOT WITHIN the RouterDeadInterval timeframe. > > We have to assume that there was a intervening > > election. Would we do another election? > > > > There is no mention of election effects / side-effects > > with respect to the restarting router, when all or > > some routers support restart? The non-restart supported > > routers would force a re-election. > > > > Thanks, > > Mitchell Erblich > > > > > -- > Acee -- Liem Nguyen From owner-ospf@DISCUSS.MICROSOFT.COM Sat May 11 17:31:23 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13172 for ; Sat, 11 May 2002 17:31:22 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <9.FF43FA7D@PEAR.EASE.LSOFT.COM>; Sat, 11 May 2002 17:30:58 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 979260 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 11 May 2002 17:31:29 -0400 Received: from 207.217.120.122 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Sat, 11 May 2002 17:31:29 -0400 Received: from 209-239-207-172.oak.jps.net ([209.239.207.172] helo=earthlink.net) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 176eSe-0007Vf-00 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 11 May 2002 14:31:28 -0700 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: <3CDBE805.2823777C@earthlink.net> <3CDBE917.5020400@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3CDD8FA9.FA2D7438@earthlink.net> Date: Sat, 11 May 2002 14:39:53 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Restart signaling, DR/BDR, and RouterDeadInterval To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Hi, Thanks for the pointer.. I actually already looked at a Hitless Restart 02.. by Moy Feb 02 to Aug 02 and wanted to see if there was any feedback before I suggested or commented on it. :-). Since, I have a few issues that I would like to clarify, I will send a separate email identifying the items.. Mitchell Erblich ----------------------------- Acee Lindem wrote: > > Michelle, Manral, > > There are two hitless restart drafts. Although I was not at > the specific meeting, the one below is the one that was accepted > by the OSPF work group. > > http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-02.txt > > IMHO, it does address your questions although there is > currently no provision for a restart that doesn't proceed within > the router dead interval. We are considering this for our > implementation. > > Erblichs wrote: > > OSPF Restart Signaling.. Feb01 to Sept01 > > > > Hi Group, > > > > I didn't see if this became a standard, so > > this clarification / question could be moot.. > > > > Just thinking of the proper way to code > > this.. > > > > I assume that if a hello is recieved from > > a restart router within the RouterDeadInterval > > timeframe, then there is significantly less > > work... There was no intervening teardown.. > > > > However, what is not mentioned, and I want to > > clarify this.. > > > > Assume both routers support Restart.. > > If the restarting router was the DR or the BDR, > > there is no assumption that if the restart was > > done WITHIN the RouterDeadInterval timeframe, > > the adjacency is still up, that a restarting > > router would stay the BDR or DR... > > > > Assume both routers support restart.. > > Else, NOT WITHIN the RouterDeadInterval timeframe. > > We have to assume that there was a intervening > > election. Would we do another election? > > > > There is no mention of election effects / side-effects > > with respect to the restarting router, when all or > > some routers support restart? The non-restart supported > > routers would force a re-election. > > > > Thanks, > > Mitchell Erblich > > > > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Sat May 11 18:51:42 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15829 for ; Sat, 11 May 2002 18:51:42 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <11.F9E5665E@PEAR.EASE.LSOFT.COM>; Sat, 11 May 2002 18:51:18 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 979389 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 11 May 2002 18:51:50 -0400 Received: from 207.217.120.74 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Sat, 11 May 2002 18:51:50 -0400 Received: from 209-239-204-128.oak.jps.net ([209.239.204.128] helo=earthlink.net) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 176fiO-0004Zk-00 for ospf@discuss.microsoft.com; Sat, 11 May 2002 15:51:49 -0700 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3CDDA283.9661130D@earthlink.net> Date: Sat, 11 May 2002 16:00:19 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Hitless Restart 02 : 2-way, BDR, grace policy To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Hitless Restart -02 by J. Moy : Feb02 to Aug02 Pre-note: I have NOT previously done this level of restart with a grace-LSA and am not currently working on this type of functionality.. My assumptions are that I understand this draft and their are a few things that may be a bit clearer... Sorry ahead of time... 1) Overview 1.: Should their by an explicit statement that 2-way DRothers link partners, not not play a role in hitless restart? 2) Overview 1.: If you are a DRother, what does this really gain you? 3) Is restart time started when the first grace-LSA is sent out OR when the last grace-LSA is acknowledged? 4) 2) Op of restart router (3) If the restarting ... Couldn't you use nvram to store that you were the DR? You then wouldn't have to wait 1/2 on average of the hello interval.. Complication, what happens with demand circuits and suppressed hellos? 5) Same section as #4. How do you preserve the fact that you were the BDR in this Draft? I actually don't really see any mention of the BDR... -- My suggestion in #4 would work as well for a BDR or a DRother.. #4 and #5) For consistency sake, these items should then be checked with hellos, etc.. 6) 2.1) (2) What happens if the nvram cypto seq # somehow is no-longer correct after the restart? I assume this can be changed. 7) 2.1) A grace-LSA is originated .. Am I correct in assuming that the below question would be implicitly covered as a topolgy change and proceed to normal restart? What happens if a BDR comes up during restart (before all grace-LSA are acknowledged? 8) 2.1) A grace-LSA is originated .. A) Conflict with 3.1 (4)b. How do you resolve a grace-LSAs that were xmit'ed and acked by one or more neighbors and one or more grace-LSAs that are in conflict with exceeding the local policy of time T. B) How do you detect that you are violating time T? C) Can you resend a grace-LSA with a different grace-period? What should a router do, if two grace-LSAs were sent with the same grace-periods? With different grace periods? D) What happens if you violate your grace-LSA value? E) What happens if the grace-period is exceeding long and router X was the DR? F) When do you stop re-xmiting grace-LSAs and proceed to normal restart? Can you spend you entire grace-period doing re-xmits? 9) 2.2 (2) add a d) router that would be a helper candidate came up after restart was started and all grace-LSAs were acknowledged. 10) Why not save xmit OSPF hellos per interface in nvram, so after a restart prior restart hellos can be reloaded and sent? 11) #4) "or they do not recieved the grace-LSA" I don't understand this phrase.. Are you talking about not reciving a ack from a router Y candidate? Thanks, Mitchell Erblich From owner-ospf@DISCUSS.MICROSOFT.COM Mon May 13 09:47:00 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09963 for ; Mon, 13 May 2002 09:46:59 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <10.F8E047A0@PEAR.EASE.LSOFT.COM>; Mon, 13 May 2002 9:46:37 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 984041 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 13 May 2002 09:47:10 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Mon, 13 May 2002 09:47:10 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 47FC3CAB7D for ; Mon, 13 May 2002 06:47:09 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20020510182443.28215.qmail@web12704.mail.yahoo.com> <742231796.20020510163655@psg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3CDFC3AB.60602@redback.com> Date: Mon, 13 May 2002 09:46:19 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: IP Destination address of hello packets in point to multipoint mode To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Suvani, RFC 2328 (which is a standards track RFC) is correct. However, if you're implementing OSPF you'll need to adhere to Jon Postal's advice and "be liberal in what you accept from others". Most implementations support point-to-multipoint packets sent both to your unicast address and the OSPF multicast addresses. Alex Zinin wrote: > Suvani, > > What you're seeing is broadcast emulation where > the lack of broadcast capability of the cloud is > hidden from the routing layer by replication of > IP-multicast packets performed by the device driver. Alex, Conceptually, it doesn't seem that this is correct since OSPF doesn't view the network topologically as a broadcast network (i.e., fully meshed). Oh well, it is a moot point. > > Following the tradition of referring people to books, > please see section 9.2.9.4 of "Cisco IP Routing: Packet > Forwarding & Intra-domain Routing Protocols" :) > > -- > Alex > > Friday, May 10, 2002, 11:24:42 AM, you wrote: > >>Hi All, > > >>>From reading RFC2328 (sections 8.1, 7.1 & 9.5), I interpreted that >>hello packets sent in point to multipoint mode should be sent >>directly to each of the neighbors as unicasts. However, I recently >>saw a commercial router send hellos to the AllSpfRouters multicast >>address. Which is the correct way? > > >>Thanks in advance, >>Suvani > > >>__________________________________________________ >>Do You Yahoo!? >>Yahoo! Shopping - Mother's Day is May 12th! >>http://shopping.yahoo.com > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon May 13 10:47:56 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13634 for ; Mon, 13 May 2002 10:47:55 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <2.FF1FB68E@PEAR.EASE.LSOFT.COM>; Mon, 13 May 2002 10:47:31 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 984422 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 13 May 2002 10:48:04 -0400 Received: from 216.136.173.245 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Mon, 13 May 2002 10:48:04 -0400 Received: from [192.25.240.26] by web12708.mail.yahoo.com via HTTP; Mon, 13 May 2002 07:48:03 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020513144803.61885.qmail@web12708.mail.yahoo.com> Date: Mon, 13 May 2002 07:48:03 -0700 Reply-To: Mailing List Sender: Mailing List From: Suvani Kaura Subject: Re: IP Destination address of hello packets in point to multipoint mode To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3CDFC3AB.60602@redback.com> Thanks, Acee & Alex. --- Acee Lindem wrote: > Suvani, > > RFC 2328 (which is a standards track RFC) is correct. However, > if you're implementing OSPF you'll need to adhere to Jon Postal's > advice and "be liberal in what you accept from others". Most > implementations support point-to-multipoint packets sent both to > your > unicast address and the OSPF multicast addresses. > > Alex Zinin wrote: > > Suvani, > > > > What you're seeing is broadcast emulation where > > the lack of broadcast capability of the cloud is > > hidden from the routing layer by replication of > > IP-multicast packets performed by the device driver. > > > Alex, > > Conceptually, it doesn't seem that this is correct since > OSPF doesn't view the network topologically as a broadcast > network (i.e., fully meshed). Oh well, it is a moot point. > > > > > Following the tradition of referring people to books, > > please see section 9.2.9.4 of "Cisco IP Routing: Packet > > Forwarding & Intra-domain Routing Protocols" :) > > > > -- > > Alex > > > > Friday, May 10, 2002, 11:24:42 AM, you wrote: > > > >>Hi All, > > > > > >>>From reading RFC2328 (sections 8.1, 7.1 & 9.5), I interpreted > that > >>hello packets sent in point to multipoint mode should be sent > >>directly to each of the neighbors as unicasts. However, I > recently > >>saw a commercial router send hellos to the AllSpfRouters > multicast > >>address. Which is the correct way? > > __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Mon May 13 13:52:59 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22275 for ; Mon, 13 May 2002 13:52:59 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <0.EB65F98B@PEAR.EASE.LSOFT.COM>; Mon, 13 May 2002 13:52:35 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 985356 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 13 May 2002 13:53:09 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Mon, 13 May 2002 13:53:09 -0400 Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with esmtp (Exim 3.36 #1) id 177K0O-0001y7-00; Mon, 13 May 2002 10:53:04 -0700 X-Mailer: The Bat! (v1.51) Personal X-Priority: 3 (Normal) References: <20020510182443.28215.qmail@web12704.mail.yahoo.com> <742231796.20020510163655@psg.com> <3CDFC3AB.60602@redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <651355150.20020513105133@psg.com> Date: Mon, 13 May 2002 10:51:33 -0700 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: IP Destination address of hello packets in point to multipoint mode Comments: To: Acee Lindem To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3CDFC3AB.60602@redback.com> Content-Transfer-Encoding: 7bit Acee, > Conceptually, it doesn't seem that this is correct since > OSPF doesn't view the network topologically as a broadcast > network (i.e., fully meshed). Oh well, it is a moot point. In fact, there are two modes: pure broadcast emulation, and p2mp with broadcast emulation. In the former case OSPF has no idea it's NBMA, the driver performs packet replication, but the admin needs to make sure there's any-any connectivity between nodes. In the latter case everything is like in p2mp except for the dst address and that you don't have to configure OSPF neighbors manually. Alex From owner-ospf@DISCUSS.MICROSOFT.COM Mon May 13 15:04:20 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26781 for ; Mon, 13 May 2002 15:04:19 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <14.F575AC93@PEAR.EASE.LSOFT.COM>; Mon, 13 May 2002 15:03:57 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 985572 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 13 May 2002 15:04:30 -0400 Received: from 216.136.226.82 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Mon, 13 May 2002 15:04:30 -0400 Received: from [149.112.94.138] by web20301.mail.yahoo.com via HTTP; Mon, 13 May 2002 12:04:28 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020513190429.51898.qmail@web20301.mail.yahoo.com> Date: Mon, 13 May 2002 12:04:28 -0700 Reply-To: Mailing List Sender: Mailing List From: Ash he Subject: Re: IP Destination address of hello packets in point to multipoint mode To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <651355150.20020513105133@psg.com> I agree with Alex. Routers do support broadcast emulation (pseudo-broadcast as cisco terms it) on P2P interfaces in much the same way. Its the view that the interface offers to OSPF i.e. P2mP or broadcast. In the broadcast mode OSPF would behave as though it were using an ethernet. Full/selective meshing would be a configuration issue. --- Alex Zinin wrote: > Acee, > > > Conceptually, it doesn't seem that this is correct > since > > OSPF doesn't view the network topologically as a > broadcast > > network (i.e., fully meshed). Oh well, it is a > moot point. > > In fact, there are two modes: pure broadcast > emulation, > and p2mp with broadcast emulation. In the former > case OSPF > has no idea it's NBMA, the driver performs packet > replication, but the admin needs to make sure > there's > any-any connectivity between nodes. In the latter > case > everything is like in p2mp except for the dst > address > and that you don't have to configure OSPF neighbors > manually. > > Alex __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Mon May 13 19:58:30 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10026 for ; Mon, 13 May 2002 19:58:29 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <8.E6B67E6B@PEAR.EASE.LSOFT.COM>; Mon, 13 May 2002 19:58:06 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 986524 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 13 May 2002 19:58:39 -0400 Received: from 205.226.5.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Mon, 13 May 2002 19:48:39 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA22689 for ; Mon, 13 May 2002 16:48:37 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4DNmaT20442 for ; Mon, 13 May 2002 16:48:36 -0700 X-mProtect: <200205132348> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.11.92, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd47rYjA; Mon, 13 May 2002 16:48:34 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3CE050D3.7A4C8113@iprg.nokia.com> Date: Mon, 13 May 2002 16:48:35 -0700 Reply-To: Mailing List Sender: Mailing List From: Mukesh Gupta Organization: Nokia IPRG Subject: Using AH for Authentication for OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Hi All, I am working on providing authentication for OSPFv3 using IPv6 AH extension header. RFC 2740 suggests using AH/ESP extension headers of IPv6 for OSPF authentication but doesn't provide details about how exactly this needs to be done. It seems that OSPFv3 shouldn't need to worry about it and it is kernel's responsibility to provide AH authentication for all OSPFv3 packets. This way OSPFv3 only receives authenticated packets. OSPFv3 uses both multicast and unicast packets. Is there any standard way of handling these packets using IPsec AH ?? Is there any standard way of implementing OSPFv3 Authentication using AH extension header ?? Is there any vendor out there who has implemented it ?? Comments/Suggestions would be highly appreciated. regards Mukesh -- ****************************************************************** Often the best way to win is to forget to keep score. ****************************************************************** Mukesh Gupta Phone: (650) 625-2264 Cell : (650) 868-9111 http://www.iprg.nokia.com/~mgupta ****************************************************************** From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 14 16:54:51 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06459 for ; Tue, 14 May 2002 16:54:51 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <1.FEA93E4D@PEAR.EASE.LSOFT.COM>; Tue, 14 May 2002 16:54:18 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 990551 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 14 May 2002 16:54:52 -0400 Received: from 205.226.5.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Tue, 14 May 2002 16:44:51 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA14909; Tue, 14 May 2002 13:44:48 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4EKikH32140; Tue, 14 May 2002 13:44:46 -0700 X-mProtect: <200205142044> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.11.92, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdBuabPc; Tue, 14 May 2002 13:44:45 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <4.3.2.7.1.20020514102916.00ae88a0@golf.cpgdesign.analog.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3CE1773D.46A19A6B@iprg.nokia.com> Date: Tue, 14 May 2002 13:44:45 -0700 Reply-To: Mailing List Sender: Mailing List From: Mukesh Gupta Organization: Nokia IPRG Subject: Re: Using AH for Authentication for OSPFv3 Comments: To: Ramana Yarlagadda Comments: cc: ipsec@lists.tislabs.com To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit > IPSec provides security at IP level so the OSPF may not need any special > mechanism to provide security services to OSPF data. All you might need > is to configure a policy. That's right. > >OSPFv3 uses both multicast and unicast packets. Is there any standard > >way of handling these packets using IPsec AH ?? > > > >Is there any standard way of implementing OSPFv3 Authentication using AH > >extension header ?? Is there any vendor out there who has implemented it > >?? > > The RFC2740 clearly says that OSPF is not doing any Authentication part. > For your reference i am copying the RFC... > > Authentication has been removed from the OSPF protocol itself, instead > relying on IPv6's Authentication Header and Encapsulating Security > Payload. I am clear about the part that OSPF is not doing any authentication and IPsec is going to provide the security required. Since OSPF is going to send both unicast and multicast traffic and it is going to be a point to multipoint security, the implementation is little more involved. I was wondering if there is any standard way of taking care of the issues. Is there any vendor out there who has implemented this or planning to implement this in near future ?? regards Mukesh -- ****************************************************************** Often the test of courage is to not to die,but to live. ****************************************************************** Mukesh Gupta Phone: (650) 625-2264 Cell : (650) 868-9111 http://www.iprg.nokia.com/~mgupta ****************************************************************** From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 14 16:59:51 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06702 for ; Tue, 14 May 2002 16:59:50 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <15.F6DC75F3@PEAR.EASE.LSOFT.COM>; Tue, 14 May 2002 16:59:26 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 990606 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 14 May 2002 17:00:00 -0400 Received: from 207.217.120.123 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Tue, 14 May 2002 17:00:00 -0400 Received: from 209-239-201-209.oak.jps.net ([209.239.201.209] helo=earthlink.net) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 177jOo-0002MK-00 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 14 May 2002 13:59:59 -0700 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: <4.3.2.7.1.20020514102916.00ae88a0@golf.cpgdesign.analog.com> <3CE1773D.46A19A6B@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3CE17CD3.55FA7E66@earthlink.net> Date: Tue, 14 May 2002 14:08:35 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Using AH for Authentication for OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Group, If this helps, in the end system space, I think Sun's Solaris has IPSec support... For intermediate systems, ... ??? Mitchell Erblich ---------------------- Mukesh Gupta wrote: > > > IPSec provides security at IP level so the OSPF may not need any special > > mechanism to provide security services to OSPF data. All you might need > > is to configure a policy. > > That's right. > > > >OSPFv3 uses both multicast and unicast packets. Is there any standard > > >way of handling these packets using IPsec AH ?? > > > > > >Is there any standard way of implementing OSPFv3 Authentication using AH > > >extension header ?? Is there any vendor out there who has implemented it > > >?? > > > > The RFC2740 clearly says that OSPF is not doing any Authentication part. > > For your reference i am copying the RFC... > > > > Authentication has been removed from the OSPF protocol itself, instead > > relying on IPv6's Authentication Header and Encapsulating Security > > Payload. > > I am clear about the part that OSPF is not doing any authentication and > IPsec is going to provide the security required. Since OSPF is going to send > both unicast and multicast traffic and it is going to be a point to > multipoint security, the implementation is little more involved. I was > wondering if there is any standard way of taking care of the issues. > > Is there any vendor out there who has implemented this or planning to > implement this in near future ?? > > regards > Mukesh > > -- > ****************************************************************** > Often the test of courage is to not to die,but to live. > ****************************************************************** > Mukesh Gupta > Phone: (650) 625-2264 > Cell : (650) 868-9111 > http://www.iprg.nokia.com/~mgupta > ****************************************************************** From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 14 19:25:07 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11768 for ; Tue, 14 May 2002 19:25:06 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <0.EB65FA2F@PEAR.EASE.LSOFT.COM>; Tue, 14 May 2002 19:24:42 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 990858 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 14 May 2002 19:25:16 -0400 Received: from 205.226.5.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Tue, 14 May 2002 19:25:07 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA23742 for ; Tue, 14 May 2002 16:25:06 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4ENP5K20154 for ; Tue, 14 May 2002 16:25:05 -0700 X-mProtect: <200205142325> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.140.126, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCRgmZL; Tue, 14 May 2002 16:25:03 PDT X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <4.3.2.7.1.20020514102916.00ae88a0@golf.cpgdesign.analog.com> <3CE1773D.46A19A6B@iprg.nokia.com> <3CE17CD3.55FA7E66@earthlink.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3CE19CD0.6DCBF5E@iprg.nokia.com> Date: Tue, 14 May 2002 16:25:04 -0700 Reply-To: Mailing List Sender: Mailing List From: Mukesh Gupta Organization: Nokia Subject: Re: Using AH for Authentication for OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit IPsec is supported on many platforms now a days. What I am looking for is OSPFv3 (OSPF for IPv6) implementation with Authentication using IPsec. regards Mukesh Erblichs wrote: > Group, > > If this helps, in the end system space, I think > Sun's Solaris has IPSec support... > > For intermediate systems, ... ??? > > Mitchell Erblich > ---------------------- > > Mukesh Gupta wrote: > > > > > IPSec provides security at IP level so the OSPF may not need any special > > > mechanism to provide security services to OSPF data. All you might need > > > is to configure a policy. > > > > That's right. > > > > > >OSPFv3 uses both multicast and unicast packets. Is there any standard > > > >way of handling these packets using IPsec AH ?? > > > > > > > >Is there any standard way of implementing OSPFv3 Authentication using AH > > > >extension header ?? Is there any vendor out there who has implemented it > > > >?? > > > > > > The RFC2740 clearly says that OSPF is not doing any Authentication part. > > > For your reference i am copying the RFC... > > > > > > Authentication has been removed from the OSPF protocol itself, instead > > > relying on IPv6's Authentication Header and Encapsulating Security > > > Payload. > > > > I am clear about the part that OSPF is not doing any authentication and > > IPsec is going to provide the security required. Since OSPF is going to send > > both unicast and multicast traffic and it is going to be a point to > > multipoint security, the implementation is little more involved. I was > > wondering if there is any standard way of taking care of the issues. > > > > Is there any vendor out there who has implemented this or planning to > > implement this in near future ?? > > > > regards > > Mukesh > > > > -- > > ****************************************************************** > > Often the test of courage is to not to die,but to live. > > ****************************************************************** > > Mukesh Gupta > > Phone: (650) 625-2264 > > Cell : (650) 868-9111 > > http://www.iprg.nokia.com/~mgupta > > ****************************************************************** -- ****************************************************************** Often the test of courage is to not to die,but to live. ****************************************************************** Mukesh Gupta Phone: (650) 625-2264 Cell : (650) 868-9111 http://www.iprg.nokia.com/~mgupta ****************************************************************** From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 14 20:08:55 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13026 for ; Tue, 14 May 2002 20:08:54 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <5.F3EA63E2@PEAR.EASE.LSOFT.COM>; Tue, 14 May 2002 20:08:30 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 990994 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 14 May 2002 20:09:04 -0400 Received: from 207.217.120.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Tue, 14 May 2002 20:09:04 -0400 Received: from 209-239-201-147.oak.jps.net ([209.239.201.147] helo=earthlink.net) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 177mLm-00001z-00 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 14 May 2002 17:09:02 -0700 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: <4.3.2.7.1.20020514102916.00ae88a0@golf.cpgdesign.analog.com> <3CE1773D.46A19A6B@iprg.nokia.com> <3CE17CD3.55FA7E66@earthlink.net> <3CE19CD0.6DCBF5E@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3CE1A922.84B8B0E1@earthlink.net> Date: Tue, 14 May 2002 17:17:38 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Using AH for Authentication for OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Mukesh, What you are really asking is when and where will a XXX, ZZZ, etc is going to publicly announce that they have deployments of routers with OSPFv3 support? My question to you, how do you know that for instance, XXX and ZZZ, etc doesn't have OSPFv3/ IPv6 software installed but just not enabled? It it up to their customers and their marketing/sales group to decide when they plan to announce levels of functionality. Mitchell Erblich Mukesh Gupta wrote: > > IPsec is supported on many platforms now a days. > > What I am looking for is OSPFv3 (OSPF for IPv6) implementation with Authentication > using IPsec. > > regards > Mukesh > > Erblichs wrote: > > > Group, > > > > If this helps, in the end system space, I think > > Sun's Solaris has IPSec support... > > > > For intermediate systems, ... ??? > > > > Mitchell Erblich > > ---------------------- > > > > Mukesh Gupta wrote: > > > > > > > IPSec provides security at IP level so the OSPF may not need any special > > > > mechanism to provide security services to OSPF data. All you might need > > > > is to configure a policy. > > > > > > That's right. > > > > > > > >OSPFv3 uses both multicast and unicast packets. Is there any standard > > > > >way of handling these packets using IPsec AH ?? > > > > > > > > > >Is there any standard way of implementing OSPFv3 Authentication using AH > > > > >extension header ?? Is there any vendor out there who has implemented it > > > > >?? > > > > > > > > The RFC2740 clearly says that OSPF is not doing any Authentication part. > > > > For your reference i am copying the RFC... > > > > > > > > Authentication has been removed from the OSPF protocol itself, instead > > > > relying on IPv6's Authentication Header and Encapsulating Security > > > > Payload. > > > > > > I am clear about the part that OSPF is not doing any authentication and > > > IPsec is going to provide the security required. Since OSPF is going to send > > > both unicast and multicast traffic and it is going to be a point to > > > multipoint security, the implementation is little more involved. I was > > > wondering if there is any standard way of taking care of the issues. > > > > > > Is there any vendor out there who has implemented this or planning to > > > implement this in near future ?? > > > > > > regards > > > Mukesh > > > > > > -- > > > ****************************************************************** > > > Often the test of courage is to not to die,but to live. > > > ****************************************************************** > > > Mukesh Gupta > > > Phone: (650) 625-2264 > > > Cell : (650) 868-9111 > > > http://www.iprg.nokia.com/~mgupta > > > ****************************************************************** > > -- > ****************************************************************** > Often the test of courage is to not to die,but to live. > ****************************************************************** > Mukesh Gupta > Phone: (650) 625-2264 > Cell : (650) 868-9111 > http://www.iprg.nokia.com/~mgupta > ****************************************************************** From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 14 20:35:11 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13735 for ; Tue, 14 May 2002 20:35:10 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <15.F6DC75FF@PEAR.EASE.LSOFT.COM>; Tue, 14 May 2002 20:34:46 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 991069 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 14 May 2002 20:35:21 -0400 Received: from 63.165.80.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Tue, 14 May 2002 20:35:20 -0400 Received: from apollo.adtech-inc.com (apollo.adtech-inc.com [10.12.0.17]) by Thor.Adtech-Inc.COM (8.10.2+Sun/8.10.2) with ESMTP id g4F0ZJW03875 for ; Tue, 14 May 2002 14:35:19 -1000 (HST) Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 May 2002 14:41:44 -1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <8AC36D3167EED41184C800508BD954050320B557@apollo.adtech-inc.com> Date: Tue, 14 May 2002 14:41:36 -1000 Reply-To: Mailing List Sender: Mailing List From: "Singh, Gurpreet" Subject: Re: Using AH for Authentication for OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Hi I have seen some e-mails regarding OSPFv3 on the mailing list. Is there any draft for OSPFv3. Where can i find it ? Thanks Gurpreet -----Original Message----- From: Mukesh Gupta [mailto:mgupta@IPRG.NOKIA.COM] Sent: Tuesday, May 14, 2002 4:45 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Using AH for Authentication for OSPFv3 > IPSec provides security at IP level so the OSPF may not need any special > mechanism to provide security services to OSPF data. All you might need > is to configure a policy. That's right. > >OSPFv3 uses both multicast and unicast packets. Is there any standard > >way of handling these packets using IPsec AH ?? > > > >Is there any standard way of implementing OSPFv3 Authentication using AH > >extension header ?? Is there any vendor out there who has implemented it > >?? > > The RFC2740 clearly says that OSPF is not doing any Authentication part. > For your reference i am copying the RFC... > > Authentication has been removed from the OSPF protocol itself, instead > relying on IPv6's Authentication Header and Encapsulating Security > Payload. I am clear about the part that OSPF is not doing any authentication and IPsec is going to provide the security required. Since OSPF is going to send both unicast and multicast traffic and it is going to be a point to multipoint security, the implementation is little more involved. I was wondering if there is any standard way of taking care of the issues. Is there any vendor out there who has implemented this or planning to implement this in near future ?? regards Mukesh -- ****************************************************************** Often the test of courage is to not to die,but to live. ****************************************************************** Mukesh Gupta Phone: (650) 625-2264 Cell : (650) 868-9111 http://www.iprg.nokia.com/~mgupta ****************************************************************** From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 14 20:39:22 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13798 for ; Tue, 14 May 2002 20:39:21 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <10.F8E0486C@PEAR.EASE.LSOFT.COM>; Tue, 14 May 2002 20:38:57 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 991105 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 14 May 2002 20:39:31 -0400 Received: from 207.217.120.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Tue, 14 May 2002 20:39:31 -0400 Received: from 209-239-201-147.oak.jps.net ([209.239.201.147] helo=earthlink.net) by goose.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 177mpF-0004HV-00 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 14 May 2002 17:39:30 -0700 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: <8AC36D3167EED41184C800508BD954050320B557@apollo.adtech-inc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3CE1B03E.4B6D16C4@earthlink.net> Date: Tue, 14 May 2002 17:47:58 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Using AH for Authentication for OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Group, The OSPF for IPv6 is RFC 2740, with a Dec. 99 date.. I have not checked for later RFCs.. Mitchell Erblich ----------------------- "Singh, Gurpreet" wrote: > > Hi > > I have seen some e-mails regarding OSPFv3 on the mailing list. Is there any > draft for OSPFv3. Where can i find it ? > > Thanks > > Gurpreet > > -----Original Message----- > From: Mukesh Gupta [mailto:mgupta@IPRG.NOKIA.COM] > Sent: Tuesday, May 14, 2002 4:45 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Using AH for Authentication for OSPFv3 > > > IPSec provides security at IP level so the OSPF may not need any special > > mechanism to provide security services to OSPF data. All you might need > > is to configure a policy. > > That's right. > > > >OSPFv3 uses both multicast and unicast packets. Is there any standard > > >way of handling these packets using IPsec AH ?? > > > > > >Is there any standard way of implementing OSPFv3 Authentication using AH > > >extension header ?? Is there any vendor out there who has implemented it > > >?? > > > > The RFC2740 clearly says that OSPF is not doing any Authentication part. > > For your reference i am copying the RFC... > > > > Authentication has been removed from the OSPF protocol itself, instead > > relying on IPv6's Authentication Header and Encapsulating Security > > Payload. > > I am clear about the part that OSPF is not doing any authentication and > IPsec is going to provide the security required. Since OSPF is going to send > both unicast and multicast traffic and it is going to be a point to > multipoint security, the implementation is little more involved. I was > wondering if there is any standard way of taking care of the issues. > > Is there any vendor out there who has implemented this or planning to > implement this in near future ?? > > regards > Mukesh > > -- > ****************************************************************** > Often the test of courage is to not to die,but to live. > ****************************************************************** > Mukesh Gupta > Phone: (650) 625-2264 > Cell : (650) 868-9111 > http://www.iprg.nokia.com/~mgupta > ****************************************************************** From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 15 23:32:06 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02477 for ; Wed, 15 May 2002 23:32:00 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <3.F8156D15@PEAR.EASE.LSOFT.COM>; Wed, 15 May 2002 23:30:22 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 996520 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 15 May 2002 23:30:57 -0400 Received: from 128.96.41.1 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 15 May 2002 23:30:56 -0400 Received: from mailee (mailee [192.4.7.23]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g4G3UqmG022800 for ; Wed, 15 May 2002 23:30:52 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Message-ID: Date: Wed, 15 May 2002 23:30:52 -0400 Reply-To: Mailing List Sender: Mailing List From: Sanjai Narain Subject: OSPF performance estimates To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: I would appreciate pointers to papers on OSPF performance for realistically sized networks. I am particularly interested in OSPF performance on a single broadcast subnet: What is the largest number of hosts connected on a single subnet running OSPF, how fast does OSPF converge on these and how much bandwidth does it consume? Thanks. -- Sanjai From owner-ospf@DISCUSS.MICROSOFT.COM Thu May 16 04:50:20 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17732 for ; Thu, 16 May 2002 04:50:19 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <2.FF1FBBCF@PEAR.EASE.LSOFT.COM>; Thu, 16 May 2002 4:49:56 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 997358 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 16 May 2002 04:50:29 -0400 Received: from 192.91.191.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 16 May 2002 04:40:26 -0400 Received: by coltrane.datcon.co.uk with Internet Mail Service (5.5.2655.55) id ; Thu, 16 May 2002 09:40:14 +0100 X-MS-TNEF-Correlator: <53F74F5A7B94D511841C00B0D0AB16F8103309@baker.datcon.co.uk> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <53F74F5A7B94D511841C00B0D0AB16F8103309@baker.datcon.co.uk> Date: Thu, 16 May 2002 09:40:22 +0100 Reply-To: Mailing List Sender: Mailing List From: Philip Crocker Subject: Question about hitless restart with virtual links. To: OSPF@DISCUSS.MICROSOFT.COM Hello, I have a comment on the OSPF Hitless Restart draft (draft-ietf-ospf-hitless-restart-02.txt). I don't think the draft details how to ensure an unplanned hitless restart if a router has active virtual links. - In the unplanned restart case, grace LSAs are sent out to attached interfaces as soon as a router restarts. However, at this point, the router does not know the IP addresses of the ends of any virtual links it has configured. These are only discovered when a routing calculation calculates the end of a virtual link as reachable. - If a HELLO packet is sent to the virtual neighbor at this point, the virtual neighbor will reset the virtual adjacency and cause the router's hitless restart to fail, disrupting routing through the virtual link. I think there is a pretty simple solution to this problem, which is to make sure that, if we are attempting an unplanned restart, then whenever a virtual link is calculated as reachable, we send the neighbor a grace LSA before any HELLO packet. This should cause the virtual neighbor to enter helper mode and so not disrupt routing through the virtual link. This may well be the intention of the draft, but I think that, if this is the correct behaviour, it should be mentioned specifically in the draft. Thanks, Phil. ------- Phil Crocker DC-OSPF Development Team Tel: +44 20 8366 1177 Fax: +44 20 8363 1039 Data Connection Ltd Email: pjc@dataconnection.com Web: http://www.dataconnection.com From owner-ospf@DISCUSS.MICROSOFT.COM Thu May 16 05:43:53 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18755 for ; Thu, 16 May 2002 05:43:52 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <1.FEA942DD@PEAR.EASE.LSOFT.COM>; Thu, 16 May 2002 5:43:29 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 997516 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 16 May 2002 05:44:01 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 16 May 2002 05:44:00 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 May 2002 05:40:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 16 May 2002 05:43:46 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPF performance estimates To: OSPF@DISCUSS.MICROSOFT.COM Hi Sanjai, Though I am not sure there are any absolute answers to your questions(or none that I know of), which would probably depend on the router, vendor implementation, topology and other such details. You may like to have a look at the following drafts which would probably give some details:- http://www.ietf.org/internet-drafts/draft-bmwg-ospfconv-term-00.txt http://www.ietf.org/internet-drafts/draft-bmwg-ospfconv-intraarea-00.txt which are bmwg working group items. A paper giving measurements for CISCO GSR and 7513 routers using blackbox methods is given at: - http://www.research.att.com/~albert/black-box-measurement.html Thanks and HTH, Vishwas -----Original Message----- From: Sanjai Narain [mailto:narain@RESEARCH.TELCORDIA.COM] Sent: Thursday, May 16, 2002 9:01 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: OSPF performance estimates I would appreciate pointers to papers on OSPF performance for realistically sized networks. I am particularly interested in OSPF performance on a single broadcast subnet: What is the largest number of hosts connected on a single subnet running OSPF, how fast does OSPF converge on these and how much bandwidth does it consume? Thanks. -- Sanjai From owner-ospf@DISCUSS.MICROSOFT.COM Thu May 16 15:25:42 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07488 for ; Thu, 16 May 2002 15:25:41 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <7.FEBE5CC6@PEAR.EASE.LSOFT.COM>; Thu, 16 May 2002 15:24:14 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1000306 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 16 May 2002 15:24:49 -0400 Received: from 207.217.120.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 16 May 2002 15:24:49 -0400 Received: from 209-239-202-48.oak.jps.net ([209.239.202.48] helo=earthlink.net) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 178Qrn-0005Uz-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 16 May 2002 12:24:48 -0700 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: <3CE40989.98BFC654@earthlink.net> Date: Thu, 16 May 2002 12:33:29 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: OSPF performance estimates To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Interesting,, The black-box link points to a valid link, but the specified paper and talk pdf file generates a error from the Acrobat reader on my Windows '98 system. Unable to extract front WCEGBT+Times-Roman.. Mitchell Erblich ======================== "Manral, Vishwas" wrote: > > Hi Sanjai, > > Though I am not sure there are any absolute answers to your questions(or > none that I know of), which would probably depend on the router, vendor > implementation, topology and other such details. You may like to have a look > at the following drafts which would probably give some details:- > > http://www.ietf.org/internet-drafts/draft-bmwg-ospfconv-term-00.txt > > http://www.ietf.org/internet-drafts/draft-bmwg-ospfconv-intraarea-00.txt > > which are bmwg working group items. > > A paper giving measurements for CISCO GSR and 7513 routers using blackbox > methods is given at: - > > http://www.research.att.com/~albert/black-box-measurement.html > > Thanks and HTH, > Vishwas > > -----Original Message----- > From: Sanjai Narain [mailto:narain@RESEARCH.TELCORDIA.COM] > Sent: Thursday, May 16, 2002 9:01 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: OSPF performance estimates > > I would appreciate pointers to papers on OSPF performance for > realistically sized networks. I am particularly interested in OSPF > performance on a single broadcast subnet: What is the largest number of > hosts connected on a single subnet running OSPF, how fast does OSPF converge > on > these and how much bandwidth does it consume? Thanks. -- Sanjai From owner-ospf@DISCUSS.MICROSOFT.COM Thu May 16 15:37:55 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08260 for ; Thu, 16 May 2002 15:37:54 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <1.FEA9433B@PEAR.EASE.LSOFT.COM>; Thu, 16 May 2002 15:37:30 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1000327 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 16 May 2002 15:38:05 -0400 Received: from 167.73.110.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 16 May 2002 15:28:05 -0400 Received: by dcntmta02.spectrum-health.org with Internet Mail Service (5.5.2653.19) id ; Thu, 16 May 2002 15:28:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FD0F.CC431650" Message-ID: <3636B731B4B310479DFED87FC055CE1302B71B01@dcntmsg05.spectrum-health.org> Date: Thu, 16 May 2002 15:28:03 -0400 Reply-To: Mailing List Sender: Mailing List From: Jeffrey Welch Subject: Re: OSPF performance estimates To: OSPF@DISCUSS.MICROSOFT.COM 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_01C1FD0F.CC431650 Content-Type: text/plain Greetings, Utilizing Adobe Acrobat 5.0 and running Windows XP, I was able to open the .PDF document in my IE browser ok. (I'm also running Internet Explorer 5.5) Just an FYI. You may need to upgrade either your Adobe software or your browser. (Not really sure.) Hope this helps. Jeffrey E. Welch Sr. Data Communications Specialist Network Infrastructure Office 616-391-2856 Pager 616-931-6346 Mobile 810-730-3169 -----Original Message----- From: Erblichs [mailto:erblichs@EARTHLINK.NET] Sent: Thursday, May 16, 2002 3:33 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPF performance estimates Interesting,, The black-box link points to a valid link, but the specified paper and talk pdf file generates a error from the Acrobat reader on my Windows '98 system. Unable to extract front WCEGBT+Times-Roman.. Mitchell Erblich ======================== "Manral, Vishwas" wrote: > > Hi Sanjai, > > Though I am not sure there are any absolute answers to your > questions(or none that I know of), which would probably depend on the > router, vendor implementation, topology and other such details. You > may like to have a look at the following drafts which would probably > give some details:- > > http://www.ietf.org/internet-drafts/draft-bmwg-ospfconv-term-00.txt > > http://www.ietf.org/internet-drafts/draft-bmwg-ospfconv-intraarea-00.t > xt > > which are bmwg working group items. > > A paper giving measurements for CISCO GSR and 7513 routers using > blackbox methods is given at: - > > http://www.research.att.com/~albert/black-box-measurement.html > > Thanks and HTH, > Vishwas > > -----Original Message----- > From: Sanjai Narain [mailto:narain@RESEARCH.TELCORDIA.COM] > Sent: Thursday, May 16, 2002 9:01 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: OSPF performance estimates > > I would appreciate pointers to papers on OSPF performance for > realistically sized networks. I am particularly interested in OSPF > performance on a single broadcast subnet: What is the largest number > of hosts connected on a single subnet running OSPF, how fast does OSPF > converge on these and how much bandwidth does it consume? Thanks. -- > Sanjai ------_=_NextPart_001_01C1FD0F.CC431650 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: OSPF performance estimates

Greetings,

 Utilizing Adobe Acrobat 5.0 and running Windows = XP, I was able to open the .PDF document in my IE browser ok. (I'm also = running Internet Explorer 5.5) Just an FYI.

 You may need to upgrade either your Adobe = software or your browser. (Not really sure.)
 Hope this helps.

Jeffrey E. Welch
Sr. Data Communications Specialist
Network Infrastructure
Office 616-391-2856
Pager 616-931-6346
Mobile 810-730-3169

-----Original Message-----
From: Erblichs [mailto:erblichs@EARTHLINK.NET= ]
Sent: Thursday, May 16, 2002 3:33 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: OSPF performance estimates


Interesting,,

        The = black-box link points to a valid link, but the
        specified = paper and talk pdf file generates a
        error = from the Acrobat reader on my Windows '98
        system. = Unable to extract front WCEGBT+Times-Roman..

        Mitchell = Erblich
        = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

"Manral, Vishwas" wrote:
>
> Hi Sanjai,
>
> Though I am not sure there are any absolute = answers to your
> questions(or none that I know of), which would = probably depend on the
> router, vendor implementation, topology and = other such details. You
> may like to have a look at the following drafts = which would probably
> give some details:-
>
> http://www.ietf.org/internet-drafts/draft-bmwg-ospfcon= v-term-00.txt
>
> http://www.ietf.org/internet-drafts/draft-bmwg-ospfcon= v-intraarea-00.t
> xt
>
> which are bmwg working group items.
>
> A paper giving measurements for CISCO GSR and = 7513 routers using
> blackbox methods is given at: -
>
> http://www.research.att.com/~albert/black-box-measurem= ent.html
>
> Thanks and HTH,
> Vishwas
>
> -----Original Message-----
> From: Sanjai Narain [mailto:narain@RESEARCH.TEL= CORDIA.COM]
> Sent: Thursday, May 16, 2002 9:01 AM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: OSPF performance estimates
>
> I would appreciate pointers to papers on OSPF = performance for
> realistically sized networks.  I am = particularly interested in OSPF
> performance on a single broadcast subnet: What = is the largest number
> of hosts connected on a single subnet running = OSPF, how fast does OSPF
> converge on these and how much bandwidth does = it consume? Thanks. --
> Sanjai

------_=_NextPart_001_01C1FD0F.CC431650-- From owner-ospf@DISCUSS.MICROSOFT.COM Thu May 16 17:10:47 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10973 for ; Thu, 16 May 2002 17:10:47 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <9.FF4400C8@PEAR.EASE.LSOFT.COM>; Thu, 16 May 2002 17:09:24 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 874677 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 16 May 2002 17:09:59 -0400 Received: from 216.33.237.210 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 16 May 2002 17:09:59 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 16 May 2002 14:09:58 -0700 Received: from 64.231.229.197 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 16 May 2002 21:09:58 GMT X-Originating-IP: [64.231.229.197] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 16 May 2002 21:09:58.0829 (UTC) FILETIME=[093355D0:01C1FD1E] Message-ID: Date: Fri, 17 May 2002 02:09:58 +0500 Reply-To: Mailing List Sender: Mailing List From: Rehan Khan Subject: AS To: OSPF@DISCUSS.MICROSOFT.COM Hi Just wanted to know what does an AS path of a BGP contains. Can you please point me to the relevant link also. Thanks RK _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From owner-ospf@DISCUSS.MICROSOFT.COM Thu May 16 18:45:11 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12847 for ; Thu, 16 May 2002 18:45:11 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <9.FF4400D3@PEAR.EASE.LSOFT.COM>; Thu, 16 May 2002 18:44:48 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 875016 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 16 May 2002 18:45:24 -0400 Received: from 171.70.157.152 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 16 May 2002 18:35:23 -0400 Received: from mira-sjcd-1.cisco.com (IDENT:mirapoint@mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4GMZFuF014516 for ; Thu, 16 May 2002 15:35:15 -0700 (PDT) Received: from DKANDHAS-W2K.cisco.com ([172.20.44.72]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ACH98399; Thu, 16 May 2002 15:35:52 -0700 (PDT) X-Sender: dkandhas@mira-sjcd-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.2.7.2.20020516153359.01f08b88@mira-sjcd-1.cisco.com> Date: Thu, 16 May 2002 15:35:15 -0700 Reply-To: Mailing List Sender: Mailing List From: Dhanaseker Kandhasamy Subject: Re: AS To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-17.txt Refer sections 4.3 and 5.1.2 Dhans At 02:09 AM 5/17/2002 +0500, you wrote: >Hi > >Just wanted to know what does an AS path of a BGP contains. >Can you please point me to the relevant link also. > >Thanks >RK > >_________________________________________________________________ >Join the world's largest e-mail service with MSN Hotmail. >http://www.hotmail.com From owner-ospf@DISCUSS.MICROSOFT.COM Thu May 16 19:27:47 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13970 for ; Thu, 16 May 2002 19:27:46 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <9.FF4400D7@PEAR.EASE.LSOFT.COM>; Thu, 16 May 2002 19:27:23 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 875223 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 16 May 2002 19:27:58 -0400 Received: from 216.33.237.142 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 16 May 2002 19:27:58 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 16 May 2002 16:27:58 -0700 Received: from 64.231.229.138 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 16 May 2002 23:27:57 GMT X-Originating-IP: [64.231.229.138] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 16 May 2002 23:27:58.0217 (UTC) FILETIME=[5019AF90:01C1FD31] Message-ID: Date: Fri, 17 May 2002 04:27:57 +0500 Reply-To: Mailing List Sender: Mailing List From: Rehan Khan Subject: Re: AS To: OSPF@DISCUSS.MICROSOFT.COM Hi Dhan Thanks very much fo your reply RK >From: Dhanaseker Kandhasamy >Reply-To: Mailing List >To: OSPF@DISCUSS.MICROSOFT.COM >Subject: Re: AS >Date: Thu, 16 May 2002 15:35:15 -0700 > >http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-17.txt > >Refer sections 4.3 and 5.1.2 > >Dhans > >At 02:09 AM 5/17/2002 +0500, you wrote: >>Hi >> >>Just wanted to know what does an AS path of a BGP contains. >>Can you please point me to the relevant link also. >> >>Thanks >>RK >> >>_________________________________________________________________ >>Join the world's largest e-mail service with MSN Hotmail. >>http://www.hotmail.com _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-ospf@DISCUSS.MICROSOFT.COM Mon May 20 11:50:23 2002 Received: from PEAR.EASE.LSOFT.COM (pear.ease.lsoft.com [209.119.1.37]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09040 for ; Mon, 20 May 2002 11:50:23 -0400 (EDT) Received: from walnut (209.119.1.45) by PEAR.EASE.LSOFT.COM (LSMTP for OpenVMS v1.1b) with SMTP id <9.FF440282@PEAR.EASE.LSOFT.COM>; Mon, 20 May 2002 11:50:00 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 887352 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 20 May 2002 11:50:39 -0400 Received: from 64.4.17.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Mon, 20 May 2002 11:50:39 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 20 May 2002 08:50:38 -0700 Received: from 134.177.109.130 by lw11fd.law11.hotmail.msn.com with HTTP; Mon, 20 May 2002 15:50:38 GMT X-Originating-IP: [134.177.109.130] Mime-Version: 1.0 Content-Type: text/html X-OriginalArrivalTime: 20 May 2002 15:50:38.0415 (UTC) FILETIME=[165B2DF0:01C20016] Message-ID: Date: Mon, 20 May 2002 15:50:38 +0000 Reply-To: Mailing List Sender: Mailing List From: padma sanampudi Subject: unsubscribe To: OSPF@DISCUSS.MICROSOFT.COM

unsubscribe


Chat with friends online, try MSN Messenger: Click Here
From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 21 02:46:27 2002 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 CAA22159 for ; Tue, 21 May 2002 02:46:27 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00613FCF@cherry.ease.lsoft.com>; Tue, 21 May 2002 2:46:41 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 876214 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 21 May 2002 02:46:41 -0400 Received: from 202.106.106.102 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Tue, 21 May 2002 02:46:41 -0400 Received: from zhuxm ([202.106.106.126]) by newexchange.domain.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 21 May 2002 14:34:36 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C200D6.22A51240" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 21 May 2002 06:34:36.0518 (UTC) FILETIME=[93877060:01C20091] Message-ID: <001001c20093$15a124f0$96ce12ac@MCSD.local> Date: Tue, 21 May 2002 14:45:22 +0800 Reply-To: Mailing List Sender: Mailing List From: Ximin Zhu Subject: unsubscribe To: OSPF@DISCUSS.MICROSOFT.COM This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C200D6.22A51240 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 dW5zdWJzY3JpYmUNCg0K ------=_NextPart_000_000D_01C200D6.22A51240 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yNjAwLjAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9E WSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxGT05UIA0K c2l6ZT0zPnVuc3Vic2NyaWJlPC9GT05UPjxCUj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4N Cg== ------=_NextPart_000_000D_01C200D6.22A51240-- From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 21 11:09:38 2002 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 LAA13877 for ; Tue, 21 May 2002 11:09:38 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00614F3B@cherry.ease.lsoft.com>; Tue, 21 May 2002 11:09:55 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 877981 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 21 May 2002 11:09:55 -0400 Received: from 207.217.120.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Tue, 21 May 2002 11:09:54 -0400 Received: from 209-239-195-16.oak.jps.net ([209.239.195.16] helo=earthlink.net) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17ABGq-0001kf-00 for ospf@discuss.microsoft.com; Tue, 21 May 2002 08:09:52 -0700 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: <3CDDA283.9661130D@earthlink.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3CEA6554.5631C7CE@earthlink.net> Date: Tue, 21 May 2002 08:18:44 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Hitless Restart 02 : 2-way, BDR, grace policy To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Group, I got a couple of private replies and wanted to clarify a few items. IF the system memory could be checkpointed/saved AND later resumed upon restart, then the main issues become, * what is the minimum of the OSPF interfaces DeadInterval? This is the value that the system must be re-booted so none its neighbors don't declare it as dead and free its associated resources. * can you save the memory in a format that upon resumption you could restore it in newer data structures? i.e. a new release. * how do you save the hw/sw registers, that upon bootup, the system behaves properly? Etc.. Then grace-lsa's would not be necessary, no knowledge of the neigbors that you are about to perform this procedure would be necessary, and it would be backward compatible with neighboring routers. This work was done at Terayon a couple of years ago and I called it "Fast Re-start". This general feature was also done at Sun Microsystems and they call it checkpoint/resume. Mitchell Erblich ====================== PS: #8 from below would partially be satisfied if MaxAge flushing was explicitly specified for grace-LSAs.. Erblichs wrote: > > Hitless Restart -02 by J. Moy : Feb02 to Aug02 > > Pre-note: I have NOT previously done this level of > restart with a grace-LSA and am not currently working > on this type of functionality.. > > My assumptions are that I understand this draft and > their are a few things that may be a bit clearer... > Sorry ahead of time... > > 1) Overview 1.: > Should their be an explicit statement that 2-way > DRothers link partners, not not play a role in > hitless restart? > > 2) Overview 1.: > If you are a DRother, what does this really gain > you? > > 3) Is restart time started when the first grace-LSA > is sent out OR when the last grace-LSA is acknowledged? > > 4) 2) Op of restart router (3) If the restarting ... > Couldn't you use nvram to store that you were the > DR? You then wouldn't have to wait 1/2 on average > of the hello interval.. Complication, what happens > with demand circuits and suppressed hellos? > > 5) Same section as #4. > How do you preserve the fact that you were the BDR > in this Draft? I actually don't really see any mention > of the BDR... > -- My suggestion in #4 would work as well for a > BDR or a DRother.. > > #4 and #5) For consistency sake, these items should then > be checked with hellos, etc.. > > 6) 2.1) (2) What happens if the nvram cypto seq # somehow > is no-longer correct after the restart? I assume this > can be changed. > > 7) 2.1) A grace-LSA is originated .. > Am I correct in assuming that the below question would be > implicitly covered as a topolgy change and proceed to normal > restart? > > What happens if a BDR comes up during restart (before all > grace-LSA are acknowledged? > > 8) 2.1) A grace-LSA is originated .. > A) Conflict with 3.1 (4)b. How do you resolve a grace-LSAs that > were xmit'ed and acked by one or more neighbors and one > or more grace-LSAs that are in conflict with exceeding the > local policy of time T. > B) How do you detect that you are violating time T? > C) Can you resend a grace-LSA with a different grace-period? > What should a router do, if two grace-LSAs were sent > with the same grace-periods? With different grace periods? > D) What happens if you violate your grace-LSA value? > E) What happens if the grace-period is exceeding long and > router X was the DR? > F) When do you stop re-xmiting grace-LSAs and proceed to > normal restart? Can you spend you entire grace-period > doing re-xmits? > > 9) 2.2 (2) add a d) router that would be a helper candidate > came up after restart was started and all grace-LSAs were > acknowledged. > > 10) Why not save xmit OSPF hellos per interface in nvram, > so after a restart prior restart hellos can be reloaded > and sent? > > 11) #4) "or they do not recieved the grace-LSA" > I don't understand this phrase.. > Are you talking about not reciving a ack from a router > Y candidate? > > Thanks, > Mitchell Erblich From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 21 13:50:24 2002 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 NAA21967 for ; Tue, 21 May 2002 13:50:24 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00615456@cherry.ease.lsoft.com>; Tue, 21 May 2002 13:50:40 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 878816 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 21 May 2002 13:50:40 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Tue, 21 May 2002 13:50:39 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 3985B18D3FC for ; Tue, 21 May 2002 10:50:38 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3CDDA283.9661130D@earthlink.net> <3CEA6554.5631C7CE@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3CEA88B6.90701@redback.com> Date: Tue, 21 May 2002 13:49:42 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Hitless Restart 02 : 2-way, BDR, grace policy To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Erblichs wrote: > Group, > > I got a couple of private replies and wanted > to clarify a few items. > > IF the system memory could be checkpointed/saved > AND later resumed upon restart, > > then the main issues become, > > * what is the minimum of the OSPF interfaces > DeadInterval? This is the value that the system must > be re-booted so none its neighbors don't declare it as > dead and free its associated resources. Mitchell, I guess if you go by RFC 2338, the answer is 2 (at least with our implementation I assure that the dead interval is greater than the hello interval). Presumably you could extend the dead interval to match the grace interval for planned restarts. For unplanned restarts, you don't have the luxury of sending the grace LSAs before you go down so the point it moot. > > * can you save the memory in a format that > upon resumption you could restore it in newer > data structures? i.e. a new release. > > * how do you save the hw/sw registers, that upon > bootup, the system behaves properly? > > Etc.. > > Then grace-lsa's would not be necessary, no knowledge > of the neigbors that you are about to perform this > procedure would be necessary, and it would be > backward compatible with neighboring routers. > > This work was done at Terayon a couple of years > ago and I called it "Fast Re-start". This general > feature was also done at Sun Microsystems and they > call it checkpoint/resume. This is definitely a potential solution. However, if you checkpointed your Link State database, neighbor state, and some flooding state (to assure it is reliable) you wouldn't need any cooperation with other routers or modifications to the base OSPF protocol. The advantage of learning this state from the other routers in the network is that it is much lower overhead. > > Mitchell Erblich > ====================== > PS: #8 from below would partially be satisfied if > MaxAge flushing was explicitly specified for grace-LSAs.. > > Erblichs wrote: > >>Hitless Restart -02 by J. Moy : Feb02 to Aug02 >> >> Pre-note: I have NOT previously done this level of >> restart with a grace-LSA and am not currently working >> on this type of functionality.. >> >> My assumptions are that I understand this draft and >> their are a few things that may be a bit clearer... >> Sorry ahead of time... >> >> 1) Overview 1.: >> Should their be an explicit statement that 2-way >> DRothers link partners, not not play a role in >> hitless restart? >> >> 2) Overview 1.: >> If you are a DRother, what does this really gain >> you? >> >> 3) Is restart time started when the first grace-LSA >> is sent out OR when the last grace-LSA is acknowledged? >> >> 4) 2) Op of restart router (3) If the restarting ... >> Couldn't you use nvram to store that you were the >> DR? You then wouldn't have to wait 1/2 on average >> of the hello interval.. Complication, what happens >> with demand circuits and suppressed hellos? >> >> 5) Same section as #4. >> How do you preserve the fact that you were the BDR >> in this Draft? I actually don't really see any mention >> of the BDR... >> -- My suggestion in #4 would work as well for a >> BDR or a DRother.. >> >> #4 and #5) For consistency sake, these items should then >> be checked with hellos, etc.. >> >> 6) 2.1) (2) What happens if the nvram cypto seq # somehow >> is no-longer correct after the restart? I assume this >> can be changed. >> >> 7) 2.1) A grace-LSA is originated .. >> Am I correct in assuming that the below question would be >> implicitly covered as a topolgy change and proceed to normal >> restart? >> >> What happens if a BDR comes up during restart (before all >> grace-LSA are acknowledged? >> >> 8) 2.1) A grace-LSA is originated .. >> A) Conflict with 3.1 (4)b. How do you resolve a grace-LSAs that >> were xmit'ed and acked by one or more neighbors and one >> or more grace-LSAs that are in conflict with exceeding the >> local policy of time T. >> B) How do you detect that you are violating time T? >> C) Can you resend a grace-LSA with a different grace-period? >> What should a router do, if two grace-LSAs were sent >> with the same grace-periods? With different grace periods? >> D) What happens if you violate your grace-LSA value? >> E) What happens if the grace-period is exceeding long and >> router X was the DR? >> F) When do you stop re-xmiting grace-LSAs and proceed to >> normal restart? Can you spend you entire grace-period >> doing re-xmits? >> >> 9) 2.2 (2) add a d) router that would be a helper candidate >> came up after restart was started and all grace-LSAs were >> acknowledged. >> >> 10) Why not save xmit OSPF hellos per interface in nvram, >> so after a restart prior restart hellos can be reloaded >> and sent? >> >> 11) #4) "or they do not recieved the grace-LSA" >> I don't understand this phrase.. >> Are you talking about not reciving a ack from a router >> Y candidate? >> >> Thanks, >> Mitchell Erblich > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 22 00:51:04 2002 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 AAA16956 for ; Wed, 22 May 2002 00:51:04 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.006168BD@cherry.ease.lsoft.com>; Wed, 22 May 2002 0:51:22 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 880975 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 22 May 2002 00:51:22 -0400 Received: from 66.163.169.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 22 May 2002 00:41:22 -0400 Received: from [203.200.20.226] by web21508.mail.yahoo.com via HTTP; Tue, 21 May 2002 21:41:21 PDT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1230628789-1022042481=:33787" Message-ID: <20020522044121.33895.qmail@web21508.mail.yahoo.com> Date: Tue, 21 May 2002 21:41:21 -0700 Reply-To: Mailing List Sender: Mailing List From: Amit Srivastava Subject: Opaque LSA To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3CEA6554.5631C7CE@earthlink.net> --0-1230628789-1022042481=:33787 Content-Type: text/plain; charset=us-ascii Hi All, I would like to know the Applications which use Opaque LSA and if there is any good material on net about the Opaque LSA regards Amit --------------------------------- Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience --0-1230628789-1022042481=:33787 Content-Type: text/html; charset=us-ascii

 Hi All,

          I would like to know the Applications which use Opaque LSA and if there is any good material on net about the

          Opaque LSA

regards

Amit


Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience --0-1230628789-1022042481=:33787-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 22 01:04:35 2002 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 BAA17373 for ; Wed, 22 May 2002 01:04:35 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00616A0A@cherry.ease.lsoft.com>; Wed, 22 May 2002 1:04:27 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 881062 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 22 May 2002 01:04:27 -0400 Received: from 203.254.224.24 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 22 May 2002 00:54:26 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0GWH00901XLQWA@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Wed, 22 May 2002 13:53:50 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GWH0094KXLPSZ@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Wed, 22 May 2002 13:53:50 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0GWH00A3KXLG5C@mmp2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Wed, 22 May 2002 13:53:41 +0900 (KST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20020522044121.33895.qmail@web21508.mail.yahoo.com> Message-ID: <01ff01c2014c$7290cdf0$b4036c6b@sisodomain.com> Date: Wed, 22 May 2002 10:22:15 +0530 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: Re: Opaque LSA To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7BIT Amit, Apart from extensive applicability in TE, opaque LSAs are used in other places... Router Capability Exchange: draft-galand-an-routing-00.txt IPv6 in IPv4 AS deployments draft-many-ngtrans-connect-ipv6-igp-00.txt BGP MPLS VPNs/TE draft-jamieson-mpls-vpn-00.txt draft-abarbanel-idr-bgp4-te-01.txt If you are just looking for an e.g. for an application of opaque LSA's you can have a look at the ospf-hitless-restart by John which use opaque LSA's to inform other ospf routers of the intention to do a hitless-restart (use by OSPF). Regards, Manav ----- Original Message ----- From: "Amit Srivastava" To: Sent: Wednesday, May 22, 2002 10:11 AM Subject: Opaque LSA | | Hi All, | I would like to know the Applications which use Opaque LSA and if there is any good material on net about the | Opaque LSA | regards | Amit | | | | --------------------------------- | Do You Yahoo!? | LAUNCH - Your Yahoo! Music Experience From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 22 01:54:48 2002 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 BAA19205 for ; Wed, 22 May 2002 01:54:48 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00616ABC@cherry.ease.lsoft.com>; Wed, 22 May 2002 1:55:05 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 881230 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 22 May 2002 01:55:05 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 22 May 2002 01:55:04 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 237B71DCC6E for ; Tue, 21 May 2002 22:55:03 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20020522044121.33895.qmail@web21508.mail.yahoo.com> <01ff01c2014c$7290cdf0$b4036c6b@sisodomain.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3CEB3279.5010708@redback.com> Date: Wed, 22 May 2002 01:54:01 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Opaque LSA To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Manav Bhatia wrote: > Amit, > Apart from extensive applicability in TE, opaque LSAs are used in other > places... > > Router Capability Exchange: > draft-galand-an-routing-00.txt Manav, I haven't seen this one - can you send me a pointer? > > IPv6 in IPv4 AS deployments > draft-many-ngtrans-connect-ipv6-igp-00.txt > > BGP MPLS VPNs/TE > draft-jamieson-mpls-vpn-00.txt > draft-abarbanel-idr-bgp4-te-01.txt > > If you are just looking for an e.g. for an application of opaque LSA's you > can have a look at > the ospf-hitless-restart by John which use opaque LSA's to inform other > ospf routers of the > intention to do a hitless-restart (use by OSPF). Amit, Note that John's GPL OSPF implementation is available at http://www.ospf.org/ > > Regards, > Manav > > ----- Original Message ----- > From: "Amit Srivastava" > To: > Sent: Wednesday, May 22, 2002 10:11 AM > Subject: Opaque LSA > > > | > | Hi All, > | I would like to know the Applications which use Opaque LSA and > if there is any good material on net about the > | Opaque LSA > | regards > | Amit > | > | > | > | --------------------------------- > | Do You Yahoo!? > | LAUNCH - Your Yahoo! Music Experience > Thanks, -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 22 02:08:20 2002 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 CAA28190 for ; Wed, 22 May 2002 02:08:20 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00616C54@cherry.ease.lsoft.com>; Wed, 22 May 2002 2:08:36 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 881276 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 22 May 2002 02:08:37 -0400 Received: from 203.254.224.24 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 22 May 2002 02:08:36 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0GWI00F0111C5A@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Wed, 22 May 2002 15:08:00 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GWI00F3R11C1J@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Wed, 22 May 2002 15:08:00 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0GWI00BDJ112H9@mmp2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Wed, 22 May 2002 15:07:52 +0900 (KST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20020522044121.33895.qmail@web21508.mail.yahoo.com> <01ff01c2014c$7290cdf0$b4036c6b@sisodomain.com> <3CEB3279.5010708@redback.com> Message-ID: <001601c20156$cf008c10$b4036c6b@sisodomain.com> Date: Wed, 22 May 2002 11:36:24 +0530 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: Re: Opaque LSA Comments: cc: acee@redback.com To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7BIT Acee, draft-galand-an-routing-00.txt documents a way to include information on active routers capabilities in the routing protocols. The active routers receive code to be executed with the payload of the IP packets ("active packets") as input. This draft uses Opaque LSAs for distribution since the information contained in Opaque LSAs may be used directly by OSPF or indirectly by some application wishing to distribute information throughout the OSPF domain. Pl. visit http://alternic.net/drafts/drafts-g-h/draft-galand-an-routing-00.html for more details. Regards, Manav ----- Original Message ----- From: "Acee Lindem" To: Sent: Wednesday, May 22, 2002 11:24 AM Subject: Re: Opaque LSA | Manav Bhatia wrote: | > Amit, | > Apart from extensive applicability in TE, opaque LSAs are used in other | > places... | > | > Router Capability Exchange: | > draft-galand-an-routing-00.txt | | Manav, | | I haven't seen this one - can you send me a pointer? | | > | > IPv6 in IPv4 AS deployments | > draft-many-ngtrans-connect-ipv6-igp-00.txt | > | > BGP MPLS VPNs/TE | > draft-jamieson-mpls-vpn-00.txt | > draft-abarbanel-idr-bgp4-te-01.txt | > | > If you are just looking for an e.g. for an application of opaque LSA's you | > can have a look at | > the ospf-hitless-restart by John which use opaque LSA's to inform other | > ospf routers of the | > intention to do a hitless-restart (use by OSPF). | | Amit, | | Note that John's GPL OSPF implementation is available at http://www.ospf.org/ | | > | > Regards, | > Manav | > | > ----- Original Message ----- | > From: "Amit Srivastava" | > To: | > Sent: Wednesday, May 22, 2002 10:11 AM | > Subject: Opaque LSA | > | > | > | | > | Hi All, | > | I would like to know the Applications which use Opaque LSA and | > if there is any good material on net about the | > | Opaque LSA | > | regards | > | Amit | > | | > | | > | | > | --------------------------------- | > | Do You Yahoo!? | > | LAUNCH - Your Yahoo! Music Experience | > | | Thanks, | -- | Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 22 12:08:08 2002 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 MAA15229 for ; Wed, 22 May 2002 12:08:08 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.006174DE@cherry.ease.lsoft.com>; Wed, 22 May 2002 12:08:24 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 884043 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 22 May 2002 12:08:24 -0400 Received: from 207.217.120.84 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 22 May 2002 12:08:24 -0400 Received: from 209-239-201-150.oak.jps.net ([209.239.201.150] helo=earthlink.net) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 17AYez-0007gy-00 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 22 May 2002 09:08:21 -0700 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: <3CDDA283.9661130D@earthlink.net> <3CEA6554.5631C7CE@earthlink.net> <3CEA88B6.90701@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3CEBC48B.21E581F6@earthlink.net> Date: Wed, 22 May 2002 09:17:15 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Hitless Restart 02 : 2-way, BDR, grace policy To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit > routers or modifications to the base OSPF protocol. The advantage of > learning this state from the other routers in the network is that it > is much lower overhead. I am not sure how you are catagorizing "overhead". * Assuming like quantities of information, accessing data from physical memory is always faster than acessing it from a link partner. Their should be a minimalistic amount of work to verify correctness when restoring data from memory. * Their is no unbounded acknowledgement time quantum required, like their is for reliable grace-LSAs (2.1 : "should retransmit the grace-LSAs until they are acknowledged"). In my assumption, this could lead to a flushing of grace-LSAs and then the resending of the grace-LSA with a different grace-period because one possible "helper" had a late response. Worst case scenario.. * Grace-LSAs are opaque and opaque LSAs are "optional", not part of the v2 OSPF spec. * Their could be a signficant amount of work/overhead to flood these grace-LSAs.. And then maybe reflood due to flushing or just with a newer sequence.. * Just because grace-LSAs are ack'ed, their is no requirement that they are guaranteed to be helpers (2.1 : " mere reception of grace-LSAs does not imply acceptance of helper responsibilities") Thus, I do not know why this draft does not have some form of "grace-LSA" that DOES imply acceptance by setting some form of acceptance flag/bit. > for planned restarts. For unplanned restarts, you don't have the luxury With a variation of CPR, it is possible to have various checkpoints of the system (say once every 1 minute) for unplanned fast-restarts. So Checkpoint/Resume (CPR) tends to be a bit complicated, but allows the router to have a shorter down-time in any circumstance. Mitchell Erblich ---------------------- Acee Lindem wrote: > > Erblichs wrote: > > Group, > > > > I got a couple of private replies and wanted > > to clarify a few items. > > > > IF the system memory could be checkpointed/saved > > AND later resumed upon restart, > > > > then the main issues become, > > > > * what is the minimum of the OSPF interfaces > > DeadInterval? This is the value that the system must > > be re-booted so none its neighbors don't declare it as > > dead and free its associated resources. > > Mitchell, > > I guess if you go by RFC 2338, the answer is 2 (at least with our implementation > I assure that the dead interval is greater than the hello interval). > Presumably you could extend the dead interval to match the grace interval > for planned restarts. For unplanned restarts, you don't have the luxury of sending > the grace LSAs before you go down so the point it moot. > > > > > * can you save the memory in a format that > > upon resumption you could restore it in newer > > data structures? i.e. a new release. > > > > * how do you save the hw/sw registers, that upon > > bootup, the system behaves properly? > > > > Etc.. > > > > Then grace-lsa's would not be necessary, no knowledge > > of the neigbors that you are about to perform this > > procedure would be necessary, and it would be > > backward compatible with neighboring routers. > > > > This work was done at Terayon a couple of years > > ago and I called it "Fast Re-start". This general > > feature was also done at Sun Microsystems and they > > call it checkpoint/resume. > > This is definitely a potential solution. However, if you checkpointed > your Link State database, neighbor state, and some flooding state (to > assure it is reliable) you wouldn't need any cooperation with other > routers or modifications to the base OSPF protocol. The advantage of > learning this state from the other routers in the network is that it > is much lower overhead. > > > > > Mitchell Erblich > > ====================== > > PS: #8 from below would partially be satisfied if > > MaxAge flushing was explicitly specified for grace-LSAs.. > > > > Erblichs wrote: > > > >>Hitless Restart -02 by J. Moy : Feb02 to Aug02 > >> > >> Pre-note: I have NOT previously done this level of > >> restart with a grace-LSA and am not currently working > >> on this type of functionality.. > >> > >> My assumptions are that I understand this draft and > >> their are a few things that may be a bit clearer... > >> Sorry ahead of time... > >> > >> 1) Overview 1.: > >> Should their be an explicit statement that 2-way > >> DRothers link partners, not not play a role in > >> hitless restart? > >> > >> 2) Overview 1.: > >> If you are a DRother, what does this really gain > >> you? > >> > >> 3) Is restart time started when the first grace-LSA > >> is sent out OR when the last grace-LSA is acknowledged? > >> > >> 4) 2) Op of restart router (3) If the restarting ... > >> Couldn't you use nvram to store that you were the > >> DR? You then wouldn't have to wait 1/2 on average > >> of the hello interval.. Complication, what happens > >> with demand circuits and suppressed hellos? > >> > >> 5) Same section as #4. > >> How do you preserve the fact that you were the BDR > >> in this Draft? I actually don't really see any mention > >> of the BDR... > >> -- My suggestion in #4 would work as well for a > >> BDR or a DRother.. > >> > >> #4 and #5) For consistency sake, these items should then > >> be checked with hellos, etc.. > >> > >> 6) 2.1) (2) What happens if the nvram cypto seq # somehow > >> is no-longer correct after the restart? I assume this > >> can be changed. > >> > >> 7) 2.1) A grace-LSA is originated .. > >> Am I correct in assuming that the below question would be > >> implicitly covered as a topolgy change and proceed to normal > >> restart? > >> > >> What happens if a BDR comes up during restart (before all > >> grace-LSA are acknowledged? > >> > >> 8) 2.1) A grace-LSA is originated .. > >> A) Conflict with 3.1 (4)b. How do you resolve a grace-LSAs that > >> were xmit'ed and acked by one or more neighbors and one > >> or more grace-LSAs that are in conflict with exceeding the > >> local policy of time T. > >> B) How do you detect that you are violating time T? > >> C) Can you resend a grace-LSA with a different grace-period? > >> What should a router do, if two grace-LSAs were sent > >> with the same grace-periods? With different grace periods? > >> D) What happens if you violate your grace-LSA value? > >> E) What happens if the grace-period is exceeding long and > >> router X was the DR? > >> F) When do you stop re-xmiting grace-LSAs and proceed to > >> normal restart? Can you spend you entire grace-period > >> doing re-xmits? > >> > >> 9) 2.2 (2) add a d) router that would be a helper candidate > >> came up after restart was started and all grace-LSAs were > >> acknowledged. > >> > >> 10) Why not save xmit OSPF hellos per interface in nvram, > >> so after a restart prior restart hellos can be reloaded > >> and sent? > >> > >> 11) #4) "or they do not recieved the grace-LSA" > >> I don't understand this phrase.. > >> Are you talking about not reciving a ack from a router > >> Y candidate? > >> > >> Thanks, > >> Mitchell Erblich > > > > > > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 22 12:29:52 2002 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 MAA16741 for ; Wed, 22 May 2002 12:29:52 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00617557@cherry.ease.lsoft.com>; Wed, 22 May 2002 12:30:10 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 884126 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 22 May 2002 12:30:10 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 22 May 2002 12:30:10 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id CD6A4262807 for ; Wed, 22 May 2002 09:30:08 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3CDDA283.9661130D@earthlink.net> <3CEA6554.5631C7CE@earthlink.net> <3CEA88B6.90701@redback.com> <3CEBC48B.21E581F6@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3CEBC74D.2050407@redback.com> Date: Wed, 22 May 2002 12:29:01 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Hitless Restart 02 : 2-way, BDR, grace policy To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Erblichs wrote: >>routers or modifications to the base OSPF protocol. The advantage of >>learning this state from the other routers in the network is that it >>is much lower overhead. > > > I am not sure how you are catagorizing "overhead". > > * Assuming like quantities of information, accessing data from physical > memory is always faster than acessing it from a link partner. Their > should be a minimalistic amount of work to verify correctness when > restoring data from memory. Agreed. I was talking about the steady state overhead of checkpointing your link state database, neighbor state, and flooding state to non-volatile memory or a standby processor. Depending on your SW/HW architecture this may be a perfectly valid option. My point is that this type of scheme could be completely transparent and not require any IETF involvement. > > * Their is no unbounded acknowledgement time quantum required, like > their is for reliable grace-LSAs (2.1 : "should retransmit the > grace-LSAs until they are acknowledged"). In my assumption, this > could lead to a flushing of grace-LSAs and then the resending of > the grace-LSA with a different grace-period because one possible > "helper" had a late response. Worst case scenario.. Maybe I'm misunderstanding you. Anyway, once an LSA is on a neighbor retransmission queue I don't re-originate it each time it is retransmitted. You are right that different routers will have different grace termination times if one does not receive the initial grace LSA. However, we don't live in a perfect world. > > * Grace-LSAs are opaque and opaque LSAs are "optional", not part > of the v2 OSPF spec. This is a problem. There are also major vendors that claim to support opaque LSAs but do *not* support the type 9 (link-local LSAs). My opinion is that they should have spoken up back when RFC 2370 was being debated. > > * Their could be a signficant amount of work/overhead to flood > these grace-LSAs.. And then maybe reflood due to flushing or > just with a newer sequence.. > > * Just because grace-LSAs are ack'ed, their is no requirement > that they are guaranteed to be helpers (2.1 : " mere reception > of grace-LSAs does not imply acceptance of helper responsibilities") > > Thus, I do not know why this draft does not have some form of > "grace-LSA" that DOES imply acceptance by setting some form > of acceptance flag/bit. If a router receives an LSA that "match" its pre-restart router LSA it will detect that a router doesn't support graceful restart and terminate graceful restart. This will happen quite quickly if your SPF timers are set low and its been implemented correctly. > > >>for planned restarts. For unplanned restarts, you don't have the luxury > > With a variation of CPR, it is possible to have various checkpoints > of the system (say once every 1 minute) for unplanned fast-restarts. > > So Checkpoint/Resume (CPR) tends to be a bit complicated, > but allows the router to have a shorter down-time in any circumstance. Agreed. > > > Mitchell Erblich > ---------------------- > > > > > Acee Lindem wrote: > >>Erblichs wrote: >> >>>Group, >>> >>> I got a couple of private replies and wanted >>> to clarify a few items. >>> >>> IF the system memory could be checkpointed/saved >>> AND later resumed upon restart, >>> >>> then the main issues become, >>> >>> * what is the minimum of the OSPF interfaces >>> DeadInterval? This is the value that the system must >>> be re-booted so none its neighbors don't declare it as >>> dead and free its associated resources. >> >>Mitchell, >> >>I guess if you go by RFC 2338, the answer is 2 (at least with our implementation >>I assure that the dead interval is greater than the hello interval). >>Presumably you could extend the dead interval to match the grace interval >>for planned restarts. For unplanned restarts, you don't have the luxury of sending >>the grace LSAs before you go down so the point it moot. >> >> >>> * can you save the memory in a format that >>> upon resumption you could restore it in newer >>> data structures? i.e. a new release. >>> >>> * how do you save the hw/sw registers, that upon >>> bootup, the system behaves properly? >>> >>> Etc.. >>> >>> Then grace-lsa's would not be necessary, no knowledge >>> of the neigbors that you are about to perform this >>> procedure would be necessary, and it would be >>> backward compatible with neighboring routers. >>> >>> This work was done at Terayon a couple of years >>> ago and I called it "Fast Re-start". This general >>> feature was also done at Sun Microsystems and they >>> call it checkpoint/resume. >> >>This is definitely a potential solution. However, if you checkpointed >>your Link State database, neighbor state, and some flooding state (to >>assure it is reliable) you wouldn't need any cooperation with other >>routers or modifications to the base OSPF protocol. The advantage of >>learning this state from the other routers in the network is that it >>is much lower overhead. >> >> >>> Mitchell Erblich >>> ====================== >>> PS: #8 from below would partially be satisfied if >>> MaxAge flushing was explicitly specified for grace-LSAs.. >>> >>>Erblichs wrote: >>> >>> >>>>Hitless Restart -02 by J. Moy : Feb02 to Aug02 >>>> >>>> Pre-note: I have NOT previously done this level of >>>> restart with a grace-LSA and am not currently working >>>> on this type of functionality.. >>>> >>>> My assumptions are that I understand this draft and >>>> their are a few things that may be a bit clearer... >>>> Sorry ahead of time... >>>> >>>> 1) Overview 1.: >>>> Should their be an explicit statement that 2-way >>>> DRothers link partners, not not play a role in >>>> hitless restart? >>>> >>>> 2) Overview 1.: >>>> If you are a DRother, what does this really gain >>>> you? >>>> >>>> 3) Is restart time started when the first grace-LSA >>>> is sent out OR when the last grace-LSA is acknowledged? >>>> >>>> 4) 2) Op of restart router (3) If the restarting ... >>>> Couldn't you use nvram to store that you were the >>>> DR? You then wouldn't have to wait 1/2 on average >>>> of the hello interval.. Complication, what happens >>>> with demand circuits and suppressed hellos? >>>> >>>> 5) Same section as #4. >>>> How do you preserve the fact that you were the BDR >>>> in this Draft? I actually don't really see any mention >>>> of the BDR... >>>> -- My suggestion in #4 would work as well for a >>>> BDR or a DRother.. >>>> >>>> #4 and #5) For consistency sake, these items should then >>>> be checked with hellos, etc.. >>>> >>>> 6) 2.1) (2) What happens if the nvram cypto seq # somehow >>>> is no-longer correct after the restart? I assume this >>>> can be changed. >>>> >>>> 7) 2.1) A grace-LSA is originated .. >>>> Am I correct in assuming that the below question would be >>>> implicitly covered as a topolgy change and proceed to normal >>>> restart? >>>> >>>> What happens if a BDR comes up during restart (before all >>>> grace-LSA are acknowledged? >>>> >>>> 8) 2.1) A grace-LSA is originated .. >>>> A) Conflict with 3.1 (4)b. How do you resolve a grace-LSAs that >>>> were xmit'ed and acked by one or more neighbors and one >>>> or more grace-LSAs that are in conflict with exceeding the >>>> local policy of time T. >>>> B) How do you detect that you are violating time T? >>>> C) Can you resend a grace-LSA with a different grace-period? >>>> What should a router do, if two grace-LSAs were sent >>>> with the same grace-periods? With different grace periods? >>>> D) What happens if you violate your grace-LSA value? >>>> E) What happens if the grace-period is exceeding long and >>>> router X was the DR? >>>> F) When do you stop re-xmiting grace-LSAs and proceed to >>>> normal restart? Can you spend you entire grace-period >>>> doing re-xmits? >>>> >>>> 9) 2.2 (2) add a d) router that would be a helper candidate >>>> came up after restart was started and all grace-LSAs were >>>> acknowledged. >>>> >>>> 10) Why not save xmit OSPF hellos per interface in nvram, >>>> so after a restart prior restart hellos can be reloaded >>>> and sent? >>>> >>>> 11) #4) "or they do not recieved the grace-LSA" >>>> I don't understand this phrase.. >>>> Are you talking about not reciving a ack from a router >>>> Y candidate? >>>> >>>> Thanks, >>>> Mitchell Erblich >>> >>> >>-- >>Acee > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 22 21:30:25 2002 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 VAA12469 for ; Wed, 22 May 2002 21:30:25 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00618470@cherry.ease.lsoft.com>; Wed, 22 May 2002 21:30:42 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 886013 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 22 May 2002 21:30:42 -0400 Received: from 64.4.37.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 22 May 2002 21:30:42 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 22 May 2002 18:30:41 -0700 Received: from 155.245.254.253 by pv2fd.pav2.hotmail.msn.com with HTTP; Thu, 23 May 2002 01:30:39 GMT X-Originating-IP: [155.245.254.253] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 23 May 2002 01:30:41.0433 (UTC) FILETIME=[7365C890:01C201F9] Message-ID: Date: Thu, 23 May 2002 01:30:39 +0000 Reply-To: Mailing List Sender: Mailing List From: wu min Subject: DR & BDR Election To: OSPF@DISCUSS.MICROSOFT.COM Hi, I am pretty new to OSPF and I have a couple of questions. I would appreciate some help. 1. Can a router declares itself as DR and BDR simultaneously (just in case that it may not be choosen to be a DR, it have some chance to take up BDR post)? 2. Should *other* routers keep declaring themselves (eligible to be) DR or BDR in HelloPackets eventhough both DR and BDR were already choosen? 3. In section 9.4, page 76 of RFC2328, step (4), why does the newly selected DR or BDR (or resigning DR or BDR), is required to run step (2) and (3) again? Take for instance, if it knew that it was being elected as the new designated DR or BDR in the first run of step (2) and (3), repeating step (2) and step (3) again will never change its view. Am I missing something here? 4. Is it true that if a router that was previously a BDR (and also has been declaring itself as BDR only in its HelloPacket), but now being elected as new DR to replace the old one, must declare itself as DS in its subsequence HelloPackets? Thanks in advance. -Tze Ven _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 22 21:56:43 2002 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 VAA13381 for ; Wed, 22 May 2002 21:56:42 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0061852C@cherry.ease.lsoft.com>; Wed, 22 May 2002 21:57:00 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 886053 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 22 May 2002 21:57:00 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 22 May 2002 21:57:00 -0400 Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with esmtp (Exim 3.36 #1) id 17Ahqc-0004KU-00; Wed, 22 May 2002 18:56:58 -0700 X-Mailer: The Bat! (v1.51) Personal X-Priority: 3 (Normal) References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <541178495.20020522185534@psg.com> Date: Wed, 22 May 2002 18:55:34 -0700 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: DR & BDR Election Comments: To: wu min To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Content-Transfer-Encoding: 7bit Tze Ven: A short answer to your questions would be---please follow the spec. However, I put explanations inline below. Wednesday, May 22, 2002, 6:30:39 PM, you wrote: > Hi, > I am pretty new to OSPF and I have a couple of questions. I would appreciate > some help. > 1. Can a router declares itself as DR and BDR simultaneously (just in case > that it may not be choosen to be a DR, it have some chance to take up BDR > post)? No, it cannot. The router puts in the hello packets the DR and BDR it has locally calculated by performing the algo in section 9.4, which ensures that a router never selects itself as both the DR and the BDR. > 2. Should *other* routers keep declaring themselves (eligible to be) DR or > BDR in HelloPackets eventhough both DR and BDR were already choosen? No, they should not. When a router elects the DR and the BDR, it should start announcing _these_ values in its Hello packets. > 3. In section 9.4, page 76 of RFC2328, step (4), why does the newly selected > DR or BDR (or resigning DR or BDR), is required to run step (2) and (3) > again? Take for instance, if it knew that it was being elected as the new > designated DR or BDR in the first run of step (2) and (3), repeating step > (2) and step (3) again will never change its view. Am I missing something > here? Please see the following URL for an answer: http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0105&L=OSPF&P=R7503 > 4. Is it true that if a router that was previously a BDR (and also has been > declaring itself as BDR only in its HelloPacket), but now being elected as > new DR to replace the old one, must declare itself as DS in its subsequence > HelloPackets? Please see my answers to your first two questions. Alex From owner-ospf@DISCUSS.MICROSOFT.COM Thu May 23 09:59:15 2002 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 JAA10601 for ; Thu, 23 May 2002 09:59:09 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00619A08@cherry.ease.lsoft.com>; Thu, 23 May 2002 9:59:18 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 889674 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 23 May 2002 09:59:18 -0400 Received: from 64.4.19.183 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 23 May 2002 09:49:18 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 23 May 2002 06:49:17 -0700 Received: from 62.90.130.2 by lw12fd.law12.hotmail.msn.com with HTTP; Thu, 23 May 2002 13:49:17 GMT X-Originating-IP: [62.90.130.2] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 23 May 2002 13:49:17.0437 (UTC) FILETIME=[A1CB5AD0:01C20260] Message-ID: Date: Thu, 23 May 2002 16:49:17 +0300 Reply-To: Mailing List Sender: Mailing List From: enosh levi Subject: OSPF Q:Does an OSPF Router have to update the LS age from the LSA in DB To: OSPF@DISCUSS.MICROSOFT.COM Hello The Q: If Ospf Router gets LSA with LS age diffrent than 0 and MaxAge, Does it has to install the LSA in the DB with the age that it got or with diffrent one (lets say 0) ? Thanks Enosh _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-ospf@DISCUSS.MICROSOFT.COM Thu May 23 10:53:53 2002 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 KAA13077 for ; Thu, 23 May 2002 10:53:53 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00619BEB@cherry.ease.lsoft.com>; Thu, 23 May 2002 10:54:10 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 889996 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 23 May 2002 10:54:10 -0400 Received: from 64.4.37.11 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 23 May 2002 10:54:10 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 23 May 2002 07:54:09 -0700 Received: from 155.245.254.253 by pv2fd.pav2.hotmail.msn.com with HTTP; Thu, 23 May 2002 14:54:09 GMT X-Originating-IP: [155.245.254.253] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 23 May 2002 14:54:09.0512 (UTC) FILETIME=[B1A6DE80:01C20269] Message-ID: Date: Thu, 23 May 2002 14:54:09 +0000 Reply-To: Mailing List Sender: Mailing List From: wu min Subject: Re: DR & BDR Election To: OSPF@DISCUSS.MICROSOFT.COM Hi Alex, Thank you for the reply and thanks for pointing out the previous question raised too. > A short answer to your questions would be---please follow > the spec. Yes, sir! For question (1) and (2), I am now clear of what DR and BDR fields in Hello packets should be. I got them mixed up with priority field :) However, I am still pretty vague with the election process. The following is a scenario and the effects and actions taken by routers (this is from my current understanding). Lets say we have 4 routers, namely, S, T, U, and V with priority 2, 3, 4, and 5 respectively. Initially none of the routers had interact with one another yet. When all first broadcasted their respective Hello packets, they declared themselves individually as DR but let BDR = 0.0.0.0. At this stage, all routers have received this information and they start to calculate (since this information is new to them, it triggers NeighbourChange event, and thus the calculation) and found out that there is no BDR yet and V should be nominated as DR. V, the newly elected DR, repeats step (2) and (3), but its perception about DR & BDR stays the same (DR = V; BDR= 0.0.0.0). The next moment, all broadcast individual Hello packets again, each Hello packet, except from U, still contain DR = V and BDR = 0.0.0.0. Hello packet from U now contains DR = V and BDR = U. All routers see the change and begin calculating again. Now every router realizes that BDR = U and DR = V and the election process complete for all routers except router U. U, the newly elected BDR, repeats step (2) and (3), but its perception about DR & BDR stays the same (DR = V; BDR= U). Election process ends. Subsequent Hello packets from all routers will have DR = V and BDR = U. I believe some part is wrong, but please point out to me. Further question: Should a router immediately broadcast a Hello packet when its perception about DR/BDR changed? Or just wait for the Hello Timer to expire? -Tze Ven _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-ospf@DISCUSS.MICROSOFT.COM Thu May 23 14:09:04 2002 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 OAA21057 for ; Thu, 23 May 2002 14:09:04 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0061A1E0@cherry.ease.lsoft.com>; Thu, 23 May 2002 14:07:31 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 891363 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 23 May 2002 14:07:31 -0400 Received: from 63.236.75.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 23 May 2002 14:07:31 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id A617A1E4A1; Thu, 23 May 2002 14:07:27 -0400 (EDT) Received: from [63.104.212.252] by xprdmailfe25.nwk.excite.com via HTTP; Thu, 23 May 2002 14:07:27 EST MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: multipart/alternative; boundary="EXCITEBOUNDARY_000__fad0d773520064c53254df1d592bca3d"; Content-Transfer-Encoding: 7bit Message-ID: <20020523180727.A617A1E4A1@xmxpita.excite.com> Date: Thu, 23 May 2002 14:07:27 -0400 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: OSPF Q:Does an OSPF Router have to update the LS age from the LSA in DB To: OSPF@DISCUSS.MICROSOFT.COM --EXCITEBOUNDARY_000__fad0d773520064c53254df1d592bca3d Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Enosh, Section 13 of RFC2328 5) d) says to "Install the new LSA in the link state database (replacing the current database copy)." This means copying each field "as is", including age, xsum, seq #, etc. Setting the age to zero could cause a lack of aging in your network, since one of the tie-breakers in sections 13.1 (deciding which LSA is newer) is differences in ages, causing the younger one to be installed. My 2 cents, Don --- On Thu 05/23, enosh levi wrote: > Hello > The Q: > If Ospf Router gets LSA with LS age diffrent than 0 and MaxAge, Does it > has > to install the LSA in the DB with the age that it got or with diffrent > one > (lets say 0) ? > > Thanks > Enosh > > > > _________________________________________________________________ > Send and receive Hotmail on your mobile device: http://mobile.msn.com > ------------------------------------------------ Join Excite! - http://www.excite.com The most personalized portal on the Web! --EXCITEBOUNDARY_000__fad0d773520064c53254df1d592bca3d Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Enosh,

Section 13 of RFC2328 5) d) says to "Install the new LSA in the link state database (replacing the current database copy)."

This means copying each field "as is", including age, xsum, seq #, etc. Setting the age to zero could cause a lack of aging in your
network, since one of the tie-breakers in sections 13.1 (deciding which LSA is newer) is differences in ages, causing the younger one
to be installed.

My 2 cents,
Don

--- On Thu 05/23, enosh levi < enosh_ospf_g@HOTMAIL.COM > wrote:
> Hello
> The Q:
> If Ospf Router gets LSA with LS age diffrent than 0 and MaxAge, Does it
> has
> to install the LSA in the DB with the age that it got or with diffrent
> one
> (lets say 0) ?
>
> Thanks
> Enosh
>
>
>
> _________________________________________________________________
> Send and receive Hotmail on your mobile device: http://mobile.msn.com
>

Join Excite! - http://www.excite.com
The most personalized portal on the Web! --EXCITEBOUNDARY_000__fad0d773520064c53254df1d592bca3d-- From owner-ospf@DISCUSS.MICROSOFT.COM Thu May 23 22:23:16 2002 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 WAA04076 for ; Thu, 23 May 2002 22:23:16 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0061B0D0@cherry.ease.lsoft.com>; Thu, 23 May 2002 22:23:33 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 893410 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 23 May 2002 22:23:33 -0400 Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 23 May 2002 22:22:28 -0400 Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 561E15D091; Fri, 24 May 2002 11:22:27 +0900 (JST) References: X-Mailer: Mew version 2.1 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20020524.111607.113946449.yasu@sfc.wide.ad.jp> Date: Fri, 24 May 2002 11:16:07 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: DR & BDR Election Comments: To: made_in__china@HOTMAIL.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Content-Transfer-Encoding: 7bit > Lets say we have 4 routers, namely, S, T, U, and V with priority 2, 3, 4, > and 5 respectively. Initially none of the routers had interact with one > another yet. When all first broadcasted their respective Hello > packets, they declared themselves individually as DR but let BDR = 0.0.0.0. > > At this stage, all routers have received this information and they start to > calculate (since this information is new to them, it triggers > NeighbourChange event, and thus the calculation) and found out that there is > no BDR yet and V should be nominated as DR. > > V, the newly elected DR, repeats step (2) and (3), but its perception about > DR & BDR stays the same (DR = V; BDR= 0.0.0.0). > > The next moment, all broadcast individual Hello packets again, each Hello > packet, except from U, still contain DR = V and BDR = 0.0.0.0. Hello packet > from U now contains DR = V and BDR = U. All routers see the change and begin > calculating again. Now every router realizes that BDR = U and DR = V and the > election process complete for all routers except router U. > > U, the newly elected BDR, repeats step (2) and (3), but its perception about > DR & BDR stays the same (DR = V; BDR= U). Election process ends. Subsequent > Hello packets from all routers will have DR = V and BDR = U. > > I believe some part is wrong, but please point out to me. Why (and where) do you believe some part is wrong ? Practically It will be more complexed depending when to receive the other's Hello packets, but your understanding seems almost correct to me. > Further question: Should a router immediately broadcast a Hello packet when > its perception about DR/BDR changed? Or just wait for the Hello Timer to > expire? It's implementation dependent, but I believe latter. If all the router on a segment behaves like former, the segment's Hello will be almost synchronized. regards. yasu. From owner-ospf@DISCUSS.MICROSOFT.COM Thu May 23 22:44:19 2002 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 WAA04796 for ; Thu, 23 May 2002 22:44:18 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0061B278@cherry.ease.lsoft.com>; Thu, 23 May 2002 22:44:37 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 893445 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 23 May 2002 22:44:37 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 23 May 2002 22:44:37 -0400 Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with esmtp (Exim 3.36 #1) id 17B54F-00080a-00; Thu, 23 May 2002 19:44:35 -0700 X-Mailer: The Bat! (v1.51) Personal X-Priority: 3 (Normal) References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <10131945904.20020523194306@psg.com> Date: Thu, 23 May 2002 19:43:06 -0700 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: DR & BDR Election Comments: To: wu min To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Content-Transfer-Encoding: 7bit Tze Ven: ... > Lets say we have 4 routers, namely, S, T, U, and V with priority 2, 3, 4, > and 5 respectively. Initially none of the routers had interact with one > another yet. When all first broadcasted their respective Hello > packets, they declared themselves individually as DR but let BDR = 0.0.0.0. > At this stage, all routers have received this information and they start to > calculate (since this information is new to them, it triggers > NeighbourChange event, and thus the calculation) and found out that there is > no BDR yet and V should be nominated as DR. Here, they _will_ elect the BDR as well. Please see section 9.4, step 2. ... > Further question: Should a router immediately broadcast a Hello packet when > its perception about DR/BDR changed? Or just wait for the Hello Timer to > expire? Yasu is correct. You should just use the timer. Alex From owner-ospf@DISCUSS.MICROSOFT.COM Thu May 23 23:24:45 2002 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 XAA05850 for ; Thu, 23 May 2002 23:24:44 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0061B438@cherry.ease.lsoft.com>; Thu, 23 May 2002 23:24:39 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 893753 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 23 May 2002 23:24:39 -0400 Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 23 May 2002 23:24:39 -0400 Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id B815E5D092; Fri, 24 May 2002 12:24:37 +0900 (JST) References: <10131945904.20020523194306@psg.com> X-Mailer: Mew version 2.1 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20020524.121818.133249527.yasu@sfc.wide.ad.jp> Date: Fri, 24 May 2002 12:18:18 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: DR & BDR Election Comments: To: zinin@PSG.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <10131945904.20020523194306@psg.com> Content-Transfer-Encoding: 7bit zinin> > At this stage, all routers have received this information and zinin> > they start to calculate (since this information is new to zinin> > them, it triggers NeighbourChange event, and thus the zinin> > calculation) and found out that there is no BDR yet and V zinin> > should be nominated as DR. zinin> zinin> Here, they _will_ elect the BDR as well. Please see section zinin> 9.4, step 2.... Strictly, guessing his assumption, at this time all the routers still electing itself as DR, so the BDR will not be found except U. regards yasu. From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 24 00:26:24 2002 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 AAA07720 for ; Fri, 24 May 2002 00:26:24 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0061B79F@cherry.ease.lsoft.com>; Fri, 24 May 2002 0:23:50 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 894005 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 24 May 2002 00:23:49 -0400 Received: from 207.217.120.84 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Fri, 24 May 2002 00:23:49 -0400 Received: from 209-239-210-105.oak.jps.net ([209.239.210.105] helo=earthlink.net) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 17B6cF-00046d-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 23 May 2002 21:23:48 -0700 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: <3CEDC266.CEDF54CF@earthlink.net> Date: Thu, 23 May 2002 21:32:38 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: DR & BDR Election To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit To add additional confusion... In footnote RFC 2328[5], when a DR expires the BDR will become both the DR and the BDR for a short period of time. Wanted to clarify #1 below. Of course, a router may on one interface be the DR and on another interface be the BDR. In addition only after a wait period, can the DR or BDR be elected. If a DR is elected and a router with a higher priority comes up after the election. The election is not run again.. Mitchell Erblich wu min wrote: > > Hi, > > I am pretty new to OSPF and I have a couple of questions. I would appreciate > some help. > > 1. Can a router declares itself as DR and BDR simultaneously (just in case > that it may not be choosen to be a DR, it have some chance to take up BDR > post)? > > 2. Should *other* routers keep declaring themselves (eligible to be) DR or > BDR in HelloPackets eventhough both DR and BDR were already choosen? > > 3. In section 9.4, page 76 of RFC2328, step (4), why does the newly selected > DR or BDR (or resigning DR or BDR), is required to run step (2) and (3) > again? Take for instance, if it knew that it was being elected as the new > designated DR or BDR in the first run of step (2) and (3), repeating step > (2) and step (3) again will never change its view. Am I missing something > here? > > 4. Is it true that if a router that was previously a BDR (and also has been > declaring itself as BDR only in its HelloPacket), but now being elected as > new DR to replace the old one, must declare itself as DS in its subsequence > HelloPackets? > > Thanks in advance. > > -Tze Ven > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 24 10:41:54 2002 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 KAA00451 for ; Fri, 24 May 2002 10:41:54 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0061C418@cherry.ease.lsoft.com>; Fri, 24 May 2002 10:42:11 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 874741 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 24 May 2002 10:42:11 -0400 Received: from 64.4.37.120 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Fri, 24 May 2002 10:42:11 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 24 May 2002 07:42:10 -0700 Received: from 155.245.254.253 by pv2fd.pav2.hotmail.msn.com with HTTP; Fri, 24 May 2002 14:42:10 GMT X-Originating-IP: [155.245.254.253] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 24 May 2002 14:42:10.0785 (UTC) FILETIME=[2FAB9510:01C20331] Message-ID: Date: Fri, 24 May 2002 14:42:10 +0000 Reply-To: Mailing List Sender: Mailing List From: wu min Subject: Re: DR & BDR Election To: OSPF@DISCUSS.MICROSOFT.COM Hi Yasu and Alex, Yes, it can be more complex than this as Yasu pointed out, however I try to keep it simple because I only intended to make myself clear of the fundamental working of the election process. I will figure out the rest of the complexities and try on my own once I am pretty sure about its basic working (unless I bump into problem again :). The assumption made on paragraph 2 and 4 of my previous example is that all individual Hello packets are transmitted (and also received) around the same time (this simplifies the example :). Both of you mentioned that the BDR should be elected as well during the first round so I have augmented the scenario below. Please verify it for me. >Lets say we have 4 routers, namely, S, T, U, and V with priority 2, >3, 4, and 5 respectively. Initially none of the routers had interact >with one another yet. When all first broadcasted their respective >Hello packets, they declared themselves individually as DR but let >BDR = 0.0.0.0. > >At this stage, all routers have received this information and they >start to calculate (since this information is new to them, it triggers >NeighbourChange event, and thus the calculation) and found out that >there is no BDR yet and V should be nominated as DR. [If I followed the rules strictly, then the statements below should be true and should come after the last paragraph above] All routers EXCEPT ROUTER V will *repeat* steps (2) and (3) since they realize that they are no longer *once believed* to be DRs. However after the execution, their perceptions about DR & BDR stays the same (DR = V; BDR = 0.0.0.0) since no one claims to be BDR (the BDR field in their HelloPacket was 0.0.0.0) EXCEPT FOR ROUTER U where it now nominates itself as BDR (however it keeps its DR = V). >V, the newly elected DR, repeats step (2) and (3), but its perception >about DR & BDR stays the same (DR = V; BDR = 0.0.0.0). This statement (the above paragraph) is no more valid. >The next moment, all broadcast individual Hello packets again, each >Hello packet, except from U, still contain DR = V and BDR = 0.0.0.0. >Hello packet from U now contains DR = V and BDR = U. All routers see >the change and begin calculating again. Now every router realizes >that BDR = U and DR = V and the election process complete for all >routers except router U. [Please verify the additional statements below] Note that all routers, except router U, trigger NeighbourChange event and thus start calculating because router U's HelloPacket contents is different from their views. Whereas, router U triggers NeighbourChange event and thus start calculating because all other routers' HelloPackets contents are different from its view. So effectively all routers see the change and start calculating. [Modification] The last statement in the paragraph above should read, "Now every router realizes that BDR = U and DR = V and the election process are completed for all routers INCLUDING router U". The reason is stated below. >U, the newly elected BDR, repeats step (2) and (3), but its >perception about DR & BDR stays the same (DR = V; BDR= U). Election >process ends. The paragraph above is not valid since router U has already assumed the BDR post since prior to the last broadcast and its view never change till this current stage. Due to this, note that during this round, no router *re-execute* steps (2) and (3). >Subsequent Hello packets from all routers will have DR = V and >BDR = U. Thank you in advance. -Tze Ven. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From owner-ospf@DISCUSS.MICROSOFT.COM Sat May 25 02:22:16 2002 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 CAA13876 for ; Sat, 25 May 2002 02:22:15 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0061E17C@cherry.ease.lsoft.com>; Sat, 25 May 2002 2:22:34 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 876634 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 25 May 2002 02:22:34 -0400 Received: from 207.217.120.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Sat, 25 May 2002 02:22:34 -0400 Received: from 209-239-195-22.oak.jps.net ([209.239.195.22] helo=earthlink.net) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17BUwj-00018C-00 for ospf@discuss.microsoft.com; Fri, 24 May 2002 23:22:33 -0700 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3CEF2FBF.77B7D7B9@earthlink.net> Date: Fri, 24 May 2002 23:31:27 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: DR and BDR election: Simplified.. To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit I would like to try to simplify the election process.. Flames are expected... Please be aware that I tend to be verbose.. here goes... Assuming the proper network topology and that all the routers have just come up and that the BDR and DR are initially defined as 0.0.0.0... 1) First we wait for the configured wait time to expire.. 2) Now we walk thru all the viable routers who can be the BDR. They should be at least in the 2WAY state and have a non-zero priority.. 3) The highest priority one becomes the BDR... 4) Now we do #2 and #3 for the DR.. 5) The highest priority router actually becomes the DR because he was promoted to become the DR.. See Cisco ref #5 and #6.p. 422 Chapt 9. OSPF... 6) Problem is that he is now the BDR AND the DR.. 7) So we run the election for the BDR again eliminating the DR as a viable candidate for the BDR and get the next highest priority eligible router as the BDR.. If their is no candidate now for the BDR position it is set to 0.0.0.0.. 8) This is it in a nutshell.. Or what was originally coded years ago.. *** Again this is just one sequence that goes with the election process.. No, * I have not covered the DR who due to RouterDeadInterval lost his DR status.. * I have not covered when their is an existing DR... * Etc... My understanding of the confusion is with declaration of multiple routers declaring themselves the DR or BDR when an area was PARTITIONED and only remerged.. Paritioning may also happen if one or more hello parameters was not matched with all the routers, but actually formed two or more sets of routers within an area.. I BELIEVE, One or more routers may declare themselves ONLY if the areas or subareas was then merged together.. This is how you can have two or more DRs or BDRs declaring themselves as such. Only in this case, will you elect the router with the highest priority in both cases to become the newer BDR and DR from the declared groups.. Hope this helps... Mitchell Erblich From owner-ospf@DISCUSS.MICROSOFT.COM Mon May 27 05:13:25 2002 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 FAA14985 for ; Mon, 27 May 2002 05:13:24 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00623C28@cherry.ease.lsoft.com>; Mon, 27 May 2002 5:13:46 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 883983 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 27 May 2002 05:13:46 -0400 Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Mon, 27 May 2002 05:13:46 -0400 Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 0497D5D01F; Mon, 27 May 2002 18:13:44 +0900 (JST) References: X-Mailer: Mew version 2.1 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20020527.180720.64764002.yasu@sfc.wide.ad.jp> Date: Mon, 27 May 2002 18:07:20 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: DR & BDR Election Comments: To: made_in__china@HOTMAIL.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Content-Transfer-Encoding: 7bit (Citations are some snipped) > time (this simplifies the example :). Both of you mentioned that the BDR > should be elected as well during the first round so I have augmented the > scenario below. Please verify it for me. > [If I followed the rules strictly, then the statements below should be true > and should come after the last paragraph above] > All routers EXCEPT ROUTER V will *repeat* steps (2) and (3) since they > realize that they are no longer *once believed* to be DRs. However after the > execution, their perceptions about DR & BDR stays the same (DR = V; BDR = > 0.0.0.0) since no one claims to be BDR (the BDR field in their HelloPacket > was 0.0.0.0) EXCEPT FOR ROUTER U where it now nominates itself as BDR > (however it keeps its DR = V). This is not true. A router will calculate BDR even if no routers have declared themselves BDR (See RFC2328 9.4 (2)). So if the router have known all the routers on the segment before DR Election process, the router can calculate proper DR & BDR. > >V, the newly elected DR, repeats step (2) and (3), but its perception > >about DR & BDR stays the same (DR = V; BDR = 0.0.0.0). > > This statement (the above paragraph) is no more valid. Above also applies here. > [Please verify the additional statements below] > Note that all routers, except router U, trigger NeighbourChange event and > thus start calculating because router U's HelloPacket contents is different > from their views. Whereas, router U triggers NeighbourChange event and thus > start calculating because all other routers' HelloPackets contents are > different from its view. So effectively all routers see the change and start > calculating. An OSPF router never compares his DR/BDR view with the other's. The OSPF router only cares about the other's *change* of DR/BDR view, by storing and comparing the other router's previous DR/BDR view. Every time the change detected, the router generates NeighborChange event(s). > >U, the newly elected BDR, repeats step (2) and (3), but its > >perception about DR & BDR stays the same (DR = V; BDR= U). Election > >process ends. > > The paragraph above is not valid since router U has already assumed the BDR > post since prior to the last broadcast and its view never change till this > current stage. Due to this, note that during this round, no router > *re-execute* steps (2) and (3). An OSPF router repeats steps (2) and (3) every time if his DR/BDR view has been changed. It is needed because it means previous condition of (2) & (3) has been changed, so the results of the previous processes (2) & (3) are recognized as obsolete. regards. yasu From owner-ospf@DISCUSS.MICROSOFT.COM Mon May 27 07:36:48 2002 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 HAA16601 for ; Mon, 27 May 2002 07:36:48 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00623CD0@cherry.ease.lsoft.com>; Mon, 27 May 2002 7:37:09 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 884776 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 27 May 2002 07:37:09 -0400 Received: from 66.163.169.58 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Mon, 27 May 2002 07:37:08 -0400 Received: from [203.200.20.226] by web21509.mail.yahoo.com via HTTP; Mon, 27 May 2002 04:37:07 PDT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-732422599-1022499427=:80227" Message-ID: <20020527113707.80401.qmail@web21509.mail.yahoo.com> Date: Mon, 27 May 2002 04:37:07 -0700 Reply-To: Mailing List Sender: Mailing List From: Amit Srivastava Subject: Opaque LSA To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20020527.180720.64764002.yasu@sfc.wide.ad.jp> --0-732422599-1022499427=:80227 Content-Type: text/plain; charset=us-ascii Hi All, My Doubt is that if a router which is opaque LSA capable cannot become DR and the DR on the network is not supporting then how will the information be flooded to the other routers in the network which are opaque LSA capable. regards amit --------------------------------- Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup --0-732422599-1022499427=:80227 Content-Type: text/html; charset=us-ascii

 Hi All,

             My Doubt is that if a router which is opaque LSA capable cannot become DR and the DR on the network is not supporting then how will the information be flooded to the other routers in the network which are opaque LSA capable.

regards

amit


Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup --0-732422599-1022499427=:80227-- From owner-ospf@DISCUSS.MICROSOFT.COM Mon May 27 08:29:06 2002 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 IAA17190 for ; Mon, 27 May 2002 08:29:05 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00623D76@cherry.ease.lsoft.com>; Mon, 27 May 2002 8:29:27 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 884876 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 27 May 2002 08:29:27 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Mon, 27 May 2002 08:29:26 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 May 2002 08:25:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2057A.1AD8F3D0" Message-ID: Date: Mon, 27 May 2002 08:29:11 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Opaque LSA To: OSPF@DISCUSS.MICROSOFT.COM 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_01C2057A.1AD8F3D0 Content-Type: text/plain; charset="iso-8859-1" Hi Amit, As the OSPF spec today stands, there is no means to do that. An operator needs to be careful while configuring the priorities and order in which the routers are brought up, so that the DR is opaque capable. It however could be achieved, that the DR is Opaque capable, by setting the priority to higher than the existing DR and doing a slight, backward compatible change, to the DR election to do the following: - When the Opaque capable router comes up and realizes that the DR is not opaque capable, it could well claim itself to be the DR. The DR election would take place and the DR with higher priority would be chosen the DR and in case the opaque capable router has higher priority it could become the DR. This would be backward compatible in the sense that all routers would choose the same DR. However I do not know of anyone who does this. ;-) Thanks, Vishwas -----Original Message----- From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM] Sent: Monday, May 27, 2002 5:07 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Opaque LSA Hi All, My Doubt is that if a router which is opaque LSA capable cannot become DR and the DR on the network is not supporting then how will the information be flooded to the other routers in the network which are opaque LSA capable. regards amit ------_=_NextPart_001_01C2057A.1AD8F3D0 Content-Type: text/html; charset="iso-8859-1"
Hi Amit,
 
As the OSPF spec today stands, there is no means to do that. An operator needs to be careful while configuring the priorities and order in which the routers are brought up, so that the DR is opaque capable.
 
It however could be achieved, that the DR is Opaque capable, by setting the priority to higher than the existing DR and doing a slight, backward compatible change, to the DR election to do the following: -
 
When the Opaque capable router comes up and realizes that the DR is not opaque capable, it could well claim itself to be the DR. The DR election would take place and the DR with higher priority would be chosen the DR and in case the opaque capable router has higher priority it could become the DR.
 
This would be backward compatible in the sense that all routers would choose the same DR. However I do not know of anyone who does this. ;-)
 
Thanks,
Vishwas
-----Original Message-----
From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
Sent: Monday, May 27, 2002 5:07 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Opaque LSA

 Hi All,

             My Doubt is that if a router which is opaque LSA capable cannot become DR and the DR on the network is not supporting then how will the information be flooded to the other routers in the network which are opaque LSA capable.

regards

amit

------_=_NextPart_001_01C2057A.1AD8F3D0-- From owner-ospf@DISCUSS.MICROSOFT.COM Mon May 27 09:37:09 2002 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 JAA18671 for ; Mon, 27 May 2002 09:37:08 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00623D8E@cherry.ease.lsoft.com>; Mon, 27 May 2002 9:37:30 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 885029 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 27 May 2002 09:37:30 -0400 Received: from 64.4.37.125 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Mon, 27 May 2002 09:37:30 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 27 May 2002 06:37:29 -0700 Received: from 155.245.254.253 by pv2fd.pav2.hotmail.msn.com with HTTP; Mon, 27 May 2002 13:37:29 GMT X-Originating-IP: [155.245.254.253] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 27 May 2002 13:37:29.0756 (UTC) FILETIME=[A5A2CDC0:01C20583] Message-ID: Date: Mon, 27 May 2002 13:37:29 +0000 Reply-To: Mailing List Sender: Mailing List From: wu min Subject: Re: DR & BDR Election To: OSPF@DISCUSS.MICROSOFT.COM Hi Yasu, I have more questions. Below is the convention used to describe part of the interface state of a router for the following scenario: +---------+--------+ |Router ID|Priority| +---------+--------+ | DR | +------------------+ | BDR | +------------------+ Scenario ======== Note: Each box represents each router indicated by the router id field. new comer +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ |A|5| |B|3| |C|4| |D|1| |E|2| |X|6| +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ | A | | A | | A | | A | | A | | X | +---+ +---+ +---+ +---+ +---+ +---+ | C | | C | | C | | C | | C | | - | +---+ +---+ +---+ +---+ +---+ +---+ [Figure 1] | Every router broadcasts its own Hello packet and those packets are received by every other router just about the same time | V *+-+-+ *+-+-+ *+-+-+ *+-+-+ *+-+-+ *+-+-+(i) |A|5| |B|3| |C|4| |D|1| |E|2| |X|6| +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ | X | | X | | X | | X | | X | | X | +---+ +---+ +---+ +---+ +---+ +---+ | C | | C | | C | | C | | C | | C | +---+ +---+ +---+ +---+ +---+ +---+ | (ii) V +-+-+(iii) |A|5| +-+-+ | X | +---+ | C | +---+ [Figure 2] In figure 1, a new router, X, appears. In figure 2, every router see new router(s) appears and all trigger NeighbourChange event (indicated by * at the top-left of each box), thus each begins calculating and as the result every router nominates X as the new DR and C as BDR. Note: (i) At step (2) it found router C should be elected as BDR. At step (3) it still found itself a DR so need not repeat steps (2) and (3). (ii) Repeat steps (2) and (3) since it is now stripped off from DR post. (iii) However its view about DR and BDR never change. Question --------- I have doubt with (ii) and (iii). Should router A have placed itself in BDR candidates list before recalculating steps (2) and (3) or just allow router C to retain its BDR post? >An OSPF router never compares his DR/BDR view with the other's. The >OSPF router only cares about the other's *change* of DR/BDR view, by >storing and comparing the other router's previous DR/BDR view. Every >time the change detected, the router generates NeighborChange event(s). Thank you for pointing out this. >An OSPF router repeats steps (2) and (3) every time if his DR/BDR >view has been changed. It is needed because it means previous >condition of (2) & (3)has been changed, so the results of the previous >processes (2) & (3) are recognized as obsolete. I can understand why a newly designated DR needs to repeat steps (2) and (3). Those steps avoid the router from claiming to be DR and BDR at one time. However I cannot see why *repetition* of those steps are required for a router that self-nominate as BDR, resigning from BDR, or resigning from DR, as indicated by step (4) because even after the recalculation, its view will never change. Do I miss any important point here? Thank you in advance. -Tze Ven _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-ospf@DISCUSS.MICROSOFT.COM Mon May 27 23:47:41 2002 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 XAA29463 for ; Mon, 27 May 2002 23:47:41 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0062516F@cherry.ease.lsoft.com>; Mon, 27 May 2002 23:47:58 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 886699 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 27 May 2002 23:47:58 -0400 Received: from 66.163.169.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Mon, 27 May 2002 23:47:58 -0400 Received: from [203.200.20.226] by web21506.mail.yahoo.com via HTTP; Mon, 27 May 2002 20:47:57 PDT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-458740933-1022557677=:63396" Message-ID: <20020528034757.64229.qmail@web21506.mail.yahoo.com> Date: Mon, 27 May 2002 20:47:57 -0700 Reply-To: Mailing List Sender: Mailing List From: Amit Srivastava Subject: RIP-OSPF Interaction To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: --0-458740933-1022557677=:63396 Content-Type: text/plain; charset=us-ascii Hi All, My Doubt is that within the same Autonomous system if both OSPF and RIP are running and a router runs RIP on one interface and OSPF on the other then the routes that are learned by RIP will be flooded in the OSPF domain as intera area , inter area or As external Path??? regards Amit --------------------------------- Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup --0-458740933-1022557677=:63396 Content-Type: text/html; charset=us-ascii

 Hi All,

           My Doubt is that within the same Autonomous system if both OSPF and RIP are running and a router runs RIP on one interface and OSPF on the other then the routes that are learned by RIP will be flooded in the OSPF domain as intera area , inter area or As external Path???

regards

Amit


Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup --0-458740933-1022557677=:63396-- From owner-ospf@DISCUSS.MICROSOFT.COM Mon May 27 23:49:40 2002 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 XAA29482 for ; Mon, 27 May 2002 23:49:40 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.0062500F@cherry.ease.lsoft.com>; Mon, 27 May 2002 23:50:02 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 886730 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 27 May 2002 23:50:02 -0400 Received: from 66.163.169.58 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Mon, 27 May 2002 23:50:02 -0400 Received: from [203.200.20.226] by web21509.mail.yahoo.com via HTTP; Mon, 27 May 2002 20:50:01 PDT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-286213398-1022557801=:73290" Message-ID: <20020528035001.79698.qmail@web21509.mail.yahoo.com> Date: Mon, 27 May 2002 20:50:01 -0700 Reply-To: Mailing List Sender: Mailing List From: Amit Srivastava Subject: Re: Opaque LSA To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: --0-286213398-1022557801=:73290 Content-Type: text/plain; charset=us-ascii Hi Vishwas!! Even i thought the same thing but RFC 2370 no where specifies that your Opaque LSA specking router should always be DR!! Thanks for the help!! regards Amit "Manral, Vishwas" wrote: Hi Amit, As the OSPF spec today stands, there is no means to do that. An operator needs to be careful while configuring the priorities and order in which the routers are brought up, so that the DR is opaque capable. It however could be achieved, that the DR is Opaque capable, by setting the priority to higher than the existing DR and doing a slight, backward compatible change, to the DR election to do the following: - When the Opaque capable router comes up and realizes that the DR is not opaque capable, it could well claim itself to be the DR. The DR election would take place and the DR with higher priority would be chosen the DR and in case the opaque capable router has higher priority it could become the DR. This would be backward compatible in the sense that all routers would choose the same DR. However I do not know of anyone who does this. ;-) Thanks,Vishwas-----Original Message----- From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM] Sent: Monday, May 27, 2002 5:07 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Opaque LSA Hi All, My Doubt is that if a router which is opaque LSA capable cannot become DR and the DR on the network is not supporting then how will the information be flooded to the other routers in the network which are opaque LSA capable. regards amit --------------------------------- Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup --0-286213398-1022557801=:73290 Content-Type: text/html; charset=us-ascii

Hi Vishwas!!

               Even i thought the same thing but RFC 2370 no where specifies that your Opaque LSA specking router should always be DR!!

Thanks for the help!!

regards

Amit

  "Manral, Vishwas" <VishwasM@NETPLANE.COM> wrote:

Hi Amit,
 
As the OSPF spec today stands, there is no means to do that. An operator needs to be careful while configuring the priorities and order in which the routers are brought up, so that the DR is opaque capable.
 
It however could be achieved, that the DR is Opaque capable, by setting the priority to higher than the existing DR and doing a slight, backward compatible change, to the DR election to do the following: -
 
When the Opaque capable router comes up and realizes that the DR is not opaque capable, it could well claim itself to be the DR. The DR election would take place and the DR with higher priority would be chosen the DR and in case the opaque capable router has higher priority it could become the DR.
 
This would be backward compatible in the sense that all routers would choose the same DR. However I do not know of anyone who does this. ;-)
 
Thanks,
Vishwas
-----Original Message-----
From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
Sent: Monday, May 27, 2002 5:07 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Opaque LSA

 Hi All,

             My Doubt is that if a router which is opaque LSA capable cannot become DR and the DR on the network is not supporting then how will the information be flooded to the other routers in the network which are opaque LSA capable.

regards

amit


Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup --0-286213398-1022557801=:73290-- From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 28 02:15:37 2002 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 CAA09419 for ; Tue, 28 May 2002 02:15:37 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.006254BA@cherry.ease.lsoft.com>; Tue, 28 May 2002 2:15:58 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 887315 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 28 May 2002 02:15:58 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Tue, 28 May 2002 02:15:58 -0400 Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with esmtp (Exim 3.36 #1) id 17CaGy-000OVO-00; Mon, 27 May 2002 23:15:56 -0700 X-Mailer: The Bat! (v1.51) Personal X-Priority: 3 (Normal) References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <5517778685.20020527231422@psg.com> Date: Mon, 27 May 2002 23:14:22 -0700 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: Opaque LSA Comments: To: "Manral, Vishwas" To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Content-Transfer-Encoding: 7bit Vishwas, BTW, that's exactly the method that one can use if the DR responsibility needs to be reassigned to another router without disconnecting the interfaces (remember the thread about a month ago about ISIS-ish DR election). I promised one person to send a message on this to the list, but got disrupted apparently :) -- Alex Monday, May 27, 2002, 5:29:11 AM, you wrote: > Hi Amit, > As the OSPF spec today stands, there is no means to do that. An operator > needs to be careful while configuring the priorities and order in which the > routers are brought up, so that the DR is opaque capable. > It however could be achieved, that the DR is Opaque capable, by setting the > priority to higher than the existing DR and doing a slight, backward > compatible change, to the DR election to do the following: - > When the Opaque capable router comes up and realizes that the DR is not > opaque capable, it could well claim itself to be the DR. The DR election > would take place and the DR with higher priority would be chosen the DR and > in case the opaque capable router has higher priority it could become the > DR. > This would be backward compatible in the sense that all routers would choose > the same DR. However I do not know of anyone who does this. ;-) > Thanks, > Vishwas > -----Original Message----- > From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM] > Sent: Monday, May 27, 2002 5:07 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Opaque LSA > Hi All, > My Doubt is that if a router which is opaque LSA capable cannot > become DR and the DR on the network is not supporting then how will the > information be flooded to the other routers in the network which are opaque > LSA capable. > regards > amit From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 28 02:51:24 2002 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 CAA09716 for ; Tue, 28 May 2002 02:51:22 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00625785@cherry.ease.lsoft.com>; Tue, 28 May 2002 2:51:43 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 887494 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 28 May 2002 02:51:43 -0400 Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Tue, 28 May 2002 02:51:43 -0400 Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id C2FD95D00D; Tue, 28 May 2002 15:51:40 +0900 (JST) References: X-Mailer: Mew version 2.1 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20020528.154515.58386327.yasu@sfc.wide.ad.jp> Date: Tue, 28 May 2002 15:45:15 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: DR & BDR Election Comments: To: made_in__china@HOTMAIL.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Content-Transfer-Encoding: 7bit > Question > --------- > I have doubt with (ii) and (iii). Should router A have placed itself in BDR > candidates list before recalculating steps (2) and (3) or just allow router > C to retain its BDR post? In my understanding, an implementation strictly following RFC2328 will do latter: just allow router C to retain its BDR post. The next BDR view of the segment depends on whether A will declare itself as BDR or not. > I can understand why a newly designated DR needs to repeat steps (2) and > (3). Those steps avoid the router from claiming to be DR and BDR at one > time. However I cannot see why *repetition* of those steps are required for > a router that self-nominate as BDR, resigning from BDR, or resigning from > DR, as indicated by step (4) because even after the recalculation, its view > will never change. Do I miss any important point here? I can't think of a situation where the 2nd calculation of DR (2nd (3)) is necessary ... (I want someone to teach me ...) But obviously 2nd calculation of BDR (2nd (2)) is necessary, see below: # note: RFC2328 9.4 (2) describes BDR calculation, (3) describes DR # calculation new comer +-+-+ +-+-+ +-+-+ |A|1| |B|0| |C|2| +-+-+ +-+-+ +-+-+ | A | | A | | C | +---+ +---+ +---+ | - | | - | | - | +---+ +---+ +---+ after C 1st (2)(3) - after C 2nd (2) A Router B has priority 0 so he is not eligible to become neither DR nor BDR. So before the newcomer comes, the segment's DR is A and BDR is none. Looking into A's calculation, After the newcomer has come and just after 1st calculation of DR/BDR, A has just resigned DR but he's yet eligible to become BDR. If we don't recalculate BDR/DR again, A cannot realize that he can be BDR. regards. yasu From owner-ospf*ospf-archive**LISTS*-IETF*-ORG@DISCUSS.MICROSOFT.COM Tue May 28 10:15:44 2002 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 KAA19682 for ; Tue, 28 May 2002 10:15:44 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0062600C@cherry.ease.lsoft.com>; Tue, 28 May 2002 10:16:06 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 889408 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 28 May 2002 10:16:05 -0400 Received: from 205.173.58.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Tue, 28 May 2002 10:16:03 -0400 Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.11.6+Sun/8.11.0) with ESMTP id g4SEJFN00419 for ; Tue, 28 May 2002 09:19:15 -0500 (CDT) Received: from TRIMAIL2.ad.tri.sbc.com (localhost [127.0.0.1]) by sbctri.tri.sbc.com (8.11.6+Sun/8.9.3) with ESMTP id g4SEFA700928 for ; Tue, 28 May 2002 09:15:10 -0500 (CDT) Received: by TRIMAIL2.ad.tri.sbc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 May 2002 09:15:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20652.2BBCBEB0" Message-ID: <905A1C4ABF353F4C8CC16FA9F53DD0D6380D29@TRIMAIL2.ad.tri.sbc.com> Date: Tue, 28 May 2002 09:15:51 -0500 Reply-To: Mailing List Sender: Mailing List From: "Karasick, Stephanie" Subject: unsubscribe To: OSPF@DISCUSS.MICROSOFT.COM 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_01C20652.2BBCBEB0 Content-Type: text/plain; charset="gb2312" unsubscribe ------_=_NextPart_001_01C20652.2BBCBEB0 Content-Type: text/html; charset="gb2312"
unsubscribe
------_=_NextPart_001_01C20652.2BBCBEB0-- From owner-ospf@DISCUSS.MICROSOFT.COM Tue May 28 11:11:40 2002 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 LAA21363 for ; Tue, 28 May 2002 11:11:40 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0062629C@cherry.ease.lsoft.com>; Tue, 28 May 2002 11:12:02 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 889771 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 28 May 2002 11:12:02 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Tue, 28 May 2002 11:12:02 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 7079218D3F4 for ; Tue, 28 May 2002 08:12:00 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20020528034757.64229.qmail@web21506.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3CF39DAE.3090006@redback.com> Date: Tue, 28 May 2002 11:09:34 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: RIP-OSPF Interaction To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Amit Srivastava wrote: > Hi All, > > My Doubt is that within the same Autonomous system if both > OSPF and RIP are running and a router runs RIP on one interface and OSPF > on the other then the routes that are learned by RIP will be flooded in > the OSPF domain as intera area , inter area or As external Path??? All non-OSPF routes redistributed (aka, imported) into the OSPF routing domain are advertised using type 5 (AS external) LSAs or type 7 (NSSA) LSAs. > > regards > > Amit > > > ------------------------------------------------------------------------ > *Do You Yahoo!?* > Yahoo! - > Official partner of 2002 FIFA World Cup -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 29 02:23:17 2002 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 CAA28933 for ; Wed, 29 May 2002 02:23:17 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.006282E8@cherry.ease.lsoft.com>; Wed, 29 May 2002 2:23:40 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 893088 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 29 May 2002 02:23:40 -0400 Received: from 66.163.169.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 29 May 2002 02:23:40 -0400 Received: from [203.200.20.226] by web21501.mail.yahoo.com via HTTP; Tue, 28 May 2002 23:23:39 PDT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-321475655-1022653419=:57270" Message-ID: <20020529062339.62149.qmail@web21501.mail.yahoo.com> Date: Tue, 28 May 2002 23:23:39 -0700 Reply-To: Mailing List Sender: Mailing List From: Amit Srivastava Subject: OSPF-TE interaction To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3CF39DAE.3090006@redback.com> --0-321475655-1022653419=:57270 Content-Type: text/plain; charset=us-ascii Hi All, Thanks Acee for the help.I have one more doubt regarding the opaque LSA and TE.The opaque LSA is used to carry some network related information.How do you configure your opaque LSA to carry the network related information such as Link type,Link ID,Max bandwidth,unreserved Bandwidth,Max reservable bandwidth e.t.c Are these information configured via CLI(that is what i think)???If yes then what are the commands that are used to configure the opaque LSA for TE.Bcoz i went through the OSPF commands it says little about the configuration of network information related to TE. regards Amit --------------------------------- Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup --0-321475655-1022653419=:57270 Content-Type: text/html; charset=us-ascii

Hi All,

         Thanks Acee for the help.I have one more doubt regarding the opaque LSA and TE.The opaque LSA is used to carry some

network related information.How do you configure your opaque LSA to carry the network related information such as Link type,Link ID,Max bandwidth,unreserved Bandwidth,Max reservable bandwidth e.t.c

                                              Are these information configured via CLI(that is what i think)???If yes then what are the commands that are used to configure the opaque LSA for TE.Bcoz i went through the OSPF commands it says little about the configuration of network information related to TE.

regards

Amit


Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup --0-321475655-1022653419=:57270-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 29 09:40:41 2002 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 JAA16896 for ; Wed, 29 May 2002 09:40:41 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00628A35@cherry.ease.lsoft.com>; Wed, 29 May 2002 9:41:03 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 895883 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 29 May 2002 09:41:03 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 29 May 2002 09:41:03 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id D49742CDB42 for ; Wed, 29 May 2002 06:41:01 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20020529062339.62149.qmail@web21501.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3CF4D9D0.8080502@redback.com> Date: Wed, 29 May 2002 09:38:24 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF-TE interaction To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Amit Srivastava wrote: > Hi All, > > Thanks Acee for the help.I have one more doubt regarding the > opaque LSA and TE.The opaque LSA is used to carry some > > network related information.How do you configure your opaque LSA to > carry the network related information such as Link type,Link ID,Max > bandwidth,unreserved Bandwidth,Max reservable bandwidth e.t.c > > Are these information > configured via CLI(that is what i think)???If yes then what are the > commands that are used to configure the opaque LSA for TE.Bcoz i went > through the OSPF commands it says little about the configuration of > network information related to TE. Amit, You should not have to configure link type, link ID, and maximum bandwidth in OSPF. This information should be available elsewhere in your system. Normally the reservations are handled dynamically by a separate functional component (e.g., RSVP) and this component passes the per interface reservations information to OSPF as reservations are added or dropped. > > regards > > Amit > > > ------------------------------------------------------------------------ > *Do You Yahoo!?* > Yahoo! - > Official partner of 2002 FIFA World Cup -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 29 11:34:56 2002 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 LAA21446 for ; Wed, 29 May 2002 11:34:56 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00628DC7@cherry.ease.lsoft.com>; Wed, 29 May 2002 11:35:19 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 896302 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 29 May 2002 11:35:19 -0400 Received: from 62.225.183.235 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 29 May 2002 11:25:19 -0400 Received: from g8pbr.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP for OSPF@DISCUSS.MICROSOFT.COM; Wed, 29 May 2002 17:24:17 +0200 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 17:25:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <5D8B3806EB64D311882608000627819705BE42D1@U8PN6.blf01.telekom.de> Date: Wed, 29 May 2002 17:25:17 +0200 Reply-To: Mailing List Sender: Mailing List From: "Wenner, Roger" To: OSPF@DISCUSS.MICROSOFT.COM Unsubscibe From owner-ospf@DISCUSS.MICROSOFT.COM Wed May 29 12:05:43 2002 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 MAA22560 for ; Wed, 29 May 2002 12:05:43 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00628E46@cherry.ease.lsoft.com>; Wed, 29 May 2002 12:06:06 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 896432 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 29 May 2002 12:06:06 -0400 Received: from 216.136.174.191 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Wed, 29 May 2002 12:06:06 -0400 Received: from [211.100.48.72] by web13206.mail.yahoo.com via HTTP; Thu, 30 May 2002 00:06:05 CST MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Message-ID: <20020529160605.74797.qmail@web13206.mail.yahoo.com> Date: Thu, 30 May 2002 00:06:05 +0800 Reply-To: Mailing List Sender: Mailing List From: =?gb2312?q?Nathen=20Wang?= Subject: unsubsribe To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 8bit unsubsribe _________________________________________________________ Do You Yahoo!? ̯¿ªÄãµÄÕÆÐÄ ÈÃÎÒ¿´¿´Äã http://sweepstakes.yahoo.com/2002cnuser From owner-ospf@DISCUSS.MICROSOFT.COM Thu May 30 01:10:13 2002 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 BAA14237 for ; Thu, 30 May 2002 01:10:13 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.0062AA54@cherry.ease.lsoft.com>; Thu, 30 May 2002 1:10:37 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 898946 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 30 May 2002 01:10:37 -0400 Received: from 66.163.169.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 30 May 2002 01:10:36 -0400 Received: from [203.200.20.226] by web21505.mail.yahoo.com via HTTP; Wed, 29 May 2002 22:10:36 PDT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-796939111-1022735436=:87163" Message-ID: <20020530051036.87317.qmail@web21505.mail.yahoo.com> Date: Wed, 29 May 2002 22:10:36 -0700 Reply-To: Mailing List Sender: Mailing List From: Amit Srivastava Subject: Re: OSPF-TE interaction To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3CF4D9D0.8080502@redback.com> --0-796939111-1022735436=:87163 Content-Type: text/plain; charset=us-ascii Hi Acee, Thanks for the help!! Actually you are right the application which wants to use the opaque LSA capability of OSPF should by means of some API or sockets send the aplication specific data to the opaque LSA.The OSPF on receiving the new application data would originate the new opaque LSA. Actually i got this yesterday only after sending the mail. Thanks Once again Regards Amit Acee Lindem wrote: Amit Srivastava wrote: > Hi All, > > Thanks Acee for the help.I have one more doubt regarding the > opaque LSA and TE.The opaque LSA is used to carry some > > network related information.How do you configure your opaque LSA to > carry the network related information such as Link type,Link ID,Max > bandwidth,unreserved Bandwidth,Max reservable bandwidth e.t.c > > Are these information > configured via CLI(that is what i think)???If yes then what are the > commands that are used to configure the opaque LSA for TE.Bcoz i went > through the OSPF commands it says little about the configuration of > network information related to TE. Amit, You should not have to configure link type, link ID, and maximum bandwidth in OSPF. This information should be available elsewhere in your system. Normally the reservations are handled dynamically by a separate functional component (e.g., RSVP) and this component passes the per interface reservations information to OSPF as reservations are added or dropped. > > regards > > Amit > > > ------------------------------------------------------------------------ > *Do You Yahoo!?* > Yahoo! - > Official partner of 2002 FIFA World Cup -- Acee --------------------------------- Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup --0-796939111-1022735436=:87163 Content-Type: text/html; charset=us-ascii

Hi Acee,

        Thanks for the help!! Actually you are right the application which wants to use the opaque LSA capability of OSPF should by means of some API or sockets send the aplication specific data to the opaque LSA.The OSPF on receiving the new application data would originate the new opaque LSA.

                                           Actually i got this yesterday only after sending the mail.

Thanks Once again

Regards

Amit

  Acee Lindem <acee@REDBACK.COM> wrote:

Amit Srivastava wrote:
> Hi All,
>
> Thanks Acee for the help.I have one more doubt regarding the
> opaque LSA and TE.The opaque LSA is used to carry some
>
> network related information.How do you configure your opaque LSA to
> carry the network related information such as Link type,Link ID,Max
> bandwidth,unreserved Bandwidth,Max reservable bandwidth e.t.c
>
> Are these information
> configured via CLI(that is what i think)???If yes then what are the
> commands that are used to configure the opaque LSA for TE.Bcoz i went
> through the OSPF commands it says little about the configuration of
> network information related to TE.

Amit,

You should not have to configure link type, link ID, and maximum bandwidth
in OSPF. This information should be available elsewhere in your system. Normally
the reservations are handled dynamically by a separate functional component
(e.g., RSVP) and this component passes the per interface reservations information
to OSPF as reservations are added or dropped.



>
> regards
>
> Amit
>
>
> ------------------------------------------------------------------------
> *Do You Yahoo!?*
> Yahoo! -
> Official partner of 2002 FIFA World Cup


--
Acee


Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup --0-796939111-1022735436=:87163-- From owner-ospf@DISCUSS.MICROSOFT.COM Thu May 30 05:07:39 2002 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 FAA26958 for ; Thu, 30 May 2002 05:07:39 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0062ADF3@cherry.ease.lsoft.com>; Thu, 30 May 2002 5:08:02 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 899512 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 30 May 2002 05:08:01 -0400 Received: from 203.199.83.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 30 May 2002 04:58:01 -0400 Received: (qmail 5403 invoked by uid 510); 30 May 2002 08:57:09 -0000 Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 30 May 2002 08:57:09 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20020530085709.5402.qmail@webmail25.rediffmail.com> Date: Thu, 30 May 2002 08:57:09 -0000 Reply-To: Mailing List Sender: Mailing List From: manish gupta Subject: Router Disable and Router Id Cahnge To: OSPF@DISCUSS.MICROSOFT.COM Hi all, i have few doubts. 1. if we disable the ospf admin status should we flush out all lsas generated by this router or it's not needed. 2. if we change the router Id of a router than what's need to be done. Regards Manish Gupta _________________________________________________________ Click below to visit monsterindia.com and review jobs in India or Abroad http://monsterindia.rediff.com/jobs From owner-ospf@DISCUSS.MICROSOFT.COM Thu May 30 05:14:06 2002 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 FAA27015 for ; Thu, 30 May 2002 05:14:04 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0062AF17@cherry.ease.lsoft.com>; Thu, 30 May 2002 5:14:28 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 899649 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 30 May 2002 05:14:27 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 30 May 2002 05:14:27 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 May 2002 05:10:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 30 May 2002 05:13:50 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Router Disable and Router Id Cahnge To: OSPF@DISCUSS.MICROSOFT.COM Manish, Check the archives http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0201&L=OSPF&P=R5297 http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0201&L=OSPF&P=R4608 Thanks, Vishwas -----Original Message----- From: manish gupta [mailto:manishgupta7618@REDIFFMAIL.COM] Sent: Thursday, May 30, 2002 2:27 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Router Disable and Router Id Cahnge Hi all, i have few doubts. 1. if we disable the ospf admin status should we flush out all lsas generated by this router or it's not needed. 2. if we change the router Id of a router than what's need to be done. Regards Manish Gupta From owner-ospf@DISCUSS.MICROSOFT.COM Thu May 30 09:22:52 2002 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 JAA03356 for ; Thu, 30 May 2002 09:22:52 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0062B254@cherry.ease.lsoft.com>; Thu, 30 May 2002 9:23:17 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 901627 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 30 May 2002 09:23:17 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 30 May 2002 09:23:16 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA25666 for ; Thu, 30 May 2002 09:23:14 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA09737 for ; Thu, 30 May 2002 09:23:14 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 30 May 2002 09:23:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC557631C9@vie-msgusr-01.dc.fore.com> Date: Thu, 30 May 2002 09:23:13 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Router Disable and Router Id Cahnge To: OSPF@DISCUSS.MICROSOFT.COM Manish, -> 1. if we disable the ospf admin status should we flush out all -> lsas generated by this router or it's not needed. Apart from what Vishwas pointed out, most of the implementations I have seen are not flushing any LSAs in OSPF shutdown/clear. Not flushing normal LSAs upon shutdown won't hurt other routers much, but flushing TE-LSAs are some times required. -> 2. if we change the router Id of a router than what's need to be -> done. RFC2328 page 47 reads... If a router's OSPF Router ID is changed, the router's OSPF software should be restarted before the new Router ID takes effect. In this case the router should flush its self-originated LSAs from the routing domain (see Section 14.1) before restarting, or they will persist for up to MaxAge minutes. -- Venkata From owner-ospf@DISCUSS.MICROSOFT.COM Thu May 30 12:12:06 2002 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 MAA11169 for ; Thu, 30 May 2002 12:12:06 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0062B611@cherry.ease.lsoft.com>; Thu, 30 May 2002 12:12:26 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 902633 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 30 May 2002 12:12:25 -0400 Received: from 192.11.222.163 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 30 May 2002 12:02:25 -0400 Received: from alpo.casc.com (h152-148-10-6.lucent.com [152.148.10.6]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4UG2OQ14250 for ; Thu, 30 May 2002 12:02:24 -0400 (EDT) Received: from lucent.com (tweak [152.148.57.14]) by alpo.casc.com (8.9.1a/8.9.1) with ESMTP id MAA24586 for ; Thu, 30 May 2002 12:02:23 -0400 (EDT) X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3CF64D0E.ABF7355A@lucent.com> Date: Thu, 30 May 2002 12:02:22 -0400 Reply-To: Mailing List Sender: Mailing List From: "Seema Rao (Infosys)" Organization: Infosys Technologies Ltd. Subject: Forwarding address To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Hi, I have a doubt in section 16.4 of RFC 2328. This regarding the forwarding address in the ASE LSA. The following is the extract from the RFC ************ Look up the routing table entry for the destination N. If no entry exists for N, install the AS external path to N, with next hop equal to the list of next hops to the forwarding address, and advertising router equal to ASBR. ************************ Now consider a scenario as follows. rtr1----ethernet hub----rtr2 | |--------rtr3----Dest-N 1] rtr1 and rtr2 are doing OSPF. 2] rtr2 has a static route to reach Dest-N via rtr3. 3] rtr2 is also redistributing this static route into OSPF. 4] The ASE-LSA rxed by rtr1 will have the forwarding address set to rtr3. 5] rtr1 will look up its routing table and will find a direct route to rtr3 network. Now as per the RFC rtr1 will need to install the route to Dest-N, with next hop equal to the list of next hops to the forwarding address. In this case, since the forwarding address is directly connected, is it correct for rtr1 to install a route to Dest-N with next hop none? TIA, Seema From owner-ospf@DISCUSS.MICROSOFT.COM Thu May 30 13:43:59 2002 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 NAA14854 for ; Thu, 30 May 2002 13:43:59 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0062B9EB@cherry.ease.lsoft.com>; Thu, 30 May 2002 13:44:22 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8d) with spool id 903281 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 30 May 2002 13:44:22 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0d) with TCP; Thu, 30 May 2002 13:44:22 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 7ABBC2CDB53 for ; Thu, 30 May 2002 10:44:20 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3CF64D0E.ABF7355A@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3CF66447.8020402@redback.com> Date: Thu, 30 May 2002 13:41:27 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Forwarding address To: OSPF@DISCUSS.MICROSOFT.COM Content-Transfer-Encoding: 7bit Seema Rao (Infosys) wrote: > Hi, > > I have a doubt in section 16.4 of RFC 2328. This regarding the > forwarding address in the ASE LSA. > > The following is the extract from the RFC > > ************ > Look up the routing table entry for the destination N. If no > entry exists for N, install the AS external path to N, with > next hop equal to the list of next hops to the forwarding > address, and advertising router equal to ASBR. > ************************ > > Now consider a scenario as follows. > > rtr1----ethernet hub----rtr2 > | > |--------rtr3----Dest-N > > > 1] rtr1 and rtr2 are doing OSPF. > 2] rtr2 has a static route to reach Dest-N via rtr3. > 3] rtr2 is also redistributing this static route into OSPF. > 4] The ASE-LSA rxed by rtr1 will have the forwarding address set to > rtr3. > 5] rtr1 will look up its routing table and will find a direct route to > rtr3 network. > > Now as per the RFC rtr1 will need to install the route to Dest-N, with > next hop equal to the list of next hops to the forwarding address. In > this case, since the forwarding address is directly connected, is it > correct for rtr1 to install a route to Dest-N with next hop none? No - the next hop will be the rtr3's IP address for the ethernet segment. Without the forwarding address you'd need to take the shortest path to rtr2 (the advertising ASBR) and then rtr3. > > TIA, > Seema > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu May 30 18:00:10 2002 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 SAA20821 for ; Thu, 30 May 2002 18:00:10 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.0062C138@cherry.ease.lsoft.com>; Thu, 30 May 2002 17:55:47 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 874960 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 30 May 2002 17:55:47 -0400 Received: from 207.217.120.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 30 May 2002 17:55:46 -0400 Received: from 209-239-207-65.oak.jps.net ([209.239.207.65] helo=earthlink.net) by goose.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 17DXtY-0003S5-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 30 May 2002 14:55:44 -0700 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: <39469E08BD83D411A3D900204840EC557631C9@vie-msgusr-01.dc.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3CF6A202.CD1FB7D0@earthlink.net> Date: Thu, 30 May 2002 15:04:50 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Router Disable and Router Id Cahnge To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Just two additional notes.. 1) If the router originated DNA (do not age LSAs), then they really need to be flushed. 2) If the router is the DR and their was no BDR configured, the DRothers lsdb synchronization will be lost during the time that reconvergence is re-done with the new router's system ID. So, before the DR is taken down, as a precautionary note, make sure that at least one of the DRothers will be able to take over the duties of the down router, while the router ID is changed. Mitchell Erblich ===================== "Naidu, Venkata" wrote: > > Manish, > > -> 1. if we disable the ospf admin status should we flush out all > -> lsas generated by this router or it's not needed. > > Apart from what Vishwas pointed out, most of the implementations > I have seen are not flushing any LSAs in OSPF shutdown/clear. > Not flushing normal LSAs upon shutdown won't hurt other routers > much, but flushing TE-LSAs are some times required. > > -> 2. if we change the router Id of a router than what's need to be > -> done. > > RFC2328 page 47 reads... > > If a router's OSPF Router ID is changed, the router's OSPF > software > should be restarted before the new Router ID takes effect. In > this case the router should flush its self-originated LSAs from > the routing domain (see Section 14.1) before restarting, or they > will persist for up to MaxAge minutes. > > -- > Venkata From owner-ospf@DISCUSS.MICROSOFT.COM Thu May 30 23:40:35 2002 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 XAA25959 for ; Thu, 30 May 2002 23:40:35 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0062CC45@cherry.ease.lsoft.com>; Thu, 30 May 2002 23:40:58 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 876079 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 30 May 2002 23:40:58 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 30 May 2002 23:40:58 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id A01FCF2C42 for ; Thu, 30 May 2002 20:40:56 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <39469E08BD83D411A3D900204840EC557631C9@vie-msgusr-01.dc.fore.com> <3CF6A202.CD1FB7D0@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3CF6F015.9000605@redback.com> Date: Thu, 30 May 2002 23:37:57 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Router Disable and Router Id Cahnge To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mitchell, I don't completely agree here. Erblichs wrote: > Just two additional notes.. > > 1) If the router originated DNA (do not age LSAs), then > they really need to be flushed. > If you reference section 2.3 of RFC 1793, you'll see that these DNA LSAs will be flushed by the first router that detects they are stale. > 2) If the router is the DR and their was no BDR configured, > the DRothers lsdb synchronization will be lost during the > time that reconvergence is re-done with the new router's > system ID. > So, before the DR is taken down, as a precautionary note, > make sure that at least one of the DRothers will be able to take > over the duties of the down router, while the router ID > is changed. Are you suggesting that one manually reconfigure a DRother router to make be DR eligible? And then reconfigure it to be DR ineligible once the router ID on the DR is changed. This is what would be required since the fact that there is no BDR implies that none of the other routers on the transit network are DR eligible. A better solution might be to design your network so there is always more than one DR eligible router on each transit network. Maybe this is what you are suggesting. > > Mitchell Erblich > ===================== > > > "Naidu, Venkata" wrote: > >>Manish, >> >>-> 1. if we disable the ospf admin status should we flush out all >>-> lsas generated by this router or it's not needed. >> >> Apart from what Vishwas pointed out, most of the implementations >> I have seen are not flushing any LSAs in OSPF shutdown/clear. >> Not flushing normal LSAs upon shutdown won't hurt other routers >> much, but flushing TE-LSAs are some times required. >> >>-> 2. if we change the router Id of a router than what's need to be >>-> done. >> >> RFC2328 page 47 reads... >> >> If a router's OSPF Router ID is changed, the router's OSPF >>software >> should be restarted before the new Router ID takes effect. In >> this case the router should flush its self-originated LSAs from >> the routing domain (see Section 14.1) before restarting, or they >> will persist for up to MaxAge minutes. >> >>-- >>Venkata > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 31 01:40:25 2002 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 BAA28024 for ; Fri, 31 May 2002 01:40:24 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0062CFE9@cherry.ease.lsoft.com>; Fri, 31 May 2002 1:40:03 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 876725 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 31 May 2002 01:40:03 -0400 Received: from 207.217.120.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 31 May 2002 01:40:03 -0400 Received: from 209-239-198-69.oak.jps.net ([209.239.198.69] helo=earthlink.net) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17Df8p-0001uU-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 30 May 2002 22:40:00 -0700 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: <39469E08BD83D411A3D900204840EC557631C9@vie-msgusr-01.dc.fore.com> <3CF6A202.CD1FB7D0@earthlink.net> <3CF6F015.9000605@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3CF70ED4.1A7DE579@earthlink.net> Date: Thu, 30 May 2002 22:49:08 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Router Disable and Router Id Cahnge To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Response... #2 in my opinion is actually more important and yes I believe in having at least a 2nd eligible DR router. But in my scenario, if there was a 2nd eligible router, there should have been a BDR... The problem exists when their isn't a 2nd eligible DR router. #1 The Demand Circuit RFC, sorry folks :-), which specifies DNA LSAs, does specify the removal of non-originated LSAs. However, I have seen instances where the removal of these LSAs is never automaticly flushed from its database and thus really need to be flushed by the originator.. Be safe than sorry. Once the system -ID has changed then the originator is NOT the same and will not "get back to the LSA's originator," (from section 2.4.. And this was done because also in 2.4..."There are times when MaxAge LSAs stay in a router's database for extended intervals: 1) when they are stuck in a retransmission queue on a slow link or 2) when a router is not properly flushing them from its database, due to software bugs. The prolonged existence of these MaxAge LSAs can inhibit the flooding of new instances of the LSA. " Thus, even though this section explicitly states "MaxAge LSAs", I would not rule out DNA LSAs.. So, again it is safer to just attempt to prematurely age ALL originated LSAs.. And then wait for some time incase of some form of delays in the flooding.. Lastly, this item really SHOULD HAVE BEEN MOOT if the router selected it's router-ID as the highest loopback interface or highest IP address. Maybe that's too Cisco like... Mitchell Erblich PS: Been around to long... :-) ================== Acee Lindem wrote: > > Mitchell, > > I don't completely agree here. > > Erblichs wrote: > > Just two additional notes.. > > > > 1) If the router originated DNA (do not age LSAs), then > > they really need to be flushed. > > > > If you reference section 2.3 of RFC 1793, you'll see that these > DNA LSAs will be flushed by the first router that detects > they are stale. > > > 2) If the router is the DR and their was no BDR configured, > > the DRothers lsdb synchronization will be lost during the > > time that reconvergence is re-done with the new router's > > system ID. > > So, before the DR is taken down, as a precautionary note, > > make sure that at least one of the DRothers will be able to take > > over the duties of the down router, while the router ID > > is changed. > > Are you suggesting that one manually reconfigure a DRother router to > make be DR eligible? And then reconfigure it to be > DR ineligible once the router ID on the DR is changed. This is what > would be required since the fact that there is no BDR implies > that none of the other routers on the transit network are DR eligible. > A better solution might be to design your network so there is > always more than one DR eligible router on each transit network. Maybe > this is what you are suggesting. > > > > > Mitchell Erblich > > ===================== > > > > > > "Naidu, Venkata" wrote: > > > >>Manish, > >> > >>-> 1. if we disable the ospf admin status should we flush out all > >>-> lsas generated by this router or it's not needed. > >> > >> Apart from what Vishwas pointed out, most of the implementations > >> I have seen are not flushing any LSAs in OSPF shutdown/clear. > >> Not flushing normal LSAs upon shutdown won't hurt other routers > >> much, but flushing TE-LSAs are some times required. > >> > >>-> 2. if we change the router Id of a router than what's need to be > >>-> done. > >> > >> RFC2328 page 47 reads... > >> > >> If a router's OSPF Router ID is changed, the router's OSPF > >>software > >> should be restarted before the new Router ID takes effect. In > >> this case the router should flush its self-originated LSAs from > >> the routing domain (see Section 14.1) before restarting, or they > >> will persist for up to MaxAge minutes. > >> > >>-- > >>Venkata > > > > > > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 31 05:25:56 2002 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 FAA09651 for ; Fri, 31 May 2002 05:25:55 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0062D370@cherry.ease.lsoft.com>; Fri, 31 May 2002 5:26:12 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 877404 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 31 May 2002 05:26:12 -0400 Received: from 202.54.64.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 31 May 2002 05:26:11 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 15:10:50 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <55E277B99171E041ABF5F4B1C6DDCA06184695@HARITHA> Date: Fri, 31 May 2002 14:58:03 +0530 Reply-To: Mailing List Sender: Mailing List From: "Balaji R (Networking) - CTD, Chennai." Subject: Re: DR & BDR Election To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Yasu, Either I have not fully understood your point or there is a flaw in the calculation. See my explanation below. My understanding of the scenario:- --------------------------------- Before C came in, A was elected as DR and BDR was 0.0.0.0 (as B can't accept DR or BDR responsibilities). Now C comes into picture. What should happen according to RFC:- ----------------------------------- A's calculation - Step 2 would not consider A, as it is already a DR. So, it would elect C as BDR. Step 3 would again elect A as DR. My question:- ----------- So, why would you get the following result? after C 1st (2)(3) - instead of after A 1st (2)(3) C OSPF attempts to keep the existing DR even when higher priority routers come up. So, the DR would lose its status only when a new DR joins (maybe, from a partioned network) or its priority changes to 0. Thanks, Balaji.R. ---------------------------------------------------------------------------- -------- I can't think of a situation where the 2nd calculation of DR (2nd (3)) is necessary ... (I want someone to teach me ...) But obviously 2nd calculation of BDR (2nd (2)) is necessary, see below: # note: RFC2328 9.4 (2) describes BDR calculation, (3) describes DR # calculation new comer +-+-+ +-+-+ +-+-+ |A|1| |B|0| |C|2| +-+-+ +-+-+ +-+-+ | A | | A | | C | +---+ +---+ +---+ | - | | - | | - | +---+ +---+ +---+ after C 1st (2)(3) - after C 2nd (2) A Router B has priority 0 so he is not eligible to become neither DR nor BDR. So before the newcomer comes, the segment's DR is A and BDR is none. Looking into A's calculation, After the newcomer has come and just after 1st calculation of DR/BDR, A has just resigned DR but he's yet eligible to become BDR. If we don't recalculate BDR/DR again, A cannot realize that he can be BDR. From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 31 05:37:31 2002 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 FAA09826 for ; Fri, 31 May 2002 05:37:31 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0062D3BE@cherry.ease.lsoft.com>; Fri, 31 May 2002 5:37:55 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 877444 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 31 May 2002 05:37:55 -0400 Received: from 202.54.64.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 31 May 2002 05:37:55 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 15:22:33 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <55E277B99171E041ABF5F4B1C6DDCA061846BC@HARITHA> Date: Fri, 31 May 2002 15:09:48 +0530 Reply-To: Mailing List Sender: Mailing List From: "Balaji R (Networking) - CTD, Chennai." Subject: Re: DR & BDR Election To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Yasu, Sorry. I failed to notice that C thought itself to be a DR when it joined. I agree with your calculations. Thanks, Balaji.R. -----Original Message----- From: Balaji R (Networking) - CTD, Chennai. [mailto:balajir@CTD.HCLTECH.COM] Sent: Friday, May 31, 2002 2:58 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: DR & BDR Election Yasu, Either I have not fully understood your point or there is a flaw in the calculation. See my explanation below. My understanding of the scenario:- --------------------------------- Before C came in, A was elected as DR and BDR was 0.0.0.0 (as B can't accept DR or BDR responsibilities). Now C comes into picture. What should happen according to RFC:- ----------------------------------- A's calculation - Step 2 would not consider A, as it is already a DR. So, it would elect C as BDR. Step 3 would again elect A as DR. My question:- ----------- So, why would you get the following result? after C 1st (2)(3) - instead of after A 1st (2)(3) C OSPF attempts to keep the existing DR even when higher priority routers come up. So, the DR would lose its status only when a new DR joins (maybe, from a partioned network) or its priority changes to 0. Thanks, Balaji.R. ---------------------------------------------------------------------------- -------- I can't think of a situation where the 2nd calculation of DR (2nd (3)) is necessary ... (I want someone to teach me ...) But obviously 2nd calculation of BDR (2nd (2)) is necessary, see below: # note: RFC2328 9.4 (2) describes BDR calculation, (3) describes DR # calculation new comer +-+-+ +-+-+ +-+-+ |A|1| |B|0| |C|2| +-+-+ +-+-+ +-+-+ | A | | A | | C | +---+ +---+ +---+ | - | | - | | - | +---+ +---+ +---+ after C 1st (2)(3) - after C 2nd (2) A Router B has priority 0 so he is not eligible to become neither DR nor BDR. So before the newcomer comes, the segment's DR is A and BDR is none. Looking into A's calculation, After the newcomer has come and just after 1st calculation of DR/BDR, A has just resigned DR but he's yet eligible to become BDR. If we don't recalculate BDR/DR again, A cannot realize that he can be BDR. From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 31 05:44:02 2002 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 FAA09908 for ; Fri, 31 May 2002 05:44:02 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0062D333@cherry.ease.lsoft.com>; Fri, 31 May 2002 5:44:26 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 877476 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 31 May 2002 05:44:26 -0400 Received: from 202.54.64.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 31 May 2002 05:44:26 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 15:29:04 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <55E277B99171E041ABF5F4B1C6DDCA061846D4@HARITHA> Date: Fri, 31 May 2002 15:16:19 +0530 Reply-To: Mailing List Sender: Mailing List From: "Balaji R (Networking) - CTD, Chennai." Subject: Identification of neighbors in PTP links To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hello, I have a question regarding the association of neighbor data structure with a received hello packet. Section 10.5 states that the neighbor is identified by the source IP address on all types of networks except point-to-point links. In point-to-point links, router ID found in the OSPF header must be used to locate the neighbor. My implementation maintains neighbors on a per-interface basis and knows the interface through which the packet came in. My question is, is there any issue in using the source IP address to locate the neighbor as is done in other types of networks? Are there any implications in doing so? (Actually, on numbered ptp links, we would have to check if the source IP address has changed every time we receive a packet, since we originate router LSA with the neighbor's IP address. I guess we would have to re-originate a new LSA if the neighbor's IP address changed. So, I thought locating the neighbor based on source IP address would hanlde this case more easily.) I can understand that using router ID to identify the neighbor can present problems with respect to multi-homing in multi-access networks. However, I don't fully appreciate why router ID must be used in point-to-point links to identify neighbors. Thanks, Balaji.R. From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 31 06:42:11 2002 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 GAA10690 for ; Fri, 31 May 2002 06:42:10 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0062D305@cherry.ease.lsoft.com>; Fri, 31 May 2002 6:42:35 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 878536 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 31 May 2002 06:42:34 -0400 Received: from 66.163.169.15 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 31 May 2002 06:42:34 -0400 Received: from [203.200.20.226] by web21504.mail.yahoo.com via HTTP; Fri, 31 May 2002 03:42:33 PDT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-816409234-1022841753=:68933" Message-ID: <20020531104233.68987.qmail@web21504.mail.yahoo.com> Date: Fri, 31 May 2002 03:42:33 -0700 Reply-To: Mailing List Sender: Mailing List From: Amit Srivastava Subject: Re: DR & BDR Election To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <55E277B99171E041ABF5F4B1C6DDCA061846BC@HARITHA> Precedence: list --0-816409234-1022841753=:68933 Content-Type: text/plain; charset=us-ascii Hi Guys, My under standing of the concept is that :- Router A is eligible to become DR/BDR but does not declare it self DR nor BDR. Router B is not eligible to become DR and BDR. Router C is eligible to become DR/BDR but does not declare it self DR nor BDR. Now when the first set of computation would result in C(higher priority router to become DR this is due to ,as C would be first selected as BDR and then Promoted to DR).Now even if A is capable of becoming the BDR it will only be able if we recalculate the DR and BDR election process . Am I right in understanding the problem or not??? Regards Amit "Balaji R (Networking) - CTD, Chennai." wrote: Yasu, Sorry. I failed to notice that C thought itself to be a DR when it joined. I agree with your calculations. Thanks, Balaji.R. -----Original Message----- From: Balaji R (Networking) - CTD, Chennai. [mailto:balajir@CTD.HCLTECH.COM] Sent: Friday, May 31, 2002 2:58 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: DR & BDR Election Yasu, Either I have not fully understood your point or there is a flaw in the calculation. See my explanation below. My understanding of the scenario:- --------------------------------- Before C came in, A was elected as DR and BDR was 0.0.0.0 (as B can't accept DR or BDR responsibilities). Now C comes into picture. What should happen according to RFC:- ----------------------------------- A's calculation - Step 2 would not consider A, as it is already a DR. So, it would elect C as BDR. Step 3 would again elect A as DR. My question:- ----------- So, why would you get the following result? after C 1st (2)(3) - instead of after A 1st (2)(3) C OSPF attempts to keep the existing DR even when higher priority routers come up. So, the DR would lose its status only when a new DR joins (maybe, from a partioned network) or its priority changes to 0. Thanks, Balaji.R. ---------------------------------------------------------------------------- -------- I can't think of a situation where the 2nd calculation of DR (2nd (3)) is necessary ... (I want someone to teach me ...) But obviously 2nd calculation of BDR (2nd (2)) is necessary, see below: # note: RFC2328 9.4 (2) describes BDR calculation, (3) describes DR # calculation new comer +-+-+ +-+-+ +-+-+ |A|1| |B|0| |C|2| +-+-+ +-+-+ +-+-+ | A | | A | | C | +---+ +---+ +---+ | - | | - | | - | +---+ +---+ +---+ after C 1st (2)(3) - after C 2nd (2) A Router B has priority 0 so he is not eligible to become neither DR nor BDR. So before the newcomer comes, the segment's DR is A and BDR is none. Looking into A's calculation, After the newcomer has come and just after 1st calculation of DR/BDR, A has just resigned DR but he's yet eligible to become BDR. If we don't recalculate BDR/DR again, A cannot realize that he can be BDR. --------------------------------- Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup --0-816409234-1022841753=:68933 Content-Type: text/html; charset=us-ascii

Hi Guys,

        My under standing of the concept is that :-

       Router A is eligible to become DR/BDR but does not declare it self DR nor BDR.

       Router B is not eligible to become DR and BDR.

       Router C is eligible to become DR/BDR but does not declare it self DR nor BDR.

                        Now when the first set of computation would result in C(higher priority router to become DR this is due to ,as C would be first selected as BDR  and then Promoted to DR).Now even if A is capable of becoming the BDR it will only be able if we recalculate the DR and BDR election process .

Am I right in understanding the problem or not???

Regards

Amit

  "Balaji R (Networking) - CTD, Chennai." <balajir@CTD.HCLTECH.COM> wrote:

Yasu,

Sorry. I failed to notice that C thought itself to be a DR when it joined. I
agree with your calculations.

Thanks,
Balaji.R.

-----Original Message-----
From: Balaji R (Networking) - CTD, Chennai.
[mailto:balajir@CTD.HCLTECH.COM]
Sent: Friday, May 31, 2002 2:58 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: DR & BDR Election


Yasu,

Either I have not fully understood your point or there is a flaw in the
calculation. See my explanation below.


My understanding of the scenario:-
---------------------------------
Before C came in, A was elected as DR and BDR was 0.0.0.0 (as B can't accept
DR or BDR responsibilities). Now C comes into picture.

What should happen according to RFC:-
-----------------------------------
A's calculation - Step 2 would not consider A, as it is already a DR. So,
it would elect C as BDR. Step 3 would again elect A as DR.

My question:-
-----------
So, why would you get the following result?

after C
1st (2)(3) -

instead of

after A
1st (2)(3) C

OSPF attempts to keep the existing DR even when higher priority routers come
up. So, the DR would lose its status only when a new DR joins (maybe, from a
partioned network) or its priority changes to 0.

Thanks,
Balaji.R.

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

I can't think of a situation where the 2nd calculation of DR (2nd (3))
is necessary ... (I want someone to teach me ...)

But obviously 2nd calculation of BDR (2nd (2)) is necessary, see
below:

# note: RFC2328 9.4 (2) describes BDR calculation, (3) describes DR
# calculation

new comer
+-+-+ +-+-+ +-+-+
|A|1| |B|0| |C|2|
+-+-+ +-+-+ +-+-+
| A | | A | | C |
+---+ +---+ +---+
| - | | - | | - |
+---+ +---+ +---+

after C
1st (2)(3 ) -

after C
2nd (2) A

Router B has priority 0 so he is not eligible to become neither DR nor
BDR. So before the newcomer comes, the segment's DR is A and BDR is
none.

Looking into A's calculation, After the newcomer has come and just
after 1st calculation of DR/BDR, A has just resigned DR but he's
yet eligible to become BDR. If we don't recalculate BDR/DR again,
A cannot realize that he can be BDR.


Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup --0-816409234-1022841753=:68933-- From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 31 06:55:00 2002 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 GAA10821 for ; Fri, 31 May 2002 06:55:00 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0062D4AB@cherry.ease.lsoft.com>; Fri, 31 May 2002 6:55:25 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 878576 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 31 May 2002 06:55:25 -0400 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 31 May 2002 06:45:25 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0062D44E@cherry.ease.lsoft.com>; Fri, 31 May 2002 6:45:25 -0400 Message-ID: Date: Fri, 31 May 2002 06:45:25 -0400 Reply-To: Mailing List Sender: Mailing List From: Arnaud Lemaire Subject: OSPF checksum error between two differents contructors routers To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, i have got a problem with a multi-constructor network : Here is my question : Two equipments are connected in OSPF, one send LSA update with a 0xFFFF checksum the second router drop the packet and said "checksum eror, should be zero". RFC 2328 says : "a checksum should never be zero". RFC 905 about Fletcher Checksum says :" one's complement arithmetic in which if any of the variables has the value minus zero (i.e. 255 "or OxFFFF) it shall be regarded as though it was plus zero (i.e. 0). Can we conclude wich equipement is wrong : the one which sent the FFFF checksum or the one which said should be zero ? What i understand is that sending an FFFF checksum is like sending a 0 cehcksum and it is an wrong value. Thanx for helping, From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 31 07:01:03 2002 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 HAA10979 for ; Fri, 31 May 2002 07:01:03 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0062D51D@cherry.ease.lsoft.com>; Fri, 31 May 2002 7:01:28 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 878635 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 31 May 2002 07:01:27 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 31 May 2002 07:01:27 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 06:57:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 31 May 2002 07:00:58 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPF checksum error between two differents contructors router s To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Arnaud, You are right. The Fletchers checksum algorithm never gives a checksum value of 0. The router expecting a checksum of 0 is the one thats probably wrong. Thanks, Vishwas -----Original Message----- From: Arnaud Lemaire [mailto:lemair_a@YAHOO.COM] Sent: Friday, May 31, 2002 4:15 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: OSPF checksum error between two differents contructors routers Hi, i have got a problem with a multi-constructor network : Here is my question : Two equipments are connected in OSPF, one send LSA update with a 0xFFFF checksum the second router drop the packet and said "checksum eror, should be zero". RFC 2328 says : "a checksum should never be zero". RFC 905 about Fletcher Checksum says :" one's complement arithmetic in which if any of the variables has the value minus zero (i.e. 255 "or OxFFFF) it shall be regarded as though it was plus zero (i.e. 0). Can we conclude wich equipement is wrong : the one which sent the FFFF checksum or the one which said should be zero ? What i understand is that sending an FFFF checksum is like sending a 0 cehcksum and it is an wrong value. Thanx for helping, From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 31 07:10:32 2002 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 HAA11169 for ; Fri, 31 May 2002 07:10:31 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0062D4D0@cherry.ease.lsoft.com>; Fri, 31 May 2002 7:10:56 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 878673 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 31 May 2002 07:10:55 -0400 Received: from 66.163.169.58 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 31 May 2002 07:10:55 -0400 Received: from [203.200.20.226] by web21509.mail.yahoo.com via HTTP; Fri, 31 May 2002 04:10:42 PDT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1966296999-1022843442=:70678" Message-ID: <20020531111042.71028.qmail@web21509.mail.yahoo.com> Date: Fri, 31 May 2002 04:10:42 -0700 Reply-To: Mailing List Sender: Mailing List From: Amit Srivastava Subject: Re: Identification of neighbors in PTP links To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <55E277B99171E041ABF5F4B1C6DDCA061846D4@HARITHA> Precedence: list --0-1966296999-1022843442=:70678 Content-Type: text/plain; charset=us-ascii Hi Balaji R You can use ip source address to identify the neighbour stucture for numbered point-to-point link but for un-numbered u will have to use Router id only so to make consistence it is better to use router id as the unique key. regards Amit "Balaji R (Networking) - CTD, Chennai." wrote: Hello, I have a question regarding the association of neighbor data structure with a received hello packet. Section 10.5 states that the neighbor is identified by the source IP address on all types of networks except point-to-point links. In point-to-point links, router ID found in the OSPF header must be used to locate the neighbor. My implementation maintains neighbors on a per-interface basis and knows the interface through which the packet came in. My question is, is there any issue in using the source IP address to locate the neighbor as is done in other types of networks? Are there any implications in doing so? (Actually, on numbered ptp links, we would have to check if the source IP address has changed every time we receive a packet, since we originate router LSA with the neighbor's IP address. I guess we would have to re-originate a new LSA if the neighbor's IP address changed. So, I thought locating the neighbor based on source IP address would hanlde this case more easily.) I can understand that using router ID to identify the neighbor can present problems with respect to multi-homing in multi-access networks. However, I don't fully appreciate why router ID must be used in point-to-point links to identify neighbors. Thanks, Balaji.R. --------------------------------- Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup --0-1966296999-1022843442=:70678 Content-Type: text/html; charset=us-ascii

Hi Balaji R

You can use ip source address to identify the neighbour stucture for numbered point-to-point link but for un-numbered u will have to use

Router id only so to make consistence it is better to use router id as the unique key.

regards

Amit

  "Balaji R (Networking) - CTD, Chennai." <balajir@CTD.HCLTECH.COM> wrote:

Hello,

I have a question regarding the association of neighbor data structure with
a received hello packet.

Section 10.5 states that the neighbor is identified by the source IP address
on all types of networks except point-to-point links. In point-to-point
links, router ID found in the OSPF header must be used to locate the
neighbor.

My implementation maintains neighbors on a per-interface basis and knows the
interface through which the packet came in. My question is, is there any
issue in using the source IP address to locate the neighbor as is done in
other types of networks? Are there any implications in doing so? (Actually,
on numbered ptp links, we would have to check if the source IP address has
changed every time we receive a packet, since we originate router LSA with
the neighbor's IP address. I guess we would have to re-originate a new LSA
if the neighbor's IP address changed. So, I thought locating the neighbor
based on source IP address would hanlde this case more easily.)

I can understand that using router ID to identify the neighbor can present
problems with respect to multi-homing in multi-access networks. However, I
don't fully appreciate why router ID must be used in point-to-point links to
identify neighbors.

Thanks,
Balaji.R.


Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup --0-1966296999-1022843442=:70678-- From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 31 08:04:27 2002 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 IAA12800 for ; Fri, 31 May 2002 08:04:27 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0062D55B@cherry.ease.lsoft.com>; Fri, 31 May 2002 8:04:52 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 878888 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 31 May 2002 08:04:51 -0400 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 31 May 2002 08:04:51 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0062D50D@cherry.ease.lsoft.com>; Fri, 31 May 2002 8:04:51 -0400 Message-ID: Date: Fri, 31 May 2002 08:04:51 -0400 Reply-To: Mailing List Sender: Mailing List From: Arnaud Lemaire Subject: Re: OSPF checksum error between two differents contructors router s To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Thanks Vishwas, but i think i made an error: Fletcher checksum is only used in LS checksum. the problem i got is concerning OSPF'header checksum. wich use another way of calculation : Checksum (RFC2328) The standard IP 16-bit one's complement checksum of the entire OSPF packet, excluding the 64-bit authentication field. This checksum is calculated as part of the appropriate authentication procedure; for some OSPF authentication types, the checksum calculation is omitted. See Section D.4 one told me a one's complement could never be FFFF (maths theory). so an OSPF checksum could never be FFFF. Anybody do confirm that ? regards, From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 31 08:28:03 2002 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 IAA13447 for ; Fri, 31 May 2002 08:28:03 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0062D42E@cherry.ease.lsoft.com>; Fri, 31 May 2002 8:28:28 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 878987 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 31 May 2002 08:28:28 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 31 May 2002 08:28:28 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 0B05F1DCC7C for ; Fri, 31 May 2002 05:28:27 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <39469E08BD83D411A3D900204840EC557631C9@vie-msgusr-01.dc.fore.com> <3CF6A202.CD1FB7D0@earthlink.net> <3CF6F015.9000605@redback.com> <3CF70ED4.1A7DE579@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3CF76BB3.4080807@redback.com> Date: Fri, 31 May 2002 08:25:23 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Router Disable and Router Id Cahnge To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Erblichs wrote: > Response... > > #2 in my opinion is actually more important and yes I believe in > having at least a 2nd eligible DR router. But in my scenario, if > there was a 2nd eligible router, there should have been a BDR... > The problem exists when their isn't a 2nd eligible DR router. > > #1 The Demand Circuit RFC, sorry folks :-), which specifies > DNA LSAs, does specify the removal of non-originated LSAs. > However, I have seen instances where the removal of these > LSAs is never automaticly flushed from its database > and thus really need to be flushed by the originator.. Well this is a bug. > > Be safe than sorry. Once the system -ID > has changed then the originator is NOT the same and will > not "get back to the LSA's originator," (from section 2.4.. > > And this was done because also in 2.4..."There are times when MaxAge > LSAs stay in a router's database for extended intervals: 1) when > they are stuck in a retransmission queue on a slow link or 2) when > a router is not properly flushing them from its database, due to > software bugs. The prolonged existence of these MaxAge LSAs can > inhibit the flooding of new instances of the LSA. " > > Thus, even though this section explicitly states "MaxAge LSAs", I > would not rule out DNA LSAs.. So, again it is safer to just attempt > to prematurely age ALL originated LSAs.. And then wait for some > time incase of some form of delays in the flooding.. > > > Lastly, this item really SHOULD HAVE BEEN MOOT if the router > selected it's router-ID as the highest loopback interface > or highest IP address. Maybe that's too Cisco like... An OSPF router has to handle router ID changes no matter what algorithm is used to select the default router ID. Most OSPF implementations allow one to explicitly specify and dynamically change the router-id (in fact, RFC 2328 lists this as a configuration parameter in appendix C.1). > > Mitchell Erblich > PS: Been around to long... :-) > ================== > > > Acee Lindem wrote: > >>Mitchell, >> >>I don't completely agree here. >> >>Erblichs wrote: >> >>>Just two additional notes.. >>> >>>1) If the router originated DNA (do not age LSAs), then >>>they really need to be flushed. >>> >> >>If you reference section 2.3 of RFC 1793, you'll see that these >>DNA LSAs will be flushed by the first router that detects >>they are stale. >> >> >>>2) If the router is the DR and their was no BDR configured, >>>the DRothers lsdb synchronization will be lost during the >>>time that reconvergence is re-done with the new router's >>>system ID. >>> So, before the DR is taken down, as a precautionary note, >>>make sure that at least one of the DRothers will be able to take >>>over the duties of the down router, while the router ID >>>is changed. >> >>Are you suggesting that one manually reconfigure a DRother router to >>make be DR eligible? And then reconfigure it to be >>DR ineligible once the router ID on the DR is changed. This is what >>would be required since the fact that there is no BDR implies >>that none of the other routers on the transit network are DR eligible. >>A better solution might be to design your network so there is >>always more than one DR eligible router on each transit network. Maybe >>this is what you are suggesting. >> >> >>> Mitchell Erblich >>> ===================== >>> >>> >>>"Naidu, Venkata" wrote: >>> >>> >>>>Manish, >>>> >>>>-> 1. if we disable the ospf admin status should we flush out all >>>>-> lsas generated by this router or it's not needed. >>>> >>>> Apart from what Vishwas pointed out, most of the implementations >>>> I have seen are not flushing any LSAs in OSPF shutdown/clear. >>>> Not flushing normal LSAs upon shutdown won't hurt other routers >>>> much, but flushing TE-LSAs are some times required. >>>> >>>>-> 2. if we change the router Id of a router than what's need to be >>>>-> done. >>>> >>>> RFC2328 page 47 reads... >>>> >>>> If a router's OSPF Router ID is changed, the router's OSPF >>>>software >>>> should be restarted before the new Router ID takes effect. In >>>> this case the router should flush its self-originated LSAs from >>>> the routing domain (see Section 14.1) before restarting, or they >>>> will persist for up to MaxAge minutes. >>>> >>>>-- >>>>Venkata >>> >>> >>-- >>Acee > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 31 08:46:51 2002 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 IAA14184 for ; Fri, 31 May 2002 08:46:51 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0062D5A6@cherry.ease.lsoft.com>; Fri, 31 May 2002 8:47:16 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 879076 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 31 May 2002 08:47:16 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 31 May 2002 08:47:16 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 08:42:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 31 May 2002 08:47:00 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPF checksum error between two differents contructors router s To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Arnaud, The LSUpdate packet uses a 16 bits ones complement checksum, the LSA use the Fletchers checksum. I tried and see the algorithm in RFC1071 which gives it as in 6 { /* Compute Internet Checksum for "count" bytes * beginning at location "addr". */ register long sum = 0; while( count > 1 ) { /* This is the inner loop */ sum += * (unsigned short) addr++; count -= 2; } /* Add left-over byte, if any */ if( count > 0 ) sum += * (unsigned char *) addr; /* Fold 32-bit sum to 16 bits */ while (sum>>16) sum = (sum & 0xffff) + (sum >> 16); checksum = ~sum; } As value of sum cannot be 0(unless the entire contents of the packet is 0) because every overflow is added back, the value of checksum cannot be 0xffff(complement of (uns16) 0). Thanks, Vishwas -----Original Message----- From: Arnaud Lemaire [mailto:lemair_a@YAHOO.COM] Sent: Friday, May 31, 2002 5:35 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPF checksum error between two differents contructors router s Thanks Vishwas, but i think i made an error: Fletcher checksum is only used in LS checksum. the problem i got is concerning OSPF'header checksum. wich use another way of calculation : Checksum (RFC2328) The standard IP 16-bit one's complement checksum of the entire OSPF packet, excluding the 64-bit authentication field. This checksum is calculated as part of the appropriate authentication procedure; for some OSPF authentication types, the checksum calculation is omitted. See Section D.4 one told me a one's complement could never be FFFF (maths theory). so an OSPF checksum could never be FFFF. Anybody do confirm that ? regards, From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 31 09:13:14 2002 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 JAA15113 for ; Fri, 31 May 2002 09:13:13 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0062D747@cherry.ease.lsoft.com>; Fri, 31 May 2002 9:13:38 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 879249 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 31 May 2002 09:13:38 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 31 May 2002 09:13:37 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 8EFD21B8EEF for ; Fri, 31 May 2002 06:13:36 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <55E277B99171E041ABF5F4B1C6DDCA061846D4@HARITHA> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3CF77648.9040303@redback.com> Date: Fri, 31 May 2002 09:10:32 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Identification of neighbors in PTP links To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Balaji R (Networking) - CTD, Chennai. wrote: > Hello, > > I have a question regarding the association of neighbor data structure with > a received hello packet. > > Section 10.5 states that the neighbor is identified by the source IP address > on all types of networks except point-to-point links. In point-to-point > links, router ID found in the OSPF header must be used to locate the > neighbor. > > My implementation maintains neighbors on a per-interface basis and knows the > interface through which the packet came in. My question is, is there any > issue in using the source IP address to locate the neighbor as is done in > other types of networks? Are there any implications in doing so? (Actually, > on numbered ptp links, we would have to check if the source IP address has > changed every time we receive a packet, since we originate router LSA with > the neighbor's IP address. I guess we would have to re-originate a new LSA > if the neighbor's IP address changed. So, I thought locating the neighbor > based on source IP address would hanlde this case more easily.) For P2P links, the link data in your router link contains your interface IP address - not your neighbors. You should not have to originate a new router LSA if your neighbor's IP address changes. > > I can understand that using router ID to identify the neighbor can present > problems with respect to multi-homing in multi-access networks. However, I > don't fully appreciate why router ID must be used in point-to-point links to > identify neighbors. > > Thanks, > Balaji.R. > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 31 09:33:29 2002 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 JAA15884 for ; Fri, 31 May 2002 09:33:28 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0062D912@cherry.ease.lsoft.com>; Fri, 31 May 2002 9:33:54 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 879441 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 31 May 2002 09:33:53 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 31 May 2002 09:33:53 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA13868 for ; Fri, 31 May 2002 09:33:47 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA16922 for ; Fri, 31 May 2002 09:33:47 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 31 May 2002 09:33:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC557631CE@vie-msgusr-01.dc.fore.com> Date: Fri, 31 May 2002 09:33:46 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Identification of neighbors in PTP links To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Balaji, Acee, -> (Actually, on numbered ptp links, we would have to check if the -> source IP address has -> > changed every time we receive a packet, since we originate -> router LSA with -> > the neighbor's IP address. I guess we would have to -> re-originate a new LSA -> > if the neighbor's IP address changed. So, I thought -> locating the neighbor -> > based on source IP address would hanlde this case more easily.) -> -> For P2P links, the link data in your router link contains -> your interface IP -> address - not your neighbors. You should not have to -> originate a new router -> LSA if your neighbor's IP address changes. In Option 1, P2P stub link represents neighbor IP address and not local interface IP address. More over, the neighbor IP address is used as the next hop for all the SPF routes through the neighbor router. Though, next hop IP address is not required for P2P links (numbered or unnumbered) - because the L3->L2 address resolution won't arise when forwarding packets in case of P2P links, most of the implementations still uses neighbor IP address as the next hop for all those routes. For all the above reason, the neighbor IP address change might results in re-originating and/or re-computing SPF. -- Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 31 09:46:11 2002 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 JAA16447 for ; Fri, 31 May 2002 09:46:10 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0062D83D@cherry.ease.lsoft.com>; Fri, 31 May 2002 9:46:35 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 879540 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 31 May 2002 09:46:35 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 31 May 2002 09:46:35 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 9D0951531CD for ; Fri, 31 May 2002 06:46:33 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <39469E08BD83D411A3D900204840EC557631CE@vie-msgusr-01.dc.fore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3CF77E01.2090606@redback.com> Date: Fri, 31 May 2002 09:43:29 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Identification of neighbors in PTP links To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Naidu, Venkata wrote: > Balaji, Acee, > > -> (Actually, on numbered ptp links, we would have to check if the > -> source IP address has > -> > changed every time we receive a packet, since we originate > -> router LSA with > -> > the neighbor's IP address. I guess we would have to > -> re-originate a new LSA > -> > if the neighbor's IP address changed. So, I thought > -> locating the neighbor > -> > based on source IP address would hanlde this case more easily.) > -> > -> For P2P links, the link data in your router link contains > -> your interface IP > -> address - not your neighbors. You should not have to > -> originate a new router > -> LSA if your neighbor's IP address changes. > > In Option 1, P2P stub link represents neighbor IP address > and not local interface IP address. I guess I didn't even support this option this time around since option 2 results in fewer routes in the OSPF routing domain. > > More over, the neighbor IP address is used as the next > hop for all the SPF routes through the neighbor router. > Though, next hop IP address is not required for P2P links > (numbered or unnumbered) - because the L3->L2 address > resolution won't arise when forwarding packets in case of > P2P links, most of the implementations still uses neighbor > IP address as the next hop for all those routes. > > For all the above reason, the neighbor IP address change > might results in re-originating and/or re-computing SPF. The router whose IP address changes should be responsible for re-originating their LSA. This will result in SPF computations on other routers in the OSPF area. If you perform an SPF when the IP source address changes you'll end doing another one when you receive the changed LSA. > > -- > Venkata. > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 31 13:47:44 2002 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 NAA24054 for ; Fri, 31 May 2002 13:47:44 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.0062E010@cherry.ease.lsoft.com>; Fri, 31 May 2002 13:48:06 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 880407 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 31 May 2002 13:48:06 -0400 Received: from 64.12.136.164 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 31 May 2002 13:38:06 -0400 Received: from Jjsyed@aol.com by imo-m09.mx.aol.com (mail_out_v32.5.) id 7.93.1ddfc01c (16110) for ; Fri, 31 May 2002 13:38:00 -0400 (EDT) Received: from aol.com (mow-m20.webmail.aol.com [64.12.180.136]) by air-id12.mx.aol.com (v86.12) with ESMTP id MAILINID122-0531133800; Fri, 31 May 2002 13:38:00 -0400 X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <1EE12DA8.19033DA9.0004D071@aol.com> Date: Fri, 31 May 2002 13:38:49 -0400 Reply-To: Mailing List Sender: Mailing List From: Javed Syed Subject: Routing it set To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit Hi, I have question on " sho ip ospf database " output command. One of the line from the output has a routing bit set. Can somebody explain me the importance of this field. I have not seen this line when I do above command on ASBR router. I think I know the answer but still would like to have good explanation from this alias. regards From owner-ospf@DISCUSS.MICROSOFT.COM Fri May 31 18:51:56 2002 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 SAA06272 for ; Fri, 31 May 2002 18:51:56 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.0062ED6B@cherry.ease.lsoft.com>; Fri, 31 May 2002 18:52:20 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 881579 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 31 May 2002 18:52:20 -0400 Received: from 207.217.120.122 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 31 May 2002 18:52:20 -0400 Received: from 209-239-201-19.oak.jps.net ([209.239.201.19] helo=earthlink.net) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17DvFo-0005Cx-00 for ospf@discuss.microsoft.com; Fri, 31 May 2002 15:52:18 -0700 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3CF800C7.6DC6B256@earthlink.net> Date: Fri, 31 May 2002 16:01:27 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Dynamic Priority setting for DR election To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Group, Has anyone heard of a router's priority selection based based on incoming values of the hello packet's priority field? Would their be an experimental draft during the past years that explictly or implicitly state this type of feature? Basicly 0) Assuming that a DR and BDR were not already elected. 1) delaying hello xmits during bootup for a period not to exceed or equal waittime, 2) Identifing a max of the priorities per DR capable interface, 3) Then transmitting hello packets with a higher priority than the calculated max and dynamically setting that value.. This would make it the DR, unless another router's priority was set to the max.. Yes, I believe this would be a non-standard functionality, and should require the formal setting of a CLI command to enable this type of feature. And yes, their could be issues with two or more routers configured this way. Mitchell Erblich