Subject: Re: Dynamic Priority setting for DR election

From: "Manral, Vishwas" <[email-masked]>
Date: Sat, 1 Jun 2002 08:25:39 -0400

Hi Mitchell,

I do not know your exact intent and what you want to achieve here, but this
method would not be backward compatible with the existing methods. For a
method to be useful, its extremely important it is able to interoperate with
existing methods.

I dont know of anything like this having been proposed in any draft in the
recent past.

However I guess there are some implementations in ISIS which flip up the
priority of the DIS(DR) so as to prevent frequent changes of the DIS(as has
been pointed out earlier in the list). I do not know of any dynamic
selection of priority though.

Thanks,
Vishwas

-----Original Message-----
From: Erblichs [mailto:[email-masked]]
Sent: Saturday, June 01, 2002 4:31 AM
To: [email-masked]
Subject: Dynamic Priority setting for DR election

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

---

From: Anton Smirnov <[email-masked]>
Date: Sat, 1 Jun 2002 21:03:51 +0200

Mitchell,
   I don't think DR's responsibilities have big impact on resources of
<router>, especially if any technique to optimize flooding over parallel
links has been implemented. Thus dynamic priority change looks like bringing
problems rather than solving them...

Anton

---

From: Erblichs <[email-masked]>
Date: Sat, 1 Jun 2002 12:52:03 -0700

Anton,

        This was a request to investigate this functionality.

        My assumption is that if the router architecture supports
        MANY DR capable interfaces, then they would like to
        have different routers willing to over-ride other
        configured priority values..

        So, they don't have to set a fixed priority value per
        interface and not be sure that the router will be the
        DR. They don't have to set the highest value. After
        the router is elected DR. They only have to execute
        a CLI to determine what is the current priority that
        the router selected per interface.

        Simply, this is a administration issue.

        And, if I understand your resource statement correctly,
        then I would have to disagree. A one item example..
         After a DR is elected,
        this router would then have to sychronize its database
        with all DRothers.. The time to do this is mostly dependent
        on the number of capable simultaneous adj formations
        without overload..
         And of course, their is a overload draft that
        suggests to limit this simultaneous adjs to a known
        acceptable value. This value is dependent on the
        capabilities of the router..

        Mitchell Erblich
        PS: And if anyone was wondering, the hello interval
        and the ROUTERDEADINTERVAL could also be read from
        recieved hellos. Again, this could lead to less required
        configuration to establish 2-ways.
        ========================

---

From: Anton Smirnov <[email-masked]>
Date: Sat, 1 Jun 2002 23:43:53 +0200

Mitchel,
   there must be several conditions met for platform to benefit from DR
offload:
- <Router> (in broad sense of the word) must have many interfaces, dozens if
not hundreds
- These interfaces must be OSPF broadcast/NBMA (because there is no DR on
ptp links)
- On each interface more than one neighbor should be present. This rule is
because otherwise interfaces should be converted - manually or somehow
automatically - to ptp. Thus dozens of apparently needless Net LSAs will be
eliminated from LSDB, having other benefits (less flooding and simpler SPF
in the area)
- Set of routers on each interface should be different. If same routers are
neighboring thru dozens of transit interfaces then one must think about
reasonable network design, right?

   I can't think of any widely accepted industry solution matching all these
requirements. Access solutions tend to have ptp links, whatever L2 method is
employed. Layer 3 switches come closest to matching all these conditions but
it is because last rule usually neglected. On L3 switches all interfaces (or
vlans) where end clients are connected may and should be configured as stub
networks, not transit.
   Then I just do not see a case where DR offload may be beneficial. That
was my point.

   Of course, there always exist freaks who for very specific reasons want
to do something unusual. But these freaks can manually play with OSPF
priorities on interfaces of routers.

Anton

----- Original Message -----
From: "Erblichs" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, June 01, 2002 9:52 PM
Subject: Re: [OSPF] Dynamic Priority setting for DR election

> > > method to be useful, its extremely important it is able to
interoperate
> > with
> > > priority of the DIS(DR) so as to prevent frequent changes of the
DIS(as
> > has

---

From: Alex Zinin <[email-masked]>
Date: Wed, 12 Jun 2002 19:06:01 -0700

In fact, there are situations where even with a single segment,
 DR responsibilities are too much of a burden for a given router,
 especially when there's a big number of neighbors and a constant
 stream of LSA updates or a flooding storm. So, the situations
 where you do want to shift the DR responsibility may be quite
 realistic.

 In fact, there's a backward-compatible way to preempt the DR
 responsibilities that I already mentioned on the list. The idea
 is to use the process that is seen when a partitioned segment
 is reconnected again. In this case, two routers believe they are
 the DR and compete for this position, as each of them announces
 itself as the DR. Similarly to this process, a router could try
 to preempt the DR role if it announces itself as the DR (or the
 BDR if that's what we need).  If the admin happened to configure
 correct priority, the DR role will shift. A nice thing is that
 we can always tell if preemption is possible based on the local
 configuration and neighbors' announced priorities & IDs.

 That's a small hack and if we see enough interest from the OPS
 community, I guess the WG could consider working on a draft for
 it.

--
Alex