Re: [pim] BSR update

[John Zwiebel <jzwiebel at cisco.com>]

On Apr 10, 2006, at 11:02 PM, Stig Venaas wrote:

> I have some problems understanding why arp can't be performed  
> first, but I'm not so interested in discussing that because I think  
> using a multicasted BSM with DNF is both simpler and safer than  
> unicasted BSMs. I like the idea that BSMs would then always be sent  
> to the same destination address, and always multicast.

Its a implementation choice that dates back to the beginning of time.
If an IP packet is to be sent to someone on the LAN for which there is
no ARP, that packet is dropped and an ARP is sent.  The theory being  
that
if the user really wanted to send the original packet, it will send  
another.

I believe the choice had to do with the difficulty in queuing
a large number of packets while waiting for the ARP response
when a router might have to be ARPing for many hosts.  I won't
guess beyond that.

> >   Solution (that I think we are converging on):
> >     o multicast the BSM
> >     o set DNF bit in PIM header for triggered BSM
> >     o do not do an RPF check on BSM received with DNF bit set
> >         (It also means "trust me")
>
> At least I think I have converged :)
>
> >      o <optional> only accept DNF-bit BSMs for <TBD> seconds after  
> > discovery of
> >         a new PIM neighbor.
>
> Yes, I'm not sure about this one. Regarding unicast BSMs it now  
> says that they are accepted until first BSM or a maximum of 150s (I  
> believe). Which kind of makes sense. I'm not able to see any  
> problems in removing this restriction though. For unicast BSMs I  
> think it's there partly to improve security...

If the DNF-bit didn't also mean 'trust me' I wouldn't care.  But as  
it is
now, I think 30 seconds is more than long enough.

Of course, we aren't addressing the potential loss of such a  
triggered BSM. :-(

> >   Trying to heal a broken network appears to be a pathological  
> > case where the
> >     network isn't configured for redundancy anyway.  There's no  
> > advantage
> >     to it since other problems will overshadow this fix.
>
> Doing the forwarding helps in exactly these pathological cases. But  
> in those cases there is a risk of getting stale data as well (if a  
> router is out of contact with BSR for a short while).

Yes, IFF one has not configured his network for redundancy.
If I sound like a broken record, sorry.  I just want to be sure
that forwarding a triggered BSM is not an option.  The cases it
fixes are few while the potential for causing problems that we
don't currently understand are many.

> BTW, a router could also have stale data if there is some packet  
> loss on path from E-BSR...

Which I interpret to mean that you will not forward the triggered BSM.
Great.

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