Subject: RE: BSR convergency time

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Mon, 26 Feb 2001 11:20:50 -0600

I was actually suggesting rule (4) for this same reason. Of course, it is definitely useful to use some kind of debounce timer to prevent BSR messages from going out too often. Or, we could make it optional as Pavlin suggested. 

-Vidya

> -----Original Message-----
> From: Mathur Sonum-CSM109 
> Sent: Sunday, February 25, 2001 4:50 PM
> To: 'Pavlin Ivanov Radoslavov '; 'Mark Handley '
> Cc: Narayanan Vidya-CVN065; 'Brian Edwards '; [email-masked] '
> Subject: RE: BSR convergency time 
> 
> 
> 
> Isn't it a good idea to have rule (4) for the cases when the 
> new C-RP being added is for a group prefix which is not being 
> served by any other C-RP. In this case, the information  
> about this new C-RP should be communicated immediately by the 
> BSR. If not, some of the  joins for that group prefix may be 
> dropped till the periodic Bootstrap message arrives, which 
> may be in the order of 60 seconds. 
> 
> --
> Sonum
> 
> > >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.
> 
> >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.
>

---

From: Mark Handley <[email-masked]>
Date: Mon, 26 Feb 2001 10:07:10 -0800

>I was actually suggesting rule (4) for this same reason. Of course, it is defi
>nitely useful to use some kind of debounce timer to prevent BSR messages from 
>going out too often. Or, we could make it optional as Pavlin suggested. 

I think making it optional is the way to go.  Probably with a sentence
of two of explanation.  

This sort of thing doesn't affect interoperability.  The normal IETF
way of doing things is to leave the fine tuning to implementors if
it's not important for interoperability.  But also to capture the
rationale (if possible) to give implementors information to make their
decision.

Cheers,
	Mark