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

From: "[email-masked]" <[email-masked]>
Date: Fri, 11 Oct 2002 01:52:28 -0400 (EDT)

Please find my reply inline. grep for RAJ please.
thanks
rajesh.

 --- On Fri 10/11, Pavlin Radoslavov  wrote:
From: Pavlin Radoslavov [mailto: [email-masked]]
To: [email-masked]
     Cc: [email-masked]
Date: Thu, 10 Oct 2002 21:44:52 -0700
Subject: Re: [pim] doubt regarding BS Timeout in the BSR draft. 

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

---> [RAJ] The Cand-RP Expiry timer is only relevant in a BSR,     
           please see section 2 of the draft. I guess this problem
           would not arise if this timer is relevant in all the 
           routers as you said.

> 
> 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
> 
---> [RAJ] I agree with you.
> 
> > 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?
> 
> 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.
---> [RAJ] Yes your analysis is correct. The non BSRs might discard 
           the first BSR message.
> 
> 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.
> 
---> [RAJ] I agree with you on the above explanation.

[RAJ]
I think the authors need to either make the C-RP exiry timer global to all the routers.
> Hope that helps,
> Pavlin

------------------------------------------------
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

---

From: Pavlin Radoslavov <[email-masked]>
Date: Thu, 10 Oct 2002 23:13:30 -0700

>            would not arise if this timer is relevant in all the 

I never said that the non-BSRs use _the_ C-RP Expiry Timer to
expire the Cand-RPs :)

"C-RP Expiry Timer" is the name of the timer the BSR starts per
Cand-RP using the Holdtime value from the Candidate-RP-Advertisement
messages.

The timer each non-BSR router starts per Cand-RP is based on that
Cand-RP's Holdtime value in the Bootstrap message. That timer
appears to be implied, but is not named in the spec.
What particular name it will have is up to the authors :)

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