Subject: [pim] doubt regarding BS Timeout in the BSR draft.

From: "[email-masked]" <[email-masked]>
Date: Thu, 3 Oct 2002 03:16:31 -0400 (EDT)

Hi,
In the BSR draft draft-ietf-pim-sm-bsr-02.XXX. The BS timer description is like this
(1) The BS Timer in an elected BSR is started for BS Period (60 secs).
(2) In a router not configured as BSR it is BS Time out (130 secs).
(3) In a router configured as BSR also it is BS Time out (130 secs).

If the BS timer in (2) and (3) expire at the same time, what should be done to the RP Set list in case (2). Should it be deleted? If the RP set list is deleted what should happen to the entry states.

In another rand_override another BSR (if present in the n/w) might become elected and the RP set list might be reestablished.

Keeping the above point in mind if the RP set list is not deleted what should happen if no other BSR is configured?

So i think it is appropriate if the BSTimer in case (2) be started for maximum possible rand_override (5secs) + BSTimeout. In case (3)  the value can be reatained.

Please correct me IF iam wrong.
thanks
rajesh.

------------------------------------------------
Changed your e-mail?  Keep your contacts!  Use this free e-mail change of address service from Return Path.  Register now!

---

From: Pavlin Radoslavov <[email-masked]>
Date: Thu, 10 Oct 2002 21:44:52 -0700

> If the BS timer in (2) and (3) expire at the same time, what should be done to the RP Set list in case (2). Should it be deleted? If the RP set list is deleted what should happen to the entry state…

If the BS timer expires, and the state about the current BSR is
deleted, the RP-set should not be deleted. In all routers, the state
about each Cand-RP is expired based on that Cand-RP's Holdtime.

Indeed, the spec does not say that explicitly, but it is
implied. Otherwise, if the RP-set is expired when the BSR timeout,
all multicast traffic via the RPs will stop until a new BSR is
elected.

Nevertheless, to avoid such confusions, I think the spec
should be explicit about that >> spec_authors

> Keeping the above point in mind if the RP set list is not deleted what should happen if no other BSR is configured?

If no other BSR is configured, then Cand-RP set will not be
distributed anymore, and all of the Cand-RPs will timeout; i.e., no
more multicast. Hence, similar to configuring a number of Cand-RPs
for each multicast prefix, make sure you configure a number of
Cand-BSRs.

> So i think it is appropriate if the BSTimer in case (2) be started for maximum possible rand_override (5secs) + BSTimeout. In case (3)  the value can be reatained.

You don't need to increase the BS Timer for some routers only (see
above), but if you do it it will be a bad idea. If the BS Timer is
different, then some routers may ignore the first Bootstrap message
from the new BSR.

Example: BSR_old is the old BSR that goes down; BSR_new is the
cand-BSR that should become the elected one after BSR_old timeout;
CRP is not a cand-BSR, but is a Cand-RP. Lets say at time T BSR_old
sends a Bootstrap message, and then immediately crashes. Lets say
that its Bootstrap message sets the BS Timer at BSR_new to BS
Timeout (= 130), but sets the BS Timer at CRP to BS Timeout +
rand_override ~= 135. At time T + 130 the BS Timer at BSR_new will
expire; at time T + ~135 BSR_new's state will transit from Pending
BSR to Elected BSR state so then BSR_new will transmit its first
Bootstrap message (this Bootstrap message will actually have no
Cand-RPs yet). Now, because the BS Timer at CRP will expire at
almost the same time T + ~135, there is some fair chance that it may
actually receive the Bootstrap message from BSR_new before the BS
Timer expires (e.g., if the Bootstrap message from BSR_old was
actually delayed). In that case, CRP will still have the state for
BSR_old, which is preferred than BSR_new. As a result the message
from BSR_new will be ignored. It may take up to BS Period (60s) for
BSR_new to send a new Bootstrap message; in the mean time CRP
will not know the BSR, and therefore it won't send Cand-RP
messages.

I believe the reason that all BS Timers are set to same values for
all routers, and that the cand-BSRs need to wait extra "Randomized
Override Interval" (*) before sending a Bootstrap message is to make
sure that the old BSR has expired everywhere, so the above race
condition doesn't happen.

(*) The definition for rand_override in Section 5 (page 22 in the PS
version) as rand(0,5) I think is incorrect; you should look at the
definition of "Randomized Override Interval" on page 13.

Hope that helps,
Pavlin
_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim

---

From: Christopher Thomas Brown <[email-masked]>
Date: Fri, 11 Oct 2002 15:58:35 -0400

On Thu, 10 Oct 2002 21:44:52 PDT
Pavlin Radoslavov wrote:
>> If the BS timer in (2) and (3) expire at the same time, what should be done 
>to the RP Set list in case (2). Should it be deleted? If the RP set list is de
>leted what should happen to the entry states.
>

I think there is a third option you do not mention. Only expire CRPs
when not contained in the relevant BSR message fragment.

With this a non-CBSR will continue to use the last provided RP set
until a new one is provided.

---

From: Pavlin Radoslavov <[email-masked]>
Date: Fri, 11 Oct 2002 15:11:38 -0700

> when not contained in the relevant BSR message fragment.

Yes, CRPs can be deleted when they are not included in retransmitted
BSR message fragments. Though, there are a number of details you
may need to be careful about (e.g., the very first Bootstrap message
from a newly elected BSR is probably empty, so it should not
flush-out all CRPs from the previous BSR).
FYI, I just talked with one of the authors, and the bottom line was
that the spec needs to be updated to clarify those details. Stay
tuned :)

Regards,
Pavlin