Re: Comment on draft-ietf-ipv6-optimistic-dad-06.txt

[Christian Vogt <[e-mail]>]

 > Actually, I disagree.  In order to provide timely address
 > configuration, we MUST violate these delays.


Nick,

my assumption in writing the above text passage was that the
delays for MLD Reports should be relaxed elsewhere, e.g. as part of 
RFC2462bis.

On the other hand, thinking more about this...

...there was consensus on the IPv6 mailing list [1] not to include any
specific support for mobility into the successors to RFC2461/2462.  At
least, this was said in the context of delays imposed on MLD Report
transmissions.

(Note:  IMO, this is a bit of a bummer, because RFC2461bis already
explicitly allows mobile nodes to forego the delay for Router
Solicitations; see section 6.3.7 in RFC2461bis.  So it could 
theoretically include an equivilant passage for the MLD Report, too. 
Anyway...)

Instead, the discussion in [1] yielded that mobility optimizations ought
to be specified in separate documents.  And thinking about this, 
draft-ietf-ipv6-optimistic-dad-06.txt is actually one such document.  So 
it could/should allow Optimistic Nodes to forego the delays defined in 
RFC2461[bis] or RFC2462[bis] where necessary and feasible.

This said, the revised text passage for 
draft-ietf-ipv6-optimistic-dad-06.txt could look like this:

"The initial Neighbor Solicitation MUST be transmitted as early as
possible after the Optimistic Address has been flagged as 'Optimistic'. 
  Where other standards require the Optimistic Node to delay sending the 
initial Neighbor Solicitation for the purpose of contention resolution, 
it is RECOMMENDED that the Optimistic Node omit such delays if 
sufficient means for de-synchronization are provided otherwise.  E.g., a 
mobile node can omit delaying the first message sent upon arrival at a 
new link [RFC2461] [RFC2462] because mobility generally serves to 
de-synchronize signaling to an appropriate extent already.  Care must be 
taken, however, not to confuse an initial link attachment after boot-up 
with a link attachment after movement."

Note that this text implicitly attends to delays on MLD Reports as 
specified in RFC2462bis.  It is also general enough to deal with L2 
technologies that have no collision avoidance (even though I agree with 
you that L2 collision avoidance should be left to L2 in any case).

One could argue for changing "it is RECOMMENDED that the Optimistic Node 
omit such delays if..." to "the Optimistic Node MUST omit such delays 
if...", but I'd prefer the less strict version.

Regards,
- Christian

[1]  "Comment on RFCs 2461bis and 2462bis", Discussion on the IPv6
      mailing list, May 27, 2005, <http://www1.ietf.org/mail-archive/
      web/ipv6/current/msg05084.html>.

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/


Nick 'Sharkey' Moore wrote:
> On 2005-10-19, Christian Vogt wrote:
> 
>>"The initial Neighbor Solicitation MUST be transmitted as early as
>>possible after the Optimistic Address has been flagged as 'Optimistic',
>>but it MUST NOT violate any delays or rate limitations set forth by
>>RFC2461 or RFC2462.
> 
> 
> Actually, I disagree.  In order to provide timely address configuration,
> we MUST violate these delays.  
> 
> As I understand it, until we've performed the MLD report, we can't
> reliably receive NSes ... and thus we may not be able to send our
> NA(O=0) and can't respond to communications!
> 
> Also, the longer we delay the NS, the longer we have to wait to discover
> a collision.  This is a big disadvantage to the arriving node, because
> in the case of a collision it's not getting any traffic.  It's also
> a small disadvantage to the collidee, because it may get traffic 
> which was meant for the arriving ON.
> 
> I think L2 collision avoidance is best left to L2 in any case.
> Elimination of these delays was proposed by some "Fast RS" draft
> or another at some point, although I don't think I ever wrote up
> the Soft vs. Hard Handover draft I'd been intending to ...
> 
> -----Nick


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