Re: Incremental De-sync. for OptiDAD? (was Re: Comment on draft-ietf-ipv6-optimistic-dad-06.txt)

On 2005-11-06, Christian Vogt wrote:
> 
> I see, it's an implementation issue.

Sadly, true.  Whilst we're not really meant to worry about these,
sometimes they can't be ignored.

> (3)  Given that you cannot really know whether the ON is stationary or
> mobile, the following may be a good approach:  Send the pair of MLD
> Report and NS multiple times with incremental de-synchonization delays,
> but allow for immediate use of the OA:

Now, I'm not saying that this is a bad idea, but I do think it's
adding unwarranted complexity for OptiDAD's purposes.

On the other hand, a more flexible desync backoff algorithm might
e a good research paper topic perhaps.

Given that the original (RFC2462, 5.4.2) is a "should delay":
|
| If the Neighbor Solicitation is the first message to be sent from an
| interface after interface (re)initialization, the node should delay
| sending the message by a random delay between 0 and
| MAX_RTR_SOLICITATION_DELAY as specified in [DISCOVERY].

I'm happy to just recommend a "SHOULD NOT delay" in OptiDAD, as this
was something I'd been assuming all along.  Does anyone in here object?

-----Nick

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