Subject: DR functionality in case of router reboot

From: Mathur Sonum-CSM109 <[email-masked]>
Date: Wed, 17 Jan 2001 18:19:07 -0600

When a PIM router reboots on a shared link, the DR of that link sends the Hello and RP-Set to the rebooted router. But all the other non-DR routers never trigger any packet. The rebooted router learns about all the other PIM neighbors when they send thier periodic Hello messages, which may be in the order of 30 seconds. The rebooted router has no method of 'immediately' knowing about all the neighbors. This is important because some of these neighbors may be the upstream RPF neighbor to reach RP. For eg, in the topology

                 R2----------R3----------RP
                 |
                 | 
    R4(DR)--|
                 |
                R1

R1 reboots and it gets PIM hello and RP-Set from the DR. But, R1 doesn't know about the R2 till R2 sends the periodic Hello message. And thus R1 doesn't know about RP also till that time.

Shouldn't the DR have some mechanism of informing about all the routers on the link to the rebooted router ?? 
Other solution is that all the routers on the link (DRs as well as non-DRs) trigger a Hello when they see a Hello message from a new neighbor. But this solution may be costly for the network if that shared link contains many PIM routers.

--
Sonum

---

From: Pavlin Ivanov Radoslavov <[email-masked]>
Date: Mon, 22 Jan 2001 01:10:43 -0800

> Shouldn't the DR have some mechanism of informing about all the
> routers on the link to the rebooted router ??
> Other solution is that all the routers on the link (DRs as well as
> non-DRs) trigger a Hello when they see a Hello message from a new
> neighbor. But this solution may be costly for the network if that
> shared link contains many PIM routers.

The network overhead of the DR sending a list of all nbrs in a
single packet is comparable to the overall overhead of each router
sending its own Hello message. Hence, instead of introducing a new
control message that is not backward compatible, it will be a much
simpler to apply your second proposal. It is much simpler to
implement, incrementably deployable and does not create any backward
compatibility issues.

IMHO, it is nice to have this optimization added/mentioned in the
spec, but is not a MUST.
Maybe it should be a "MAY"? :)

For example:

After a PIM router sees a new neighbor, it MAY schedule to send an
extra Hello message within the next 5 seconds (randomized), but at
the same time the originally scheduled Hello is not canceled (i.e.,
the triggered Hello will not affect the timing of the periodic
Hello messages).

Pavlin

---

From: Isidor Kouvelas <[email-masked]>
Date: Mon, 22 Jan 2001 08:51:14 -0800

In message <[email-masked]>,
>the triggered Hello will not affect the timing of the periodic

Yes we agree with this position as well and in fact had discussed
adding some similar text to the spec...

thanks
I