Subject: [pim] BSR re-election when current BSR withdraws

From: Venugopal Hemige <[email-masked]>
Date: Fri, 19 Mar 2004 17:45:05 -0800 (PST)

There seem to be a few issues relating to BSR re-election when the current elected-BSR (eBSR) declares it no longer wants to be eBSR. There need to be additional state machine events and/or actions added in order to facilitate quick and consistent election of a new BSR on all PIM routers. Please let me know if I am missing something.
 
1. If a candidate-BSR (cBSR) receives a non-preferred BSM from the eBSR, the specified action is to set BS timer to rand_override and move to pending-BSR (pBSR) state. In addition, I think it must forward the BSM so that other PIM routers in the domain know about the eBSR's wish to withdraw it's role. Otherwise, when the cBSR tries to become eBSR, the other routers would just throw away the BSM it sends since it sees the BSM as a non-preferred BSM.
 
2. Furthermore, I think we should define an "acceptable BSM" apart from the preferred and non-preferred BSM. An acceptable BSM would be a BSM with a better weight than the cBSR, but worse than the eBSR. If a cBSR receives an acceptable BSM from the eBSR, then it must treat it as a preferred BSM and remain in cBSR state. This causes the BSM to be flooded to every one else and prevents any accidental re-election. It must also note down the new BSR priority. The current behavior is that the cBSR treats this as a non-preferred BSM and transitions to pBSR state.
 
3. When a non-candidate-BSR receives a non-preferred BSM from the eBSR, it must treat it as a preferred BSM and perform all actions relevant when processing a preferred BSM. It must also note down the new BSR priority. The current behavior is to just ignore the BSM.
 
Thanks,
-Venu

Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam