Re: DR election

Acee Lindem <acee@CISCO.COM> Wed, 04 May 2005 14:07 UTC

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 KAA11241 for <ospf-archive@LISTS.IETF.ORG>; Wed, 4 May 2005 10:07:12 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.010332C2@cherry.ease.lsoft.com>; Wed, 4 May 2005 10:07:12 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 69270091 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 4 May 2005 10:07:11 -0400
Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 4 May 2005 10:07:11 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 04 May 2005 10:07:11 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j44E74RU028212 for <OSPF@PEACH.EASE.LSOFT.COM>; Wed, 4 May 2005 10:07:08 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 May 2005 10:07:03 -0400
Received: from [10.82.241.73] ([10.82.241.73]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 May 2005 10:07:03 -0400
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <7F17177AC9AC2F4CB4A1A33C936D038D7E2275@nevismail01.pune.nevisnetworks.com> <4277747D.5040101@cisco.com> <4277F11C.91DCF5C6@earthlink.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 May 2005 14:07:03.0110 (UTC) FILETIME=[8BE0E660:01C550B2]
Message-ID: <4278D706.1040906@cisco.com>
Date: Wed, 04 May 2005 10:07:02 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@CISCO.COM>
Subject: Re: DR election
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <4277F11C.91DCF5C6@earthlink.net>
Precedence: list
Content-Transfer-Encoding: 7bit

Hi Mitchell,
I don't see this as a strong requirement since one could always
configure a router priority of 0 on those routers which are not
able to hande the DR task. We've gotten along without this
DR preemption feature for this long and to the best of my knowledge
there aren't even any proprietary extensions to do this. This would
indicate to me that there is not a strong requirement.

As always, you are welcome to make such a proposal in
an individual draft for consideration by the WG.

Thanks,
Acee

Erblichs wrote:

>Acee,
>
>	Thanks' I just don't have the RFCs memorized
>	to what section says what and yes, trying to solve
>	a few gray issues to satisfy customers so I don't
>	monitor this discussion on a daily basis.
>
>	HOWEVER, Sorry,, I have to say more..
>
>	The resulting re-election of the DR SHOULD NOT
>	cause a major "churn", yes a minor churn.
>
>	The reason is that if the re-election is done,
>	their is no gurantee of a change in the DR, unless
>	my suggestion of a delayed hello.
>
>	If a new DR is elected, the previous DR would more
>	than likely become the BDR or the BDR would stay
>	the same. Thus, at least 1/2 of the full adjs
>	are expected to stay the same.
>
>	If this was an actual area combining event
>	then the re-synch of the LSDB is necessary,
>	else most of the LSDB updates would be on a 1
>	way basis and only with the 1st full neighbor
>	LSDB exchange.
>
>	Yes, a minor churn, but if the new router has
>	significantly higher capabilities than the present
>	DR, I would see little reason not to at least
>	consider this as a feature.
>
>	Mitchell Erblich
>	----------------
>
>
>Acee Lindem wrote:
>  
>
>>All,
>>
>>This has been discussed before on this list and you could search
>>the archives to get all the gritty details. In summary:
>>
>>   - The protocol attempts to avoid BDR/DR churn and the BDR/DR election
>>      gives the current BDR/DR precedence. The reason is obvious - you
>>want to
>>     avoid the network overhead/convergence delay of bringing up
>>     adjacencies with the new BDR/DR as well as  the
>>overhead/convergence delay
>>     of flooding and recalculating the intra-area route table with a new
>>DR's
>>     network-LSA.
>>   - While it is not part of the protocol specification, an
>>implementation could
>>      force a BDR/DR election by ignoring the fact that there is a
>>BDR/DR and
>>     asserting themselves as BDR/DR. They would cause a NeighborChange
>>     event (Section 9.2, RFC 2328) causing RFC 2328 compliant
>>implementations
>>     to perform a BDR/DR election.
>>
>>Thanks,
>>Acee
>>
>>Naresh Paliwal wrote:
>>
>>    
>>
>>>Erblich,
>>>
>>>I didn't get your reply, can u please give the references of the idea.
>>>
>>>I mean to ask, is it possible to enforce DR/BDR-election without
>>>changing configuration of existing DR/BDR?
>>>
>>>Regards
>>>-Naresh
>>>
>>>
>>>-----Original Message-----
>>>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of
>>>Erblichs
>>>Sent: Monday, May 02, 2005 10:07 PM
>>>To: OSPF@PEACH.EASE.LSOFT.COM
>>>Subject: Re: DR election
>>>
>>>Yes and no,
>>>
>>>If a router "really wants to be the DR", the protocol does
>>>allow this through a back door. The router must act like
>>>it was already also elected as the DR. This can happen in
>>>what was a split area. By coming up later, the later router
>>>SHOULD know the other's priority and router-id. It can then
>>>boost its broadcasted priority and/or its router-id to gurantee
>>>re-election.
>>>
>>>Mitchell Erblich
>>>----------------------
>>>
>>>
>>>"Krishnan, Vijay G." wrote:
>>>
>>>
>>>      
>>>
>>>>The first router does not become the DR immediately. It waits for its
>>>>configurable "wait timer" to expire, before electing the DR. Others
>>>>
>>>>
>>>>        
>>>>
>>>routers
>>>
>>>
>>>      
>>>
>>>>could come up during this time. Once the DR is elected, addition of
>>>>
>>>>
>>>>        
>>>>
>>>new
>>>
>>>
>>>      
>>>
>>>>routers would not change the DR. This will reduce the instability due
>>>>
>>>>
>>>>        
>>>>
>>>to the
>>>
>>>
>>>      
>>>
>>>>DR changes.
>>>>
>>>>regards
>>>>Vijay
>>>>
>>>>-----Original Message-----
>>>>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Ilan
>>>>Bercovich
>>>>Sent: Monday, May 02, 2005 11:51 AM
>>>>To: OSPF@PEACH.EASE.LSOFT.COM
>>>>Subject: DR election
>>>>
>>>>Hello
>>>>If all routers accept the DR regardless of their Router Priority,
>>>>It means that actually the first active router on the LAN is the DR.
>>>>Isn't this makes the Router Priority parameter somewhat irrelevant?
>>>>(In RSTP for instance, when priority is changed - network is
>>>>re-calculated).
>>>>Ilan
>>>>
>>>>
>>>>        
>>>>
>>>
>>>      
>>>
>
>  
>