Jari Arkko wrote:
Brian Haberman wrote:
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.
In the case of link-local addresses, a router would not change its behavior. L2 switches that implement snooping will.
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
2710 does this by mandating that nodes that join a multicast group send N Report messages immediately.
- desire to avoid packet storms upon booting many nodes simultaneously
2710 accomplishes this by using message suppression. If a node hears a Report for the same group, it cancels the transmission of any pending Reports it has for the group.
- 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?
It is not that it shouldn't say anything about MLD, I believe the comment is directed at the fact that in this case, 2462bis would contradict what is documented in the current MLD specs.
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."
So you want to impose this delay factor on all multicast groups? Or do you want the MLD spec to be more complicated and say do X for link-local groups and Y for all other scopes?
I definitely want to avoid having that kind of logic in the MLD specs.
Overall, I think the biggest issue here is the differences in the way MLD and ND were designed. And we have additional complexity in the fact that MLDv1 and MLDv2 have some fundamental differences in how they behave.
Regards, Brian
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
