RE: [pim] BSR update

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

John,

Please see comments inline.

> [...]
> > I believe the goal
> > should be to get the entire network to a consistent RP-SET as soon
as
> > possible.
> 
> I completely agree.  But, IMHO, ASAP can mean 60 seconds, the next
> periodic BSM.  In a "well-constructed network" with a lot of
redundancy
> there shouldn't be a need to forward triggered BSMs.
>

Try telling that to IPTV providers :-). For applications like that, even
a second's worth of outage is very important to the providers.

> If this isn't a good enough reason, please consider that the idea of
> a unicast BSM seemed to be brilliant until faced with the reality
> of implementation.  (I thought so and was surprised that it didn't
> work.)
> 

Like you say, the problem with ARP resolution and unicast BSMs seems
like a an implementation issue. Also, we are attempting to solve it for
one protocol while the problem is more a generic issue with any unicast
packet going out. I would think implementations queue up unicast packets
until ARP resolution is completed. I agree there are scaling issues with
doing that, but it should typically not be an issue in most cases. So I
am not even convinced we should get rid of unicast BSMs :-).

The problem with race conditions with ARP resolution is a more generic
problem that applies to ALL unicast packets. I would rather solve that
generically than try to solve the problem in individual protocols. Just
to entertain that thought, why not require routers to send a gratuitous
ARP response when an interface comes up? And routers that receive
gratuitous ARP responses would have to create an ARP cache entry. Isn't
that much better place to solve that problem than do it here in PIM BSR?

There are several problems I see with getting rid of unicast BSMs and
replacing it with link-local multicast BSMs:

1. The solution would not be backward compatible with existing BSR
implementations. When I say that, I mean triggered BSMs do not work with
old implementations - there will be a 60 second convergence delay. There
might be a large number of existing deployments that are shipping BSR
based on the current draft. I think it is important to maintain that
backward compatibility. Again, I am assuming implementations do not
simply drop unicast packets if there has not been ARP resolution.

2. If we send a triggered multicast BSM, then it is destined to get
dropped by an old implementation if RPF check fails on that router. It
means a 60 second convergence delay when there are old implementations
in the network.

3. If we send a triggered multicast BSM, we will have to ask the other
router to ignore RPF check. If we are adding a bit in the BSM, then that
might be ok, but I am very skeptical of accepting BSMs without RPF check
for an arbitrary period of time.

Given the above, especially #1 and #2, I do not like getting rid of
unicast BSMs altogether. I would prefer solving the ARP resolution race
condition as a generic problem than deal with it here.

> So, the "worst case" scenario I can come up with.  If we choose to
> forward triggered BSMs, we could end up with BSMs looping throughout
> the network in a BSM storm.  Not that I think it -will- happen, but
> I do believe it a possibility.
> 

You asked me to prove that such a storm will not happen, so here is an
attempt in doing that :-). Forwarded BSMs are link-local multicast
packets unlike triggered BSMs. And if we introduce this DNF
(do-not-rpf-check) bit, the bit MUST be clear when forwarding the BSM.
Which means any router that receives forwarded BSMs will perform an RPF
check and accept only if it comes from the RPF. If there are no IGP
loops, then there will be no BSM storm. 

Is that acceptable explanation?

Regards,
-Venu



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