Re: [pim] BSR update

[John Zwiebel <jzwiebel at cisco.com>]

A router may be restarting, or ..

the router may be connected to a switch and the switch is the system
that is rebooting.

In the first case, it is easy to set a timer on the booting router  
that is
coming up to accept any BSMs as long as they are multicast -- provided
that router doesn't start sending out hellos getting itself elected
as the DR before accepting a BSM.  ie, if there is a dependency on
which system is the DR, there is a potential for conflict.

In the second case, the router (router A) may believe that it is the  
DR on
the VLAN.  And may have some RP-cache information that
it has received from a different BSR.  When the 'real' DR comes up
(router B) you now have a problem sorting out which BSM to use the
one from A or the one from B.

Finally discovery of a new PIM neighbor takes less time than  
converging the
IGP.  So doing an RPF check is problematic, therefore forwarding the
BSM would be problematic in case 2.  Consider that this switch might
be in the middle of a network so that there are two equal size multicast
clouds.

Or, is the second case just a question of bad network design?  There
should have been multiple routes from every part of the network to
every other part.  In other words, solving the second case isn't
worth pursuing.

In that case, the triggered BSM should probably not be forwarded  
anywhere
because this triggered BSM mechanism is only used to solve the "new  
router
on a lan" case.

And so setting a "triggered BSM" bit that is sent by any router that
believes it is the DR on a LAN (which it only sends if it has a non-NULL
RP-cache) seems to be the simplest solution.  This bit means:
  -- no RPF check required.
  -- do not forward this BSM.

On Apr 10, 2006, at 10:42 AM, Venu Hemige wrote:

> 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

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