Subject: RE: Optimistic DAD draft ...

From: "Bound, Jim" <[email-masked]>
Date: Wed, 16 Oct 2002 11:16:54 -0400

I do understand it exactly and you are 100% correct.

Lets do some testing.

/jim

-----Original Message-----
From: Tony Hain [mailto:[email-masked]] 
Sent: Tuesday, October 15, 2002 5:19 PM
To: 'Charles E. Perkins'
Cc: 'Pekka Savola'; 'Nick 'Sharkey' Moore'; [email-masked]
Subject: RE: Optimistic DAD draft ...

inline

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Charles 
> E. Perkins
> Sent: Tuesday, October 15, 2002 2:47 PM
> To: [email-masked]
> Cc: 'Pekka Savola'; 'Nick 'Sharkey' Moore'; [email-masked]
> Subject: Re: Optimistic DAD draft ...
> 
> 
> 
> Hello Tony,
> 
> It is possible to have nice handoffs even with
> break-before-make, as long as "break" is not
> too lengthy.   

It seems like this would be a bigger latency concern than DAD.

> If the determination about the
> destination network is available in time, completing
> DAD before switching is a good idea -- whether or
> not the handoff is "break-before-make".

Maybe I just don't understand the technology well enough, but I from my
limited perspective it would seem that the current GGSN would know which
radio system the MN was attached to, and therefore could figure out the
candidate set of destinations for a hand-off. That list could be
forwarded to the MN, so personal policy and signal strength could be
applied to sort the list to come up with the best candidates. With that
an out of band predictive DAD could be done. This would make much more
sense than moving, stepping on an existing node, then backing off. It
seems that a little bit of overhead traffic is better than dropping 2
connections.  

> 
> This is under discussion within the seamoby working
> group.  We have a draft about it, and an optimistic
> DAD scheme.  When my head rises more than an millimeter
> above water, I'll read the draft in the Subject: line
> (glub, glub).
> 
> Regards,
> Charlie P.
> 
> 
> Tony Hain wrote:
> > 
> > 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.
> > 
> > Tony
> > 
> > > -----Original Message-----
> > > From: Pekka Savola [mailto:[email-masked]]
> > > Sent: Tuesday, October 15, 2002 1:32 PM
> > > To: Tony Hain
> > > Cc: 'Nick 'Sharkey' Moore'; [email-masked]
> > > 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-masked]
> > > > > [mailto:[email-masked]] On Behalf Of Nick 
> > > > > 'Sharkey' Moore
> > > > > Sent: Monday, October 14, 2002 7:58 PM
> > > > > To: [email-masked]
> > > > > 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-masked]>
> > > > > 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-masked]
> > > > >
> > > 
> --------------------------------------------------------------------
> > > > >
> > > >
> > > >
> > > > 
> ------------------------------------------------------------------
> > > > --
> > > > 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-masked]
> > > > 
> --------------------------------------------------------------------
> > > >
> > >
> > > --
> > > 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-masked]
> > --------------------------------------------------------------------
> --------------------------------------------------------------------
> 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-masked]
> --------------------------------------------------------------------
> 

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

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

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 16 Oct 2002 14:33:47 -0400

How can mobile IPv6 in the market without at least PS and LMM is still a
discussion which I believe is required and as you know I say use AAAv6
instead of overhead of Ipsec.

Now if you mean we can move in the market as vendors without the IETF I
agree but that has not happened yet.

/jim

-----Original Message-----
From: Alper E. YEGIN [mailto:[email-masked]] 
Sent: Wednesday, October 16, 2002 1:10 PM
To: Bound, Jim; [email-masked]; Pekka Savola
Cc: Nick 'Sharkey' Moore; [email-masked]
Subject: Re: Optimistic DAD draft ...

Jim,

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

You mean Mobile IPv6? It works.

alper

> Thanks
> From: Alper E. YEGIN [mailto:[email-masked]]
> Sent: Tuesday, October 15, 2002 5:43 PM
> To: [email-masked]; 'Pekka Savola'
> > > > 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

> > > > 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
> > > > 
> > > > > > > One of the big issues in getting low-latency handovers
> > > > > > > working for IPv6 mobility is the long delay
> > > involved
> > > > > > > in
> > > > > > > completing DAD.
> > > > > > > 
> > > > > > > address is still Tentative (optimistically assuming that 
> > > > > > > DAD will succeed), but to adjust its ND / SAA behaviour
> > > in order to
> > > > > > > We've kicked the idea around a little on mobile-ip, and 
> > > > > > > I've
>

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 17 Oct 2002 02:07:34 -0400

Charlie,

Yes clarify for the future.  I am a PRODUCT engineer not research.  I
only care when it gets close to product.  Clearly test beds are
different.

Pessimistic.  Excuse me but I see nothing optimistic because I have
heard it all to often.  So don't even give me that at all.  I do think
its closer though and yes I am tracking it as painful as I find it.

As far as custom platforms.  That might be true but at times the market
won't wait.  That will happen very soon and new specs will show up that
work from the market.

Regards,
/jim

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]] 
Sent: Wednesday, October 16, 2002 2:47 PM
To: Bound, Jim
Cc: [email-masked]
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 many products.

Of course, people in general can't use it until it's productized.
And, productization depends on standardization.  However, I was
responding to your sentence:

> work?

I am providing the information that it DOES work.  How long it
takes to get to market will depend on things other than whether
the technology is workable.  In fact, the very things you pointed
out.

>                             I would not put my shit on the line for
> anyones implementation of layer 3 such as a soldier or hospital
> emergency rescue team.  Nor for IPv6 at this time.

Well, you could, but without products it would be hard.
But productization and standardization have been hindered
by factors which would not be important for the applications
that you indicated.  On the other hand, it's easier to write
applications for products (vs. custom platforms) because it
is easier to fund because there's more profit in it.

> I would like to see specs for this and agreement on MIPv6 movement. We
> can't even get MIPv6 PS in the IETF.

We are currently busting our tails to respond to Working Group
Last Call comments, and we are down to the end.  You can see
the progress by looking at our page of issues:
    http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html

Everyone knows it's been a long and contentious process.
However, pessimism is not justified by current events.

Regards,
Charlie P.

> From: Charles E. Perkins [mailto:[email-masked]]
> Sent: Wednesday, October 16, 2002 1:11 PM
> To: Bound, Jim
> Cc: [email-masked]; [email-masked]
> 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 this
> note.  Video is either done or doable depending
> on your definitions.
> 
> The media and technology (Mobile IP and fast
> handovers) support it;  some way of alleviating
> DAD delays is required for it to work.  The market
> and the standardization process are another matter
> entirely.  Research publications are yet another
> matter, but some papers have been published.
> 
> Regards,
> Charlie P.
> 
> "Bound, Jim" wrote:
> >
> > Alper,
> >

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 17 Oct 2002 02:28:23 -0400

Nick,

100% agree.  

/jim

-----Original Message-----
From: Nick 'Sharkey' Moore [mailto:[email-masked]] 
Sent: Wednesday, October 16, 2002 6:24 PM
To: Bound, Jim
Cc: Tony Hain; Charles E. Perkins; Pekka Savola;
[email-masked]

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.

We could obviously just reduce the RETRANS_TIMER value, but for
real-time services we'd have to ask ourselves "How long is 
too long for real-time? How short is too short for reliable
collision detection?"

-----N

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 17 Oct 2002 18:08:56 -0400

Nick,

Doing review of the draft now.  It is good.  No opinion yet.
Don't get me wrong I think we need to solve this I just want to be
careful how, because we got that ND stuff a runnin now and test
deployed.  But many of us have products now in 2nd and 3rd release.
But O-DAD appears to be add on so that's  cool.  Just don't want to burn
an interface without just cause so being cool as product engineer :--)

On the theoretical discussion.  I think the entire layer 3 effort to all
agree and standardize (Charlie and others I know clearly are testing) is
far far from baked as standard.  I do refuse to listen to folks who tell
me we are close when I am on the mail list or reading the archive and 5
very very bright people all correct do agree, but none of them will
compromise with each other technically.  Then I say from 10 years in the
IETF working and implementing that this is simply going to take awhile.

On the ignore the standard diatribe.  I simply believe the people who
support my day job are now wanting technology that requires mobile ipv6,
ipv6, ipsec/TLS, BGP+, TCP-Multicast-Fixes et al, SCTP, and lots of good
technology created here, are simply tired of waiting for us in this
community.  If they have enough money and opportunity then they can
attract the top vendors.  I do know of such giants that are ready to
discuss lets get vendor x,y,z and contract gurus a,b,c together and make
this work.  When we are done we can build specifications for standards
bodies.  That will happen soon.  At that point they are not even
listening to us here.

L2 vs L3.  This battle rages.  I am positive we require layer 3 handover
simply because I believe mobility requires IP to be totally successful
and I would argue IPv6 and IPv4 is a dead end street.  But per the baked
discussion above we are far from agreement on hmipv6, LMM, and PKI
(mostly in the market) and without these tid-bits I just don't see L3
happening first.

Here is my vision of large $$$$$$ deployment of Mobility:

1. First there is none.  Users accept to reconnect first but using IPv6.

2. Second.  We get full products with MIPv6 and we still use L2 for
handover.  Similar to 3G but more 3G+ (I can't say 4G cause I still
believe its marketing hype but maybe not I have stopped following it).

3. At some point in the future we finally get to L3 handovers.

4. I believe AAA will be as important as Ipsec and will play a big role
in all three cases above to make it work and charge money for it :--)

I think #3 best case for true deployment into large enough test beds
that it is ready for real deployment (I roam in L.A. from home to
airport and stay connected) and will scale across town via the routers,
is best case 5 years away.  

I usually send first draft comments to just the authors and I hope to
next week as I do have technical input for you.

Regards,
/jim

-----Original Message-----
From: Nick 'Sharkey' Moore [mailto:[email-masked]] 
Sent: Thursday, October 17, 2002 2:45 AM
To: Bound, Jim
Cc: Alper E. YEGIN; [email-masked]; Pekka Savola;
[email-masked]

On Thu, Oct 17, 2002 at 02:34:59AM -0400, Bound, Jim wrote:
> > > 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 future?
> 
> > We're pretty clear on this: we've tested it.
> 
> Have you tested hmipv6 to the scale that mobility operator working 
> with ISPs can cover the entire metropolis of L.A.?

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 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 :-)

Actually, JinHyeock reminded me that I'd forgotten to mention the
Movement Detection Delay ... we've been tackling that with inter-layer
signalling to prompt router solicitations.

> No one has deployed layer 3 in production environment I am aware of? 
> Nor would I trust it yet simply because of this mail discussion.

Ummm ... I hope it isn't my Optimism which has caused your 
concerns ... although if you've got technical comments or concerns re:
my draft I'd love to hear them.  It is, after all, a work in progress.

The Optimistic DAD thing comes about because I thought
the FH stuff was getting a bit theoretical and I felt that a set of
small, easily implemented patches, one per cause of L3 handover delay,
would be a good way to move forward in the short term.

cheers,
-----Nick

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Fri, 18 Oct 2002 09:11:48 +0200

> > => 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 think there's
  > some common ground between the tactics of HMIP and the FMIP
  > three-party-handover and I suspect the best solution is in that
  > region somewhere ... 

=> I guess, w're on the wrong list for this discussion.
But I don't understand your concern about "propagation". 
In Jim's case, you're not likely to use Dynamic MAP 
discovery. The most likely way is manual configuration
of ARs.

  > > => What you're doing (optimistic DAD) can be combined 
  > > with Fast Handovers to completely eliminate movement 
  > > detection delay. [...]
  > > => My very initial effort (with Karim) with Fast 
  > handovers was aimed 
  > > at: anticipation + optimistic DAD + HMIPv6.
  > 
  > It's tricky getting anticipation signalling out of most 802.11
  > drivers, but we've had success getting L2 to signal L3 that it has
  > just reassociated, causing L3 to RS. Greg Daley has more information
  > here, I'm sure he'll chip in when he gets back to town ...

=> Anticipation is not bound to 802.11, it can also
happen on the network side in other link layers. 
I agree that it is not supported by all cards
as you guys keep telling me :)

Hesham

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Fri, 18 Oct 2002 19:53:07 +0200

>   - 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.
  > 
  >     Where are these link-layer addresses taken from?
  > 
  >     The router will ignore both NS and NA for the following reasons:
  >      - NS is send  without the Source Link-Layer Address option.
  >      - NA is sent with the O-bit = 0.  If the router does 
  > not have an
  >        entry for this address (most likely), it "SHOULD" 
  > ignore the NA
  >       (2461).
  > 
  >     The only place so far the node can get the address of 
  > the router is from
  >     the RA, but Source Link-Layer Address option is optional in RAs
  >     (it's a MAY in 2462).
                       ^^^^^
=> You mean 2461 I guess. There is probably an implicit 
assumption about the use of Fast Handovers here. In
that case the optimistic node can get this information
before it moves.

Hesham

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 18 Oct 2002 13:49:31 -0400

Ahh I do that every day in engineering :--)

Hey if you collide take a look at router renumbering spec for IPv6 :--)

We have way to many specs to read I have no clue how the IESG keeps up
with it all. That is why it's a full time job right there. Let alone all
the other stuff they have to do.

/jim

> Sent: Thursday, October 17, 2002 8:37 PM
> To: Bound, Jim
> Cc: James Kempf; Alper E. YEGIN; Pekka Savola; 
> [email-masked]
> 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 :-)
> 
> I guess I'm working from a different angle to most, too:
> "What is the minimum required for a useful fast, smooth 
> MIPv6" vs. "What is the most perfect system which is still 
> implementable".
> 
> -----Nick
>

---

From: "Richard Draves" <[email-masked]>
Date: Tue, 22 Oct 2002 09:23:25 -0700

> > > 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, 
> > > but why is the correspondent soliciting for a REACHABLE 
> entry? (Or 
> > > have I missed something elsewhere?)

Here's a real scenario where you will receive an NA with S=1, O=0 in the
REACHABLE state. You try to resolve an anycast address by sending an NS.
You receive a first NA and transition to REACHABLE. Then you receive a
second NA with S=1, O=0. You want to ignore this second NA.

The situation where you receive an NA with S=0, O=0 when not INCOMPLETE
is this: Someone is proactively advertising an address (perhaps because
of a configuration change) and wants to update any stale neighbor caches
out there. So if your link-layer address is different than the one in
the NA, move from REACHABLE to STALE to speed-up NUD if the cached
link-layer address is now bad. If it's actually still good, you haven't
done much damage by moving to STALE.

Rich

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Thu, 24 Oct 2002 10:01:08 +1000

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 can of worms.

By the way, linux-2.4.18/net/core/neighbour.c:neigh_update()
seems (at a quick glance) to go with the "don't do anything if
override = 0" interpretation, but then that's a whole _different_
can of worms!

Most folks back in 1999 seem to have gone with the REACHABLE->STALE
interpretation though ... unless there's a canonical 2461bis
which fixes this problem I'm going to interpret it as a MAY,
eg nodes may or may not reset the entry.

Thanks everyone for your comments.  I'm going to fix the draft
up a bit for -01, I think getting some kind of Optimistic
DAD standardized is going to be essential for Mobile IPv6 
to be useful ...

-----Nick