Subject: [pim] Question on BSR as according to draft_*06.txt

From: vikram pim <[email-masked]>
Date: Tue, 15 Nov 2005 08:26:55 -0800 (PST)

Hi all,
 
I had a question on BSR election. There is an E-BSR and several C-BSRs
 
The timeline sequence for which is as follows:
 
E-BSR  ----> advertises the RP-set mapping within the bs_period
E-BSR ----> advertises the RP-set mapping  within the bs_period
 
However now,
 
E-BSR ---> advertises a NULL RP-set mapping within the bs_period
E-BSR ---> advertises a NULL RP-set mapping within the bs_period
 
According to the draft, page 15, it says the action of Storing RP is 
skipped for an empty BSM. 
 
However, will this allow the current E-BSR to continue doing this without
arming the BS_timeout timer? In short will this E-BSR be the elected BSR 
preventing any  other C-BSR to take over ???
 
Also, will the previous RP-set information be refreshed too?
 
Thanx
vikram

---------------------------------
 Yahoo! FareChase - Search multiple travel sites in one click.  

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

---

From: John Zwiebel <[email-masked]>
Date: Tue, 15 Nov 2005 12:38:47 -0800

> E-BSR ---> advertises a NULL RP-set mapping within the bs_period

Why would it do this unless there are no C-RPs?

> skipped for an empty BSM.

I don't see what you are referring to.

> preventing any  other C-BSR to take over ???

I would think so.  The question is why are you seeing a BSM with no C- 
RPs?
Are you under a DOS attack?

> Also, will the previous RP-set information be refreshed too?

There has to be a C-RP in the BSM to update the timeout in the client  
RP-cache.
According to para 3.4:

     If an RP is not in the new RP-Set, that RP is considered  
unreachable and
     the hash algorithm (see PIM-SM specification) is re-performed  
for each
     group with locally active state that previously hashed to that  
RP. This
     will cause those groups to be distributed among the remaining RPs.

But that seems to contradict this paragraph on page 25 (as well as  
some other places):

   RP Count 1..n
      The number of Candidate RP addresses included in the whole
      Bootstrap message for the corresponding group prefix. A router  
does
      not replace its old RP-Set for a given group prefix until/ 
unless it
      receives `RP-Count' addresses for that prefix; the addresses could
      be carried over several fragments.  If only part of the RP-Set for
      a given group prefix was received, the router discards it, without
      updating that specific group prefix's RP-Set.

And then if one considers that a BSM can be divided into fragments,  
it would
seem to me that unless the C-RP is explicitly removed with a Holdtime  
of 0
in the BSM that there could be problems.