Subject: Re: [mobile-ip] what optimistic DAD?

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Sat, 28 Jun 2003 10:42:19 +1000

On 2003-06-27, Erik Nordmark wrote:
> 
> As long as the downside of being tentative isn't significant this would
> make sense.

Yeah, that's part of the idea of Optimistic DAD ... reduce the
penalty of Tentativeness, thus it doesn't matter if you've got to
hang around for an old-fashioned 1000ms or even longer.

-----Nick

---

From: Soliman Hesham <[email-masked]>
Date: Fri, 27 Jun 2003 21:55:42 -0400

> so if the NAR sends out a Neighbor Solicitation for the 
 > mobile's newCoA and there is no reply (because the MN 
 > hasnt showed on the link yet), the NAR wont retry for 
 > another 1000 ms. if the mobile node shows up on the link 
 > after the first Neighbor Solicitation, it has to wait for 
 > 1000 ms for the NAR to send another Neighbor Solicitation, 
 > reply with a Neighbor Advertisement and create a REACHABLE
 > neighbor cache entry at the NAR, right?

=> The MN can send an unsolicited NA, which would cause
the AR to copy its information into a STALE entry. 
Which means that the AR can still forward packets
immediately to the MN. The MN need not have a REACHABLE
state. So it doesn't have to wait for 1 s

Hesham

 > 
 > Erik, if you missing the context, we are discussing 
 > OptiDAD here. the NAR sends out an Neighbor Solicitation 
 > because the FBU to the PAR caused the PAR to start 
 > forwarding packets to the NAR. if NAR sends a Neighbor 
 > Solitication before the mobile node shows up, then we have 
 > a problem?
 > 
 > if the mobile node misses the first Neighbor Solicitatoin
 > then it would take 1000 ms to create a REACHABLE neighbor
 > cache entry. OTOH, a message like FastNA from the mobile 
 > node creates a REACHABLE neigbor cache entry immediately.
 > 
 > Vijay
 >

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 30 Jun 2003 10:25:31 -0700

Erik Nordmark wrote:
> 
> The question seemed to be whether some event was specififed in RFC 2461
> and that was what my response convered.
> 
> RFC 2461 doesn't specify a mechanism by which the sender of the NS
> would be told to send one sooner than after RetransTimer has expired, yes.
> 
> That doesn't mean that there aren't other ways to create
> an NCE; for instance sending an unsolicited NA.
> (That will create it in STALE state and then move to DELAY when
> the first data packet is sent.)
> 
> Why would REACHABLE be required? I think STALE is the correct
> state since bidirectional reachability wouldn't be known at
> this point in time. Thus wouldn't FastNA be the same as an unsolicited NA?

hi Erik,

it became clear to me through email exchanges with 
Nick. thanks.

in the current OptiDAD proposal, the unsoliciated NA
is a MAY. Nick promised to upgrade it to a SHOULD in
certain scenarios (like for example when the MN has
sent an FBU on the old link and would know packets 
would start arriving at the NAR before it shows up).

Vijay