Subject: RE: BSR convergency time

From: Brian Edwards <[email-masked]>
Date: Thu, 22 Feb 2001 16:43:57 -0800

Mark,
Yes I agree that if an RP fails (which is much more likely than total
network partition), then both mechanisms have about the same convergence
time.

-Brian

-----Original Message-----
From: Mark Handley [mailto:[email-masked]]

If we were just talking about RP failure, it seems like there's not
much to choose between the two (all groups in one anycast RP's region
affected vs some of the groups in the whole domain affected).

---

From: Pavlin Ivanov Radoslavov <[email-masked]>
Date: Fri, 23 Feb 2001 03:57:53 -0800

> network partition), then both mechanisms have about the same convergence

Thanks for all responses. Now I have a better picture of the
problem.

Below I will describe the Bootstrap enhancement I mentioned before.
Some aspects of this enhancement can be used with other mechanisms
(e.g. taking care of RP failure).

The basic idea is if a Cand-RP or a BSR is down or unreachable,
the state/information about it should be quickly timeout or
deprecated from all routers. Two ways to do it is:

  * Send a message with holdtime of 0 (or some very small timeout
    value). The effect of such message is that it will quickly
    timeout whatever state it carries.
    For example, if such Cand-RP message is sent to the BSR, and
    then propagated (inside the Bootstrap message) through the
    network, it will flush the particular RP state from all
    routers.

  * Send a message with very low priority. This message will
    update the previous state by deprecating it.
    For example, the BSR-priority field inside a Bootstrap message
    can be used to deprecate the particular BSR.

Hence, if a Cand-RP or a BSR is gracefully going down, it should
send the appropriate Cand-RP/Bootpstrap message to flush-out its own
state (I think the new spec mentions similar rule for sending Hello
messages with Holdtime of 0).

Well, if the Cand-RP or BSR crashes, or if there is a network
partitioning, then obviously the RP/BSR won't be able to originate
the flushing message, or the message will not reach the routers on
the other side of the partition. In this case, we can allow the
particular message to be originated by another router. For example:

 * If a router crashes, its neighbors will detect it (e.g., the
   Hello messages expired or by some other mechanism), and the DR
   will originate all necessary flushing messages on behalf of the
   crashed router (the state that needs to be flushed can be deduced
   from the most recent BSR message).

 * If there is a network partitioning, the routers that are alive
   and are on the border with the partitioning will automatically
   know which Cand-RPs and Cand-BSRs are on the other side of the
   partition (based on the RPF check), and therefore they can
   originate the appropriate flushing messages toward the
   to-be-elected BSR within each partition.

There are two drawbacks I see with this enhancement:

 * The default Hello expire time is 105 s, so the Hello mechanism
   itself is not a much faster way of discovering a neighbor router
   crash/partitioning. If fast convergence is essential, we may want
   to reduce the Hello Holdtime anyway, so it may help to improve
   BSR convergency as well.

 * If there is a network partitioning across a large domain, then
   there each of the routers next to the partitioning will discover
   it and will initiate flushing data toward the new BSR in each
   partition, and this may result in some notable network
   overhead for very large domains. Randomization (either
   implicit or explicit) can help here though.

Comments?

Pavlin