Re: [pim] BSR update
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [pim] BSR update
On Apr 11, 2006, at 4:06 PM, Venu Hemige wrote:
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.
I would not for a second suggest that an IPTV provider should be happy
with a 60 second downtime.
OTOH, I would question their network if there wasn't any redundancy that
would make BSM distribution moot.
FWIW: IMHO IF we are talking about cable systems (or even DSL systems)
that are using IP multicast to distributed cable TV, and if those
companies
are depending on PIM-SM, I would FIRE the network manager and anyone
in his group that didn't understand that PIM-SM is NOT the answer to
their
problems. (ie, if their set-top box can't do IGMPv3 and MLDv2 they
need to find the idiot who suggested it would be OK.) [Can you
tell you've hit a nerve. ;p ]
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 :-).
WRT ARP and gratuitous ARPs and all the points you make. I can not
give you a good reason why it can't be fixed. I agree with you.
I can tell you that the way ARPs have been handled in routers (ok,
cisco routers) has been the same since I became aware of IP. So, WRT
your 'backward compatibility' argument, again I agree with you. Which
'backward compatibility' do you want to address? (that's a rhetorical
question.)
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.
The key here is "might be a large number" of unicast BSM deployments.
I'll need some numbers. FWIW, that "large number" will include a
lot of cisco routers and none of those work with unicast BSMs because
of the ARP question. So we'd be back to figuring out how to solve that
problem, because it does not work now.
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.
Which is true with the unicast BSM too. I don't see in the current
spec that
the RPF-check is relaxed. (you can make an argument that it should be
obvious, can't disagree with that position).
It
means a 60 second convergence delay when there are old implementations
in the network.
The reason this whole thread was started was because the "old
implementations"
weren't working for me. So I don't care. :-)
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.
Me too. Yet my testing has shown that its required. Aside from the ARP
problem, consider that it takes some time for unicast routing to
converge.
You may have other results, but in my simple topology I find that the
PIM
neighbors are discovered well before the IGP converges. And I found
many BSMs were being dropped for RPF checks.
Perhaps we didn't implement it right. :-)
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.
If it weren't for the RPF check, I could find myself agreeing with you.
I'd like to point out that solving the ARP problem is going to be
well outside of our capacity to solve. As I tried to say earlier, its
been this way 'forever'. (since '92 as far as I know -- perhaps
longer.)
I'm not trying to support this choice. Just pointing out the reality
of it.
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?
No. If downstream (which is ill-defined at this point) routes have to
do an RPF check that means that their IGP will have converged, which
means (to me) that they they have alternate paths to the BSR, which
means they didn't need the triggered BSM anyway.
FWIW, I've spent hours and hours watching this not work on a very
simple topology -- only 5 routers. I've pressured for changes and
folks have gone out of their way to try to make it work for me. It
just isn't happening. But that shouldn't be taken to mean that I'm
right. Try something else.
_______________________________________________
pim mailing list
pim at ietf.org
https://www1.ietf.org/mailman/listinfo/pim
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
