Re: [pim] BSR update

[Stig Venaas <stig.venaas at uninett.no>]

Dino Farinacci wrote:
> > > Slide 6, Unicast BSMs
> > >
> > > New revision says that they must be sent from the primary address,
> > > and also only accepts them from the primary. I believe Dino said this
> > > was problematic. But I must say now that I'm not sure why. Could you
> > > clarify Dino? Or anyone else?
>
>     The problem with unicast BSMs, as sent by the DR on a LAN when a new
>     neighbor comes up, is if the ARP cache is not primed with the new 
>     neighbor, then the BSM is *typically* dropped by the local system (when
>     the ARP implementation does not queue packets). 
>
>     Since the PIM neighbor adjacency and the unicast routing protocol adjacency
>     are coming up at the same time, it is typically a race on which one sends 
>     the first unicast packet to the newly booted router. And since there is 
>     less chit-chat in PIM for bringing up an adjacency (versus OSPF or, IS-IS 
>     which never sends a unicast packet), it's the BSM that triggers the ARP
>     request.
>
>     So I am questioning the probablistic usefulness of unicast BSMs. I think
>     a simple solution is to link-local multicast them. But the new neighbor
>     needs to not RPF-check these. So either:
>
>     o The new neighbor accepts all BSMs within a short-time of discovering
>       the DR, or
>
>     o Set a bit in the BSM to unconditionally accept (and not forward) the
>       BSM. This would be useful from another repsect in that the new neighbor
>       wouldn't have to determine if the DR is sending it. Especially, in the
>       case where the new neighbor is just becoming the DR.

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?

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?

Stig


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