Group management protocols can be considered a low-level member of the routing protocols. That means, random delays in sending state changes affect the routing/forwarding infrastructure of the network. Introducing delays in the sending of those state changes doesn't seem to be the approach to take here. And reliability is addressed by scheduling multiple Report messages to be transmitted.
I agree that group management protocols can be consider to be routing protocols. But in the case that we are talking about here, the multicast address is a link local mc address. As a result, the routing/forwarding infrastructure of the network is not affected, as far as I can see. It is possible that some L2 device is affected. And the router will process the MLD message. But (perhaps I'm dense) I don't see how a router would change its routing or forwarding behaviour due to seeing a change in the link local multicast behaviour.
Even if there would be a change, I do not see why it follows that delays are prohibited. As I see it, we have a number of somewhat conflicting factors:
- desire to provide service in a timely manner - desire to avoid packet storms upon booting many nodes simultaneously - desire to accommodate snooping switches
The second factor may dictate that some delay be used, even if the first factor would lead to sending all messages immediately.
Also, Jinmei wrote:
Regarding option 3:
pro: this is a complete solution of the problem, which works with
MLD snooping switches
con: this can be regarded as spec-violation, and we may have to
worry about conflict with MLD updates in the future
Why do you consider this as a spec violation? Because then 2462bis would appear to say something that is different than what MLD specs say, or because ND specs should not say anything about MLD?
I think the right engineering solutions should be adopted, without too much regard into the documentation boundaries. Having said that, if you worry about the document boundary, you can simply say "delay joining to the multicast group by a random delay. Once you have joined, send the ND packet."
--Jari
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
