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

---

From: Rishabh Parekh <[email-masked]>
Date: Mon, 22 Mar 2004 15:59:51 -0800

Venu,
Please look at the replies inline.

On Friday 19 March 2004 05:45 pm, Venugopal Hemige wrote:
> 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.
>

I agree that the non-preferred BSM message from eBSR should be forwarded so 
that eBSR's new weight is propogated across the SZ quickly. However the 
current FSM also works because when the cBSR transitions from pBSR to eBSR 
state, it will originate a BSM. When the previous eBSR receives this BSM, it 
will transition to cBSR state and stop originating BSMs. This will cause the 
previous eBSR state to be timed out in all other routers in the SZ and 
re-election will occur. 

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

I do not think that the "acceptable" BSM will work because only the RP-set 
from the current eBSR should be "trusted" as all the C-RPs are sending C-RP 
Adv to that router. In current FSM, a router in cBSR state will ONLY 
transition to pBSR when it receives a non-preferred BSM from the eBSR. A 
non-preferred BSM from any router other than the current eBSR should be 
ignored.
 
> 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.
>
Again, I do not think that a non-candidate BSR should process a non-preferred 
BSM in Accept Preferred state as a preferred BSM because only the RP-set from 
current BSR should be "trusted". However, as an enhancement, when a 
non-preferred BSM is received from current BSR in Accept Preferred state, the 
router should store the new weight of the BSR so that any re-election happens 
quicker.

Regards,
Rishabh. 

> Yahoo! Mail - More reliable, more storage, less spam

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

---

From: Rishabh Parekh <[email-masked]>
Date: Mon, 22 Mar 2004 15:59:51 -0800

Venu,

 

Regards,
Rishabh.

---

From: Venugopal Hemige <[email-masked]>
Date: Mon, 22 Mar 2004 16:47:34 -0800 (PST)

Risabh,
 
I was not contending that the current draft does not work. Sure, all routers converge to using the same eBSR within 2*bs-timeout seconds.. I was proposing something which helps this convergence happen almost immediately. I am not sure if this is of much importance in actual deployments, since the rp-set should not really change when re-electing BSRs, but it helps limit the amount of BSM traffic in the network for sure. 
 
Please see comments inline.

Rishabh Parekh <[email-masked]> wrote:

Venu,

[Venu] Again, I agree with you. The intention of my mail was to facilitate quicker re-election of the new eBSR than have to wait for bs-timeouts.

[Venu] Ok, I am only talking about "acceptable BSM from current eBSR". If you lower the priority on the eBSR, but it is still better than the cBSR, then the cBSR need to try to become pBSR. By definition, non-preferred BSM is something that is worse than current eBSR weight and I am merely pointing out, it is worth making a distinction between "non-preferred BSM from eBSR" and "acceptable BSM from eBSR". Again, the network corrects itself after bs-timeout seconds, but that is churn not really necessary and can be easily avoided.

[Venu] Same argument as above. I am only talking about "non-preferred BSM from eBSR". Storing the new weight helps the BSR see the new BSR quickly, but if it did not forward the "non-preferred BSM from eBSR", other routers in the network will not have the opportunity to store the new weight and we end up with not really solving the problem we set out to solve. 

Regards,

-Venu

Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.

---

From: Venugopal Hemige <[email-masked]>
Date: Mon, 22 Mar 2004 16:47:34 -0800 (PST)

Risabh,

Venu,

Regards,

-Venu

Do you Yahoo!?

---

From: Rishabh Parekh <[email-masked]>
Date: Tue, 23 Mar 2004 08:54:16 -0800

Venu,
Please look at my replies inline.

On Monday 22 March 2004 04:47 pm, Venugopal Hemige wrote:
> > 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.
>
> [Venu] Ok, I am only talking about "acceptable BSM from current eBSR". If
> you lower the priority on the eBSR, but it is still better than the cBSR,
> then the cBSR need to try to become pBSR. By definition, non-preferred BSM
> is something that is worse than current eBSR weight and I am merely
> pointing out, it is worth making a distinction between "non-preferred BSM
> from eBSR" and "acceptable BSM from eBSR". Again, the network corrects
> itself after bs-timeout seconds, but that is churn not really necessary and
> can be easily avoided.
>

I am sorry if I misunderstood you. But it is not clear from your original mail 
that you meant an acceptable BSM from the current BSR. I agree with you about 
the need distinction between non-prefereed BSM from any other router and an 
"acceptable" BSM from current eBSR. This should quicken convergence after an 
election.
 
Regards,
Rishabh.

---

From: Rishabh Parekh <[email-masked]>
Date: Tue, 23 Mar 2004 08:54:16 -0800

Venu,

 
Regards,
Rishabh.