> > > True, but the term 'hand-off' implies a make-before-break process, > > > else the MN is just establishing itself on a new link. Given it has > > > the opportunity to be aware of multiple links, it can > > decide when to > > > switch. I am arguing that it complete DAD 'before' it makes that > > > decision, not after. > > > > I don't think we can consider all "handoffs" as > > 'make-before-break'. There exists some link-layer > > technologies that allow this, but not all have such capability. > > Then DAD latency should be the least of the concerns.
Not really. For example 802.11b (link-layer) handover can take something like 200ms, and DAD would take 1sec on that link. People are already working on shrinking link-layer handover latency, and some should do the same for DAD as well. > > > > > Completing DAD before handover requires either movement > > anticipation or make-before-break, both of which are not > > widely applicable. Therefore solving DAD latency for general > > case is a valid approach, imo. > > My argument is that all MNs anticipate movement, and establish DAD > before they really make the move. Yes this will generate some overhead > if the node doesn't move, but that is a minor cost in the grand scheme > of things. We cannot assume all MNs can "anticipate movement". Not all link-layers have this capability. alper > > Tony > > > > > alper > > > > > > > > > > > > > > Tony > > > > > > > -----Original Message----- > > > > From: Pekka Savola [mailto:[EMAIL PROTECTED]] > > > > Sent: Tuesday, October 15, 2002 1:32 PM > > > > To: Tony Hain > > > > Cc: 'Nick 'Sharkey' Moore'; [EMAIL PROTECTED] > > > > Subject: RE: Optimistic DAD draft ... > > > > > > > > > > > > On Tue, 15 Oct 2002, Tony Hain wrote: > > > > > [...] it would seem the prudent thing for a MN to do is > > > > establish DAD > > > > > for all candidate prefixes well before it is ready to > > start using > > > > > them. [...] > > > > > > > > Isn't there a problem with how this could be done, as > > > > currently specified? > > > > > > > > One can't perform DAD before being on the link. > > > > > > > > > > -----Original Message----- > > > > > > From: [EMAIL PROTECTED] > > > > > > [mailto:[EMAIL PROTECTED]] On Behalf Of Nick > > > > > > 'Sharkey' Moore > > > > > > Sent: Monday, October 14, 2002 7:58 PM > > > > > > To: [EMAIL PROTECTED] > > > > > > Subject: Optimistic DAD draft ... > > > > > > > > > > > > > > > > > > G'day IPng-ers, > > > > > > > > > > > > One of the big issues in getting low-latency > > > > > > handovers working for IPv6 mobility is the long delay > > involved > > > > > > in > > > > > > completing DAD. > > > > > > > > > > > > One option is to allow the Mobile Node to communicate > > while the > > > > > > address is still Tentative (optimistically assuming that DAD > > > > > > will succeed), but to adjust its ND / SAA behaviour > > in order to > > > > > > minimize disruption in case of an address conflict > > (and maintain > > > > > > correct interoperation with > > > > unmodified nodes). > > > > > > > > > > > > We've kicked the idea around a little on mobile-ip, > > > > > > and I've formalized my thoughts into an internet draft, > > > > which should > > > > > > get published soon. In the meantime, you can find it at > > > > > > <http://www.ctie.monash.edu.au/ipv6/fastho.htm> > > > > > > (tentatively titled draft-moore-ipv6-optimistic-dad-00). > > > > > > > > > > > > I'd be interested in your opinions on the > > draft, and its > > > > > > potential suitability for standards track. > > > > > > > > > > > > > > > > > > cheers, > > > > > > Nick > > > > > > -- > > > > > > Nick 'Sharkey' Moore > > <[EMAIL PROTECTED]> > > > > > > Research Fellow, CTIE Tel: +61 3 9905 3707 > > > > > > Monash University, Australia Fax: +61 3 9905 5358 > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > IETF IPng Working Group Mailing List > > > > > > IPng Home Page: > > > > http://playground.sun.com/ipng > > > > > > FTP archive: > > > > ftp://playground.sun.com/pub/ipng > > > > > > Direct all administrative requests to > > > > [EMAIL PROTECTED] > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------ > > > > > -- > > > > > IETF IPng Working Group Mailing List > > > > > IPng Home Page: > > http://playground.sun.com/ipng > > > > > FTP archive: > > ftp://playground.sun.com/pub/ipng > > > > > Direct all administrative requests to > > [EMAIL PROTECTED] > > > > > > > -------------------------------------------------------------------- > > > > > > > > > > > > > -- > > > > Pekka Savola "Tell me of difficulties surmounted, > > > > Netcore Oy not those you stumble over and fall" > > > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: http://playground.sun.com/ipng > > > FTP archive: ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to [EMAIL PROTECTED] > > > -------------------------------------------------------------------- > > > > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
