Re: [pim] BSR update

["Christopher Thomas Brown" <ctbrown at nexthop.com>]

Stig Venaas wrote:
> I would like to not change the draft more than necessary, but I must say 
> I like the idea of getting rid of unicast BSMs if possible.
> 
> I prefer your first alternative, i.e., not adding a new flag. However, I 
> would also like to avoid the complexity of finding out whether the BSM 
> came from the DR (the DR in this new routers absence). What about 
> skipping that check? Currently there is no check that the unicasted BSM 
> came from the DR either. However, the unicasted BSM is supposed to be 
> sent by the DR, so we should still say that this triggered multicasted 
> BSM is to be sent by the DR.
> 
> Do you see any problems with just saying that for a short time after 
> startup, the RPF check is not required?


I think it couldn't be required.  If the router is restarting it likely
doesn't have an MRIB with which to do an RPF check.


> Then there is the issue of forwarding. We could perhaps say that RPF 
> should still be performed. I wonder if it would be safe enough to just 
> forward it and have the neighbours perform RPF.
> 
> So, to conclude, how about saying that if no previous BSM has been 
> accepted (for the particular scope zone) and less than BS_Period has 
> elapsed since startup, then the RPF check should be skipped.
> 
> I believe this would greatly simplify the implementation (no unicast 
> BSMs, just a minor special case at startup). There is significant 
> complexity in securing unicast BSMs (e.g. Router Alerts or use of ttl 
> 255, verifying ttls and backwards compatibility) that would simply go away.
> 
> Anyone see issues with my proposal? Anyone prefer alternative solutions 
> as suggested by Dino or others?


I see one potential issue, but I'm unsure how much of a real problem it
is.  Any other router on the lan that has the DR as the RPF to the BSR
will not be able to distinguish this BSM from one originated by the BSR.
So, some subtrees might see some burstiness to BSMs.  However, since the
BS period is realatively long I'm not sure how much of an issue this
really is.

Chris

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