Subject: RE: [Mipshop] FNA in the current spec

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 17 Aug 2005 17:40:20 -0400

Hi Rajeev, 

 > Here is the thinking behind having FNA.
 > 
 > 1. Assume that the PAR has processed FBU before the
 >     MN regains link connectivity with NAR. So, the
 >     arriving packets at NAR invike Neighbor Discovery,
 >     setting the state to INCOMPLETE. IF the timing turns
 >     out to be such that the MN can answer the _first_ Neighbor
 >     Solicitation, then things are good. In the most likely case,
 >     such a coincidence cannot be guaranteed :-)
 >     For the general case, assume that the MN sends Neighbor 
 > Advertisement
 >     unsolicited. Since there is an ND state (INCOMPLETE), it is
 >     changed to STALE upon receiving the unsolicited NA. The STALE
 >     entry prompts reachability confirmation before the peer (MN)
 >     is deemed REACHABLE. 

=> That's true but irrelevant at the same time :). It is true, but
it has no consequence on packet delivery. In STALE, the AR can send
packets to the MN while confirming reachability.

      (NOTE: it is not clear to me whether an
 >     unsolicited NA immediately prompts a new NS or the state machine
 >     waits until the next NS is triggered since address resolution is
 >     in progress). This means either active probing (sending
 >     NS, expecting solicited NA) or "forward progress" determination.

=> It doesn't matter, there is no disruption of service. 

 > 2. Assume that the PAR has not processed FBU before the MN regains
 >     connectivity on NAR. In this case, NAR has no ND state 
 > for the MN,
 >     and hence it will discard the unsolicited NA. When the 
 > PAR processes
 >     FBU and starts tunneling packets to NCoA, NAR will do 
 > one round-trip
 >     of NS - NA processing.

=> There are several unstated assumptions here:
  a. You're assuming that either the BU is lost or that
     the transition to the new link was quicker than the 1/2 RTT
     between the MN and the PAR plus 1/2 RTT between the PAR and NAR.
     The second case is extremely unlikely. But even if it happens
     this would be a normal ND transaction. Note that it is very unlikely
     that this happens. 
  b. If the BU is lost, you're assuming that the MN would resend the
     BU to the PAR. Even if this is the MN's fallback, by that time, 
     the NS/NA is not a big issue because FMIP has basically failed. 

 > 
 >     So, if we are requiring the MN to send an unsolicited NA 
 > anyway, why
 >     not make it such that there is no additional round-trip 
 > of (possibly
 >     delayed) signaling is necessary, and the ND state is set 
 > to REACHABLE
 >     immediately? This was the thinking.

=> You MUST NOT set the state to REACHABLE until you know that 
bidirectional reachbility is available. The FNA does not do that. 
It seems like an ill-defined shortcut to me.

Hesham

 > 
 > -Rajeev
 > 
 > 
 > 
 > 
 > _______________________________________________
 > Mipshop mailing list
 > [email-masked]
 > https://www1.ietf.org/mailman/listinfo/mipshop
 > 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 17 Aug 2005 15:25:27 -0700

Hi Hesham,

> packets to the MN while confirming reachability.

Could you point out the relevant text in 2461? This is implementation
dependent?

> => It doesn't matter, there is no disruption of service. 

What does happen? I am curious.

>      the NS/NA is not a big issue because FMIP has basically failed. 

The assumption is that this is the FMIP reactive handover :-)
I don't see why FMIP has failed. It's just that FBU is sent from the new
link.

> It seems like an ill-defined shortcut to me.

If you could forward packets "optimistically" when in STALE state, why 
not make it "official" for FMIP purposes? Note that this is an FMIP 
optimization, and not baseline ND operation.

-Rajeev