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

[JINMEI Tatuya / $B?@L at C#:H(B <jinmei at isl.rdc.toshiba.co.jp>]

>>>>> On Mon, 09 Feb 2004 12:14:35 +0900, 
>>>>> JINMEI Tatuya <jinmei@isl.rdc.toshiba.co.jp> said:

>> 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."

> Hmm, I tend to agree with this wording.  Yes, this can still be
> considered as boundary violation with wording trick, but I think this
> makes it clear that the delay is only for DAD NSs and this minimizes
> effects to the MLD spec.  And, of course, this is a perfect solution
> to the collision problem.

How about this one?  (this may still be controversial, and if so,
please continue the discussion.  But since the cutoff deadline is
looming, I'll submit the draft with the proposed text below anyway.)

   If the Neighbor Solicitation is going to be the first message to be
   sent from an interface after interface (re)initialization, the node
   should delay joining the solicited-node multicast address by a random
   delay between 0 and MAX_RTR_SOLICITATION_DELAY as specified in RFC
   2461 [5]. This serves to alleviate congestion when many nodes start
   up on the link at the same time, such as after a power failure, and
   may help to avoid race conditions when more than one node is trying
   to solicit for the same address at the same time.

   Note that the delay for joining the multicast address implicitly
   means delaying transmission of the corresponding MLD report message
   [9]. Since RFC 2710 [9] does not request a random delay to avoid race
   conditions, only delaying Neighbor Solicitation would cause
   congestion by the MLD report messages. The congestion would then
   prevent 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.

   In order to improve the robustness of the Duplicate Address Detection
   algorithm, an interface MUST receive and process datagrams sent to
   the all-nodes multicast address or solicited-node multicast address
   of the tentative address while the delaying period. This does not
   necessarily conflict with the requirement that joining the multicast
   group be delayed. In fact, in some cases it is possible for a node to
   start listening to the group during the delay period before MLD
   report transmission. It should be noted, however, that in some
   link-layer environments, particularly with MLD-snooping switches, no
   multicast reception will be available until the MLD report is sent.


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------