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 12:53:13 -0500 (EST)

The question on DR election reminded me...

This is a suggestion to make a small, backward compatible change
to IS-IS so that the election protocol can behave either like
the current IS-IS, like OSPF, or some combination as determined by the user.

The IS-IS election is "deterministic", meaning the same
router will always be elected. The OSPF is "sticky", meaning
that once you are DR, nobody else will take over.

You can find advocates for either way of doing it. The OSPF
way has the advantage that if the highest priority (numerically
lowest...whatever) router is going up and down like a yo-yo, it
is highly disruptive to have a deterministic algorithm, since the
sick router will keep taking over as DR. The "sticky" advocates basically
say "leave well enough alone", i.e., if there's someone who's doing
the job, don't change things.

But there might be some reason to prefer one router over the other, which
is why some people prefer a deterministic algorithm.

NLSP (an IPX specific variant of IS-IS) had the DR change its priority
by 20 once it was DR for a minute. If you wanted the OSPF behavior (where
nobody would usurp DR-ness from an alive DR), you just made sure that
everyone's configured priority was within 20 of each other. If you
wanted the IS-IS way where every router had a distinct priority and
would take over from any other, then you just set their priorities to
be at least 20 different from each other router. If you wanted some
hibrid (where there was a set of routers that you preferred to have
the DR come from, but you wanted it to be sticky within that set), then
you could set those routers to have priority at least 21 more than
other routers, and within 20 of each other so that within that set
it would be sticky.

With this change there are no additional parameters to set. Any router
can do this and interoperate with routers that don't do this.

It might be more intuitive to have an extra parameter, either two priorities
(one for before election, and one for after being elected), or a priority
and an "election increment". But I couldn't think of any case that
couldn't be handled by the simple "add 20" rule.

Radia

---

From: Tony Li <[email-masked]>
Date: Wed, 24 Feb 1999 18:38:24 -0800 (PST)

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

|  This is a suggestion to make a small, backward compatible change
|  to IS-IS so that the election protocol can behave either like
|  the current IS-IS, like OSPF, or some combination as determined by the user.
|  
|  The IS-IS election is "deterministic", meaning the same
|  router will always be elected. The OSPF is "sticky", meaning
|  that once you are DR, nobody else will take over.
|  
|  You can find advocates for either way of doing it. The OSPF
|  way has the advantage that if the highest priority (numerically
|  lowest...whatever) router is going up and down like a yo-yo, it
|  is highly disruptive to have a deterministic algorithm, since the
|  sick router will keep taking over as DR. The "sticky" advocates basically
|  say "leave well enough alone", i.e., if there's someone who's doing
|  the job, don't change things.
|  
|  But there might be some reason to prefer one router over the other, which
|  is why some people prefer a deterministic algorithm.
|  
|  NLSP (an IPX specific variant of IS-IS) had the DR change its priority
|  by 20 once it was DR for a minute. If you wanted the OSPF behavior (where
|  nobody would usurp DR-ness from an alive DR), you just made sure that
|  everyone's configured priority was within 20 of each other. If you
|  wanted the IS-IS way where every router had a distinct priority and
|  would take over from any other, then you just set their priorities to
|  be at least 20 different from each other router. If you wanted some
|  hibrid (where there was a set of routers that you preferred to have
|  the DR come from, but you wanted it to be sticky within that set), then
|  you could set those routers to have priority at least 21 more than
|  other routers, and within 20 of each other so that within that set
|  it would be sticky.
|  
|  With this change there are no additional parameters to set. Any router
|  can do this and interoperate with routers that don't do this.
|  
|  It might be more intuitive to have an extra parameter, either two priorities
|  (one for before election, and one for after being elected), or a priority
|  and an "election increment". But I couldn't think of any case that
|  couldn't be handled by the simple "add 20" rule.
|  
|  Radia
|  
|