[pim] Re: Simple join failure notification for PIM-SM multicast routing

[hoerdt at clarinet.u-strasbg.fr]

The draft will be presented and discussed at the 66th IETF PIM working
group by Stig Venaas. In the meantime, here are some thought in 
reaction to the excellents comments that we got so far from

http://www.ietf.org/internet-drafts/draft-hoerdt-pim-group-unreachable-00.txt

The lacks of IPv6 mtrace on the M6bone motivate us to push this
forward. We have stopped to count the number of times that we have to
help user to debug IPv6 multicast connectivity without actually
knowing where the error could have happened, and the M6bone is still
an small network. To debug one group/channel we had to look for the
presence of TIB states at each routers on the path making this very
costly. And if the error is outside of your domain, the only thing we
could said was "Multicast is not working in your domain, please debug
it".

The idea is designed to be simple and deployed on all routers,
letting network administrator spotting where and when there are
failures in the PIM protocol without mtracing whenever there is an
error report. If they know the address of the router where the
(temporary or periodic) error occured, they can contact the right
person responsible of the domain and ask to fix it if they are not
already working on it.

This draft only documents how and why and when the error is
propagated. We did not mention how to use actually the message,
believing that it was out of scope of the document. We agree that what
is proposed is basically a PIM-NAK. Wether we call this a PIM-NACK or
a Tree Unreachable, the core idea of this proposition document a
way to do on-line error reporting within PIM-SM.

One may think "Just don't do it, use mtrace", but the approach is
different from an off-line error testing like mtrace and could
potentially be used to design an automatic DDOS protection mechanism.
Wether it's off-line or on-line, we definitly want to push forward the
idea of helping administrator to manage multicast forward to enhance
the M6bone. We don't think that the primary idea of sending a PIM-NACK
down to the tree is too costly in comparison of its potential usage.

The error  could logged by MIB traps like said Toerless.  A user can
still report to it's network administrator that he can't connect to
some contents, the network administrator could then lookup into the
MIBs and advise what to do next. And even if no user report that it's
not working, a network administator should maintain the number of Tree
Unreachable routing errors as low as possible being be done without
"spreading the panic".

To avoid the side attacks possibility mentionned by Rami, It could be
decided to filter the message at the router edges, thus eliminating an
information that could be used by hosts to counter-side a DDOS attack.
The fact is, that without any feedback from the point of failure down
to the tree, PIM-SM control plane attacks are still very easy.

Hoerdt Mickael

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