On 22/09/2014 17:44, Andrew 👽 Yourtchenko wrote:
Its only result in a correct implementation must be "if you join the
group, you should get the traffic, if you did not, you should not"
function.
A result of composition of multiple independent correct
implementations of this function remains the same - "if you join the
group, you should get the traffic, if you did not, you should not".
Sadly, some vendors actually need that spelling out, in a way they can't
dodge. There are some very very bad IGMP/MLD snooping implementations
out there; as someone else has pointed out, failure mode on (s,g)
slot/memory exhaustion is particular pernicious. We have devices that
just stop forwarding all current and future multicast (although
thankfully flooding link-local IPv6 so ND etc. continue to work).
Vendor claims this is "expected behaviour" when "too many" hosts join
"too many" groups :o/
It would be a lot easier if a very strict (and short) RFC embodied what
you wrote above, and people could say "must be RFC xxxx compliant" under
their procurement rules. Similar to the RIPE docs for IPv6 feature set.
