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

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 10 Feb 2004 19:00:04 +0900

>>>>> On Mon, 09 Feb 2004 06:24:26 -0500, 
>>>>> Brian Haberman <[email-masked]> said:

>> I think what Jari asked was not a modification to the semantics
>> of reporting group joins.
>> 
>> I think that what Jari proposed was actually that we delay DAD
>> (which entails both the operation of beginning listening to
>> a group and the NS transmission).

> So, in logic-wise it would look like:

>      1. Generate the solicited-node multicast address
>      2. Wait for random timer expiry
>      3. Perform ADD_MEMBERSHIP call on the socket
>      4. Send DAD

> I think I can live with that for the time being.

In my latest proposal, the behavior is a bit different:

      1. Generate the solicited-node multicast address
      2. Perform ADD_MEMBERSHIP call on the socket (or equivalent) but
         not send MLD, i.e., start listening to the multicast address
      3. Wait for random timer expiry
      4. send MLD
      5. Send DAD

The reason for doing 2 before the random delay is because we need to
listen to the multicast address to improve the reliability of DAD.

The reason for doing 3 (random delay) before sending MLD is for
avoiding collisions.

Would you still live with this?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 09 Feb 2004 01:34:15 +0900

>>>>> On Sun, 08 Feb 2004 09:02:54 -0500, 

> Given my point above, I would argue that we shouldn't add a delay to
> MLD messages.

So, do you have any opinion among the options I raised in this thread?

1. no change in rfc2462bis (expecting MLDv1 and/or MLDv2 will
   eventually be updated with a random delay)
2. the original proposal of mine (expecting MLDv1 and/or MLDv2 will
   eventually be updated with a random delay):
   impose a random delay even for the first NS after the corresponding
   MLD when the sending node knows there is no delay for the MLD.
3. Greg's suggestion:
   require a random delay before the first MLD (in rfc2462bis).

(including "4. none of above").

Apparently you'd reject option 3 from your point.  I also know that
you are NOT expecting MLDv1/v2 will be updated with a random delay,
even if you prefer option 1 or 2 itself.

					JINMEI, Tatuya