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 t

RE: Optimistic DAD draft ...

ove quickly, or making sure a stationary node is not interrupted??? Tony > -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] > S

RE: Optimistic DAD draft ...

on, not after. 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 ... > > >

RE: Optimistic DAD draft ...

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] &

Re: Optimistic DAD draft ...

s that decision, not > after. > > 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]

Re: Optimistic DAD draft ...

On Tue, Oct 15, 2002 at 01:21:16PM -0700, Tony Hain wrote: > Without having read the draft, it occurs to me that the whole idea of > DAD latency impacting hand-offs is a self inflicted problem. From the > perspective of 'failure to plan on your part does not constitute an > emergency on my part',

Re: Optimistic DAD draft ...

On Tue, Oct 15, 2002 at 02:46:55PM -0700, Charles E. Perkins wrote: > > It is possible to have nice handoffs even with > break-before-make, as long as "break" is not > too lengthy. If the determination about the > destination network is available in time, completing > DAD before switching is a

RE: Optimistic DAD draft ...

inline > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of Charles > E. Perkins > Sent: Tuesday, October 15, 2002 2:47 PM > To: [EMAIL PROTECTED] > Cc: 'Pekka Savola'; 'Nick 'Sharkey' Moore'; [E

Re: Optimistic DAD draft ...

sday, 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 M

Re: Optimistic DAD draft ...

On Tue, Oct 15, 2002 at 03:18:34PM -0700, Tony Hain wrote: > > It seems like this would be a bigger latency concern than DAD. 1000ms is a long time by anyone's standards! > Maybe I just don't understand the technology well enough, but I from my > limited perspective it would seem that the curre

RE: Optimistic DAD draft ...

inline > -Original Message- > From: Alper E. YEGIN [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, October 15, 2002 3:12 PM > To: [EMAIL PROTECTED]; 'Pekka Savola' > Cc: 'Nick 'Sharkey' Moore'; [EMAIL PROTECTED] > Subject: Re: Optimistic DAD d

Re: Optimistic DAD draft ...

"anticipate movement". Not all link-layers have this capability. alper > > Tony > > > > > alper > > > > > > > > > > > > > > Tony > > > > > > > -Original Message- > > > > From: Pekka S

RE: Optimistic DAD draft ...

Alper E. YEGIN wrote: > ... > We cannot assume all MNs can "anticipate movement". Not all > link-layers > have this capability. A MN 'can anticipate movement' because that is what it does by definition. What it may not be able to figure out is the candidate list of where it may end up. The fact

Re: Optimistic DAD draft ...

Tony, > > ... > > We cannot assume all MNs can "anticipate movement". Not all > > link-layers > > have this capability. > > A MN 'can anticipate movement' because that is what it does by > definition. What it may not be able to figure out is the candidate list > of where it may end up. What I re

Re: Optimistic DAD draft ...

Hi Alper, > > Sure. Actually, my comment is not against what you are saying here. > I guess an approach like a proxy-DAD can be a candidate solution > to this problem. Another candidate is server-based DAD that I'm > currently working on. It involves a server keeping track of > currently used IP

RE: Optimistic DAD draft ...

[EMAIL PROTECTED] Subject: Re: Optimistic DAD draft ... On Tue, Oct 15, 2002 at 03:18:34PM -0700, Tony Hain wrote: > > It seems like this would be a bigger latency concern than DAD. 1000ms is a long time by anyone's standards! > Maybe I just don't understand the technology wel

RE: Optimistic DAD draft ...

ore'; [EMAIL PROTECTED] Subject: RE: Optimistic DAD draft ... inline > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of Charles > E. Perkins > Sent: Tuesday, October 15, 2002 2:47 PM > To: [EMAIL PROTECTED] > Cc: 'Pekk

RE: Optimistic DAD draft ...

PROTECTED]; 'Pekka Savola' Cc: 'Nick 'Sharkey' Moore'; [EMAIL PROTECTED] Subject: Re: Optimistic DAD draft ... > > > True, but the term 'hand-off' implies a make-before-break process, > > > else the MN is just establishing itself on a ne

RE: Optimistic DAD draft ...

--Original Message- From: Alper E. YEGIN [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 5:12 PM To: [EMAIL PROTECTED]; 'Pekka Savola' Cc: 'Nick 'Sharkey' Moore'; [EMAIL PROTECTED] Subject: Re: Optimistic DAD draft ... Hi Tony, > True, but the

Re: Optimistic DAD draft ...

IN [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, October 15, 2002 5:43 PM > To: [EMAIL PROTECTED]; 'Pekka Savola' > Cc: 'Nick 'Sharkey' Moore'; [EMAIL PROTECTED] > Subject: Re: Optimistic DAD draft ... > > > > > > True, but the term 'ha

Re: Optimistic DAD draft ...

PM > To: [EMAIL PROTECTED]; 'Pekka Savola' > Cc: 'Nick 'Sharkey' Moore'; [EMAIL PROTECTED] > Subject: Re: Optimistic DAD draft ... > > > > > Hi Tony, > > > True, but the term 'hand-off' implies a make-before-break process, &

Re: Optimistic DAD draft ...

Hello Jim, Layer 3 handover definitely can and does work. We have been showing smooth layer-3 handover for voice for almost two years now, even with conference demos and press releases, using Mobile IPv6. Improvements have been done for QoS and several other features which aren't the point of th

RE: Optimistic DAD draft ...

this and agreement on MIPv6 movement. We can't even get MIPv6 PS in the IETF. Thanks /jim -Original Message- From: Charles E. Perkins [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 1:11 PM To: Bound, Jim Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Optimisti

RE: Optimistic DAD draft ...

-Original Message- From: Alper E. YEGIN [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 1:10 PM To: Bound, Jim; [EMAIL PROTECTED]; Pekka Savola Cc: Nick 'Sharkey' Moore; [EMAIL PROTECTED] Subject: Re: Optimistic DAD draft ... Jim, > None of us working on this are eve

Re: Optimistic DAD draft ...

16, 2002 1:11 PM > To: Bound, Jim > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Optimistic DAD draft ... > > Hello Jim, > > Layer 3 handover definitely can and does work. > We have been showing smooth layer-3 handover for > voice for almost two years now, ev

Re: Optimistic DAD draft ...

On Wed, Oct 16, 2002 at 11:15:50AM -0400, Bound, Jim wrote: > [Nick 'Sharkey' Moore wrote:] > > 1000ms is a long time by anyone's standards! > > I simply cannot believe it is 1000 ms. Like I said lets get some > empircal data. I was referring to the DAD delay, eg: RETRANS_TIMER from RFC 2461. W

Re: Optimistic DAD draft ...

On Wed, Oct 16, 2002 at 11:07:55AM -0700, Alper E. YEGIN wrote: > > As far as I understand, people are not suggesting changing DAD, but instead > developing an optimized version of it. Both versions should be able > to co-exist, no interference. That's exactly right, Alper. My reason for using

Re: Optimistic DAD draft ...

On Wed, Oct 16, 2002 at 11:18:52AM -0400, Bound, Jim wrote: > Alper, > > None of us working on this are even clear layer 3 handover will ever > work? Not sure if that matters does it? Are we talking about the > future? We're pretty clear on this: we've tested it. The significant delays are:

RE: Optimistic DAD draft ...

E. Perkins [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 2:47 PM To: Bound, Jim Cc: [EMAIL PROTECTED] Subject: Re: Optimistic DAD draft ... Hello Jim, "Bound, Jim" wrote: > Test beds are good. But no one is going to use it till we make sure it > works across

RE: Optimistic DAD draft ...

Nick, 100% agree. /jim -Original Message- From: Nick 'Sharkey' Moore [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 6:24 PM To: Bound, Jim Cc: Tony Hain; Charles E. Perkins; Pekka Savola; [EMAIL PROTECTED] Subject: Re: Optimistic DAD draft ... On Wed, Oct 1

RE: Optimistic DAD draft ...

hanks /jim -Original Message- From: Nick 'Sharkey' Moore [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 6:46 PM To: Bound, Jim Cc: Alper E. YEGIN; [EMAIL PROTECTED]; Pekka Savola; [EMAIL PROTECTED] Subject: Re: Optimistic DAD draft ... On Wed, Oct 16, 2002 at 1

Re: Optimistic DAD draft ...

On Thu, Oct 17, 2002 at 02:34:59AM -0400, Bound, Jim wrote: > From: Nick 'Sharkey' Moore [mailto:[EMAIL PROTECTED]] > > > Bound, Jim wrote: > > > > > > None of us working on this are even clear layer 3 handover will ever > > > work? Not sure if that matters does it? Are we talking about the >

RE: Optimistic DAD draft ...

> To clarify: we've been doing some work to identify and isolate > the causes of L3 handover delays, and they each seem solvable > by one means or another. > > For example, hmipv6 offers one possible way of eliminating the RTT > delay caused by sending BUs. In its current form, it pr

Re: Optimistic DAD draft ...

On Tue, Oct 22, 2002 at 10:22:54AM -0400, Sowmini Varadhan wrote: > > I think this was discussed in the past: check out the thread with the > subject "ND- processing neighbor advertisements" in > ftp://playground.sun.com/pub/ipng/mail-archive/ipng.199912 Hmmm. Interesting, and opens rather a ca

Re: Optimistic DAD draft ...

On Fri, Oct 18, 2002 at 08:48:46AM +0300, Pekka Savola wrote: > > This sounds rather good, using the lower case, of course. Of course. I'll clarify the details for -01. Thanks for your feedback. > I don't have figures but Francis Dupont reported this happening once to > him. > It should also be

Re: Optimistic DAD draft ...

On Tue, Oct 15, 2002 at 12:58:00PM +1000, Nick 'Sharkey' Moore wrote: > 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

Re: Optimistic DAD draft ...

On Fri, Oct 18, 2002 at 08:48:46AM +0300, Pekka Savola wrote: > > > I'd be really interested to know if anyone has any indicative > > figures on MAC address collision: it is inevitable that somewhere > > out there there are two adaptors with the same MAC address due > > to human frailties, but how

Re: Optimistic DAD draft ...

Nick I haven't made up my mind yet about this draft, but here are some comments. - Sections 2.1 and 2.2 are not very clear. For example, in section 2.2 there are two bullets that modify section 5.4.3, but these 2 bullets are very ambigiouse as to what parts of [rfc2462 sec. 5.4.3] they apply to

Re: Optimistic DAD draft ...

> > For manually assigned addresses, I believe the ratio is closer > > to 1:10 or 1:100 (unmeasurable, of course). > > I'd be really interested to know if anyone has any indicative > figures on MAC address collision: it is inevitable that somewhere > out there there are two adaptors with the same

RE: Optimistic DAD draft ...

to do. /jim > -Original Message- > From: Nick 'Sharkey' Moore [mailto:sharkey@;zoic.org] > Sent: Thursday, October 17, 2002 8:37 PM > To: Bound, Jim > Cc: James Kempf; Alper E. YEGIN; Pekka Savola; > [EMAIL PROTECTED] > Subject: Re: Optimistic DAD draft ... &

RE: Optimistic DAD draft ...

> - Section 3.1 of the draft states: > > > ...Since the Optimistic Node already has the > link-layer > > address of the router, and the router now has the > link-layer address > > of the Optimistic Node, communications can begin immediately. > > Wher

Re: Optimistic DAD draft ...

is > > in *some* cases, in particular autoconfigured vs privacy addresses. > > I see what you mean. I need to make it clear that [SOTO] and I are > referring to strongly random addresses ... this is a requirement > for my Optimistic DAD draft anyway for exactly this reason. Yep.

Re: Optimistic DAD draft ...

Pekka, > 2) I'm not sure if this is the right approach. Something better suited > could be found, I believe, in adding functionality to first-hop routers' > ND cache behaviour; a router could answer directly which could be > interpreted like "don't use that address, I just recently saw it used h

Re: Optimistic DAD draft ...

On Fri, Oct 18, 2002 at 01:18:57PM -0400, Vladislav Yasevich wrote: > > - Sections 2.1 and 2.2 are not very clear. For example, in > section 2.2 there are two bullets that modify section 5.4.3, > but these 2 bullets are very ambigiouse as to what parts of > [rfc2462 sec. 5.4.3] they apply to.

Re: Optimistic DAD draft ...

On Fri, Oct 18, 2002 at 05:26:22PM -0700, Alper E. YEGIN wrote: > Pekka Savola wrote: > > > > 2) I'm not sure if this is the right approach. Something better suited > > could be found, I believe, in adding functionality to first-hop routers' > > ND cache behaviour; > > This is the approach I've

Re: Optimistic DAD draft ...

On Fri, 18 Oct 2002, Alper E. YEGIN wrote: [...] > >Optimistic DAD is a useful optimization because DAD is far more > >likely to succeed than fail, by a factor of at least 10,000,000,000 > >to one[SOTO]. This makes it worth a little disruption in the failure > >case to provide fast

Re: Optimistic DAD draft ...

On Mon, Oct 21, 2002 at 10:27:48AM -0400, Vladislav Yasevich wrote: > [Nick Moore wrote:] > > > A NA with S=0,O=0 for a REACHABLE entry will have no effect on the > > entry according to the Appendix C state machine, and these are the > > only NAs which the ON will sent to All Nodes which Tentative.

Re: Optimistic DAD draft ...

Hi Alper, Sorry about the delayed response. Possibly unhelpful responses below... Alper E. YEGIN wrote: Pekka, 2) I'm not sure if this is the right approach. Something better suited could be found, I believe, in adding functionality to first-hop routers' ND cache behaviour; a router could an

RE: Optimistic DAD draft ...

> > > A NA with S=0,O=0 for a REACHABLE entry will have no > effect on the > > > entry according to the Appendix C state machine, and > these are the > > > only NAs which the ON will sent to All Nodes which Tentative. > > > Admittedly an NA with S=1,O=0 will reset a REACHABLE > entry to STALE

Re: Optimistic DAD draft ...

>> Vendors who ship e.g. 4-port Ethernet adapters (e.g some Sun products) >> with the same mac address in each port are problematic of course (and this >> isn't the first time -- switches usually don't like it:-). If you connect >> two ports to the same segment.. >Is that common? for

RE: Optimistic DAD draft ...

>Optimistic DAD is a useful optimization because DAD is far more >likely to succeed than fail, by a factor of at least > 10,000,000,000 >to one[SOTO]. This makes it worth a little disruption > in the failure >case to provide faster handovers in the successful case,

RE: Optimistic DAD draft ...

On Thu, 17 Oct 2002, Hesham Soliman (EAB) wrote: > >Optimistic DAD is a useful optimization because DAD is far more > >likely to succeed than fail, by a factor of at least > > 10,000,000,000 > >to one[SOTO]. This makes it worth a little disruption > > in the failure > >

Re: Optimistic DAD draft ...

Nick, > For example, hmipv6 offers one possible way of eliminating the RTT > delay caused by sending BUs. In its current form, it probably > isn't scalable to that level, but sadly I don't have a megapolis > to test it with -- I'm a research engineer not a product engineer :-) > With the latest F

Re: Optimistic DAD draft ...

On Tue, 15 Oct 2002, Nick 'Sharkey' Moore wrote: A few comments on some portions of the draft. On the general approach, first: 1) the draft needs to spell out much more clearly how the modifications to RFC2461/RFC2462 (and whether they have been done) affect on the behaviour on the links wher

RE: Optimistic DAD draft ...

ber 17, 2002 2:45 AM To: Bound, Jim Cc: Alper E. YEGIN; [EMAIL PROTECTED]; Pekka Savola; [EMAIL PROTECTED] Subject: Re: Optimistic DAD draft ... On Thu, Oct 17, 2002 at 02:34:59AM -0400, Bound, Jim wrote: > From: Nick 'Sharkey' Moore [mailto:sharkey@;zoic.org] > > > Bound, Ji

RE: Optimistic DAD draft ...

tober 17, 2002 10:25 AM To: Nick 'Sharkey' Moore; Bound, Jim Cc: Alper E. YEGIN; Pekka Savola; [EMAIL PROTECTED] Subject: Re: Optimistic DAD draft ... Nick, > For example, hmipv6 offers one possible way of eliminating the RTT > delay caused by sending BUs. In its current fo

Re: Optimistic DAD draft ...

ed to make it clear that [SOTO] and I are referring to strongly random addresses ... this is a requirement for my Optimistic DAD draft anyway for exactly this reason. Do you this it is fair to say: DAD is far more likely to succeed than fail FOR RANDOMLY AUTOCONFIGURED ADDRESSES, by a fac

Re: Optimistic DAD draft ...

G'day James, On Thu, Oct 17, 2002 at 08:24:36AM -0700, James Kempf wrote: > > With the latest FMIPv6 draft, HMIP isn't really necessary as a handover > optimization technology, though it can contribute if routers supporting > FMIPv6 are not an option. With all the ... uh ... debate surrounding F

Re: Optimistic DAD draft ...

On Thu, Oct 17, 2002 at 06:24:24PM -0400, Bound, Jim wrote: > Nick per hmip I rest my case :---) below. I don't have and opinion not > my discipline but I would like to see James, Hesham, you, et al agree > :) How about for the greater good :--) Should our opinions collide, we'll reconfigure

Re: Optimistic DAD draft ...

On Thu, Oct 17, 2002 at 11:23:25AM +0200, Hesham Soliman (EAB) wrote: > > > For example, hmipv6 offers one possible way of eliminating the RTT > > delay caused by sending BUs. In its current form, it probably > > isn't scalable to that level, > > => Why not? I think it is scalable to that

RE: Optimistic DAD draft ...

> > => Why not? I think it is scalable to that level simply > > because you can plug more anchor points as you see > > fit. it's as scalable as HAs are in MIPv6. > > My main concern would be issues to do with the MAP information > propagation, and the MAP selection algorithm ... I t