Re: [pim] BSR update
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pim] BSR update



Christopher Thomas Brown wrote:
Stig Venaas wrote:
I believe I see one problem now. If we have the following scenario:

          _________________ long non-preferred backup path
         /                  \
BSR -- A -- R1 -- B -- R2 -- C1 -- C2 -- C3

With BSR being the only C-BSR (and elected). Assume now that routers R1 and R2 restart, and are gone for say 1.5 * BS Period. Assume that while they are restarting, the BSR changes the RP set and A and C routers learn the new set. B will however still have the old set. When R1 and R2 comes up, R2 might accept stale BSM from B. Now if R2 forwards this towards C routers and the IGP by then has gone back to prefer tha main path (not using the backup path), then C routers will accept and use the stale data.

I'd say this kills the idea. I'd much rather have the partition with the stale data converge more slowly than risk having stale data propagate once the partition begins to heal.

This is the worst case scenario I can think of. This might be bad enough to go for no forwarding (with some flag bit whatever) I suppose,

I still want to know which bit people have in mind. The only spare bits are in the encoded group address and I would not like having to parse that far into the BSM in order to determine if it should be accepted or rejected.

Yes, I think the most obvious is to use a bit for the first encoded group address in the BSM (really first in each fragment). I also think this is rather ugly. You would only need to parse for it when you boot up though, and it should probably be just one BSM (the first you get).


I assume we don't want to touch the reserved bits that are right after the PIM type field. Those bits should probably be left the same for PIM messages (incl BSMs).

Regarding backwards compatibility. Routers not supporting such a new scheme, would ignore this bit and always do RPF and forwarding as today. This means that the problem I noted in the scenario above might still occur if router R2 implements say RFC 2362 BSR (RPF might fail though if it hasn't got info from IGP yet).

Stig

Chris


_______________________________________________
pim mailing list
pim at ietf.org
https://www1.ietf.org/mailman/listinfo/pim




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.