Re: DR election

[Erblichs <[e-mail]>]

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:[e-mail]] On Behalf Of
> >Erblichs
> >Sent: Monday, May 02, 2005 10:07 PM
> >To: [e-mail]
> >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:[e-mail]]On Behalf Of Ilan
> >>Bercovich
> >>Sent: Monday, May 02, 2005 11:51 AM
> >>To: [e-mail]
> >>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
> >>
> >>
> >
> >
> >