RE: [pim] BSR update

["Venu Hemige" <venu.hemige at alcatel.com>]

Wouldn't there be a problem if we do not do RPF check? Let's say there
is more than one router starting up simultaneously. Both of them do not
do RPF check for a short period of time. BSMs that are received on that
interface and accepted without RPF check may be forwarded back on that
interface (or may come from elsewhere to complete the loop). The same
BSM may get forwarded multiple times in the network until the routers
decide to start doing RPF check again.

I like Dino's second idea of setting a bit in the BSM to accept without
RPF check. But I think the BSM should be forwarded. When forwarding, we
should disable this bit.

Regards,
-Venu

> -----Original Message-----
> From: Christopher Thomas Brown [mailto:ctbrown at nexthop.com]
> Sent: Monday, April 10, 2006 10:06 AM
> To: Stig Venaas
> Cc: pim at ietf.org
> Subject: Re: [pim] BSR update
> 
> 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


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