Re: [rfc2462bis issue 274] conflict between MLD and NS delay

[Jari Arkko <jari.arkko at kolumbus.fi>]

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.

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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------