Subject: Re: IS-IS DIS Election Algorithm -- do we want to modify it?

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Wed, 24 Feb 1999 22:58:19 -0500 (EST)

>>Radia,

>>If an implementation wanted to do this unilaterally, why couldn't it?

>>Do we need to spec this?  
>>Does it change the protocol?
>>Do we have any responsibilities here?

>>Tony

An implementation can do this unilaterally and wouldn't mess anything up.
But it might be a good idea to write it down as a recommendation, and I'd
be curious if people have had customers unhappy with the deterministic
behavior and might prefer being able to select "sticky" behavior if they want.

Radia

---

From: Henk Smit <[email-masked]>
Date: Thu, 25 Feb 1999 13:25:58 +0100 (MET)

> behavior and might prefer being able to select "sticky" behavior if they

  Why a recommendation ?
 I have never heard any customers mention this as a problem.
 When I used to do support, I have never seen problems with the deterministic
 behaviour. IMHO the DIS election is not a relevant issue at all.

  The only place where I can remember I've seen customers worry about who
 the DIS is, is when they use the OSPF broadcast model over (non-fully
 meshed) NBMA clouds. ;-)  IMHO NBMA is a place where you really don't
 want to use the broadcast model.

     Henk.

---

From: Tony Staw <[email-masked]>
Date: Thu, 25 Feb 1999 15:35:33 -0800

> behavior and might prefer being able to select "sticky" behavior if they want.
We certainly had problems with the IS-IS behaviour in the early days
of NLSP deployment - which is why we changed the way NLSP behaves.  The main
problem is when a new router comes up and becomes the DR, you have several
seconds of lost connectivity through the LAN, as the new DR acquires the
link state database.

I do think it ought to be written down in a spec as at least a recommendation
or an option.   Arguably, it might be seen as a violation of the spec for
a system to arbitrarily change the value of its DR priority from the one
that it had been configured with.

Tony Staw