>>>>> On Wed, 18 Aug 2004 20:18:27 +0200,
>>>>> "Gerrit van Niekerk" <[EMAIL PROTECTED]> said:
>> If there is something we need to care about, it would be that the
>> current text may give an impression that it suddenly starts talking
>> about the MLD implication. So, I'd like to propose a small
>> modification to the 5th paragraph of section 5.4.2:
> I support this modification; it also addresses my previous concern. I would
> just like to add a one-sentence motivation (which was my issue right from the
> start) and change the reference to RFC3590 to be more specific. Here is the
> slightly modified text:
Your suggestion looks basically fine, but I want to check one minor
point:
> Note that when a node joins a multicast address, it typically sends a Multicast
> Listener Discovery (MLD) report message [RFC2710] for the multicast address. In
> the case of Duplicate Address Detection the MLD report message is required in
> order to inform MLD-snooping switches, rather than routers, to forward the
> multicast addresses.
Do you really mean "forward the multicast addresses"? I'd say, e.g.,
"to forward packets to the multicast address".
> In the above description, the delay for joining the
> multicast address thus means delaying transmission of the corresponding MLD
> report message [RFC2710]. Since [RFC2710] does not request a random delay to
> avoid race conditions, just delaying Neighbor Solicitation would cause
> congestion by the MLD report messages. The congestion would then prevent the
> MLD-snooping switches from working correctly, and, as a result, prevent
> Duplicate Address Detection from working. The requirement to include the delay
> for the MLD report in this case avoids this scenario. [RFC3590] specifies
> which source address should be used for the MLD report when no valid local
> addresses has yet been configured.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
