Subject: [pim] Use of BS_Min_Interval in BSR draft

From: Rishabh Parekh <[email-masked]>
Date: Fri, 19 Jan 2007 15:00:31 -0800

Hi,
The latest BSR draft states "There MUST however be a minimum of BS_Min_Interval between each time a BSM is sent." This is mentioned in the context of generating BSMs on C-RP set changes. 

However, the C-BSR state machine also originates BSMs in E-BSR state for the event "Recieve Non-Preferred BSM". This action is not limited by BS_Min_Interval. Should this action also be throttled by BS_Min_Interval value? If so, then the action should be to reduce BS Timer to BS_Min_Interval if it is greater than this interval.

Regards,
Rishabh.
_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: sumanta seal <[email-masked]>
Date: Sat, 20 Jan 2007 09:20:44 +0000 (GMT)

Rishabh Parekh <[email-masked]> wrote:  Hi,
 The latest BSR draft states "There MUST however be a minimum of BS_Min_Interval between each time a BSM is sent." This is mentioned in the context of generating BSMs on C-RP set changes. 
 
 However, the C-BSR state machine also originates BSMs in E-BSR state for the event "Recieve Non-Preferred BSM". This action is not limited by BS_Min_Interval. Should this action also be throttled by BS_Min_Interval value?
 If so, then the action should be to reduce BS Timer to BS_Min_Interval if it is greater than this interval. 
BS_Min_Interval is applied to the case when there is a need of sending BSM due to some event. For example, when a BSR, elected as DR, receives a new Hello or a Hello with new Gen Id from a PIM neighbor, it will send a BSM with the stored copy of Bootstrap information in it. This BSM should be send after BS_Min_Interval from the previous BSM it send. In normal scenario, BSMs are send at an interval of BS_Period by the elected BSR.
Rgds,Sumanta

 Regards,
 Rishabh.

Thanks & Regards, 
************************************************** 
Sumanta Seal
Salt Lake City, Kolkata
West Bengal
**************************************************

---------------------------------
 Here’s a new way to find what you're looking for - Yahoo! Answers

---

From: Rishabh Parekh <[email-masked]>
Date: Sun, 21 Jan 2007 16:16:55 -0800

Sumanta,
Please fine my reply inline.

Rishabh.
On Saturday 20 January 2007 01:20, sumanta seal wrote:
> BS_Min_Interval is 
> applied to the case when there is a need of sending BSM due to some event.
> For example, when a BSR, elected as DR, receives a new Hello or a Hello
> with new Gen Id from a PIM neighbor, it will send a BSM with the stored
> copy of Bootstrap information in it. This BSM should be send after
> BS_Min_Interval from the previous BSM it send. In normal scenario, BSMs are
> send at an interval of BS_Period by the elected BSR. Rgds,Sumanta
>
You are referring to the "No Forward" or Unicast BSMs which refresh BSR state 
at a new or re-starting neighbor. I don't think that these BSMs should be 
limited by the BS_Min_Interval because doing so will defeat the very purpose 
of such BSM messages.
I was referring to the regular BSM generated by an E-BSR due to two different 
events. In one case (C-RP set changes), the origin of BSM is limited by 
BS_Min_Interval while in other case (Recv Non-Preferred BSM) the origin is 
not regulated. My question is whether the latter case should also be limited 
by BS_Min_Interval or not?
>  Heres a new way to find what you're looking for - Yahoo! Answers

---

From: Alexander Gall <[email-masked]>
Date: Mon, 22 Jan 2007 16:14:52 +0100

On Fri, 19 Jan 2007 15:00:31 -0800, Rishabh Parekh <[email-masked]> said:

> The latest BSR draft states "There MUST however be a minimum of
> BS_Min_Interval between each time a BSM is sent." This is mentioned
> in the context of generating BSMs on C-RP set changes.

> However, the C-BSR state machine also originates BSMs in E-BSR state
> for the event "Recieve Non-Preferred BSM". This action is not
> limited by BS_Min_Interval. Should this action also be throttled by
> BS_Min_Interval value? If so, then the action should be to reduce BS
> Timer to BS_Min_Interval if it is greater than this interval.

Throttling is not necessary in a stable network because a candidate
BSR does not generate any BSMs as long as it receives those from the
elected BSR (i.e. this particular event does not occur at all in this
case).  Thrashing during BSR (re-)election is prevented by
BS_Rand_Override, so this issue appears to be moot.

--
Alex

---

From: Rishabh Parekh <[email-masked]>
Date: Mon, 22 Jan 2007 10:19:12 -0800

Alex,
> BS_Rand_Override, so this issue appears to be moot.
The BS_Rand_Override interval at a new C-BSR might not be large enough (and 
thereby contained within the 60 second BS_Period window at E-BSR) to prevent 
the C-BSR from transitioning to E-BSR from P-BSR state and sending out an 
empty BSM. In this case, the E-BSR will send out a BSM (if the new C-BSR is 
inferior) without waiting for BS_Min_Interval.

Even if throttling is not required in above case, I feel that the MUST 
statement in the spec should be modified to explicitly exclude "No Forward" 
BSMs and Unicast BSMs from BS_Min_Interval limit to prevent a 
misunderstanding as evident in earlier mail from Sumanta.

Rishabh.

---

From: Alexander Gall <[email-masked]>
Date: Tue, 23 Jan 2007 17:43:30 +0100

> inferior) without waiting for BS_Min_Interval.

Yes, this can happen, but it has no effect on the receiving routers
because the RP-set doesn't change.  I really don't think it matters.

> misunderstanding as evident in earlier mail from Sumanta.

Note that such BSMs are originated by the DR.  So this is only
relevant if it happens to be the E-BSR.  IMHO, a clarification for
this corner case is not needed.

--
Alex