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

 > 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?

Yes, I agree.  This solution makes sense.

- Christian

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

Nick 'Sharkey' Moore wrote:
> 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
--------------------------------------------------------------------