Subject: RE: BSR convergency time

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Fri, 23 Feb 2001 16:20:39 -0600

When a C-RP dies and this is communicated to the BSR, it will help if the BSR does not wait for the periodic interval and if it sends out a BSR update reflecting this change almost immediately. Is this already taken into account? Of course, there should be some dampening timer to deal with routers or links flapping. In general, it will be nice if the BSR sends out an update almost immediately if there is a change in the RP-Set information (eg., addition of a C-RP to the system or deletion of one). 

Also, in order for a rebooted or newly added C-RP to be known to all the routers in the PIM domain as quickly as possible, a C-RP advertisement can be triggered when the new router receives the RP-Set from its neighbor through a GenID change. This, in turn, should trigger a BSR update to all the routers from the BSR. This would especially help in faster convergence when a network partition recovers. 

Comments?

Thanks,
Vidya

> 
> 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
>

---

From: Mark Handley <[email-masked]>
Date: Fri, 23 Feb 2001 15:45:23 -0800

>I am not sure I completely understand the above paragraph. Are you
>suggesting something like the following sequence of events should
>happen:
>
>1. A Cand-RP router is booted-up (or rebooted).
>2. The DR will send immediately to this Cand-RP router the Bootstrap
>    message.
>3. The Cand-RP router will send immediately a Cand-RP message to
>   the BSR it has just learned about.
>4. The BSR will add the new Cand-RP to the Bootstrap set, and
>   if the Group->RP mapping has changed, it will immediately
>   send-out a Bootstrap message with the new Cand-RP included.
>
>Rule (2) is already in the spec, rule (4) was mentioned above, so
>rule (3) is needed as well to complete the picture.

I think rule (3) makes sense, but I'm not completely happy with rule
(4).

I think when an RP goes down, the BSR should immediately regenerate
the RP Set and send a new bootstrap message.  However when a new C-RP
becomes available to the BSR, I don't see any reason why the BSR needs
to rush to change the RP set.  The only reason to do this would be if
the existing RPs are likely to be overloaded.  If this isn't likely
(ie the RP Set is already reasonable sized), then I think a good BSR
implementation wouldn't change the RP set unnecessarily as this
disrupts traffic on the shared tree for those groups that hash to the
new RP.  In addition, it's possible several C-RPs came up in a short
time, and you would certainly rather avoid unnecessary thrashing of
the RP set.

Cheers,
	Mark

---

From: Pavlin Ivanov Radoslavov <[email-masked]>
Date: Fri, 23 Feb 2001 15:30:06 -0800

> When a C-RP dies and this is communicated to the BSR, it will help
> if the BSR does not wait for the periodic interval and if it sends
> out a BSR update reflecting this change almost immediately. Is

Right.

> this already taken into account? Of course, there should be some
> dampening timer to deal with routers or links flapping. In
> general, it will be nice if the BSR sends out an update almost
> immediately if there is a change in the RP-Set information (eg.,
> addition of a C-RP to the system or deletion of one). 

Agree. Actually, by looking at the end of Section 3.1 of the new
Bootstrap I-D that Mark just sent to the ML, it indeed says that
a new Bootstrap message is generated whenever a Cand-RP message with
holdtime of 0 is received. Maybe this rule should be generalized
as you suggest above (generate a new Bootstrap message whenever
a Cand-RP message that affects the Group->RP mapping has been
received)?

> Also, in order for a rebooted or newly added C-RP to be known to
> all the routers in the PIM domain as quickly as possible, a C-RP
> advertisement can be triggered when the new router receives the
> RP-Set from its neighbor through a GenID change. This, in turn,
> should trigger a BSR update to all the routers from the BSR. This
> would especially help in faster convergence when a network
> partition recovers.

Regards,
Pavlin

---

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

> the existing RPs are likely to be overloaded.  If this isn't likely

I agree that there are less compelling reasons for adding rule (4).
The BSR itself may be in a position to know better when to send-out
the Bootstrap message (e.g. if the RP-set was empty), hence rule (4)
should be something like:

"If the BSR receives a new Cand-RP message that adds a new Cand-RP
to the RP-Set, it MAY send-out the Bootstrap message before the BS
Timer expires".

However, because of the existing danger of trashing the RP-set, then
I'm fine if we don't have even the above rule.

Regards,
Pavlin