Re: [Mipshop] I-D Action:draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt

Behcet,

    Well, this argument I already covered, but I will do it in more detail.
    The HI and HAck exchange are still possible even in the original 
RFC 4068 in reactive mode even though Figure three in the original 
RFC 4068 did not show it.  If one reads the text it was still 
possible.   Why?  Because once the mode node was on the NAR, how does 
it signal to the PAR?
by the FBU, right? Okay so now the PAR knows where the mobile node is 
(that is its new care of address.)  Does the PAR need to tell the NAR 
anything or need to know anything from the NAR?
Well, yes it does.  The PAR needs to know that the new care of 
address in the FBU is indeed okay for the Mobile node to use on the 
NAR.  If so, it does so through the HI/Hack.

When the Mobile node sent the UNA to the NAR.  It did so with a new 
care of address which might not be acceptable to the NAR.  If the New 
care of address is not acceptable to the NAR, it will send back a 
NAACK.  However in the mean time the mobile node has not received an 
FBack, so it sends a FBU with its NCoA to the PAR.  In this case the 
NCoA picked by the mobile node is not the one the NAR wants and 
therefore if the PAR uses only the information provided in the FBU 
from the mobile node and the PAR does not send the HI to the NAR to 
confirm the NCoA use.  An error could occur, No?
     Now with this explanation am I still missing something on why 
the HI/HAck should or should not be included?

David Cypher
==================================
  At 05:27 PM 4/24/2008, you wrote:
>Hi David,
>   Please see inline. Let me know if you are still confused.
>
>Regards,
>
>Behcet
>
>----- Original Message ----
>From: David Cypher <david.cypher@nist.gov>
>To: mipshop@ietf.org
>Sent: Tuesday, April 22, 2008 2:13:31 PM
>Subject: Re: [Mipshop] I-D Action:draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt
>
>Behcet,
>
>     Okay there appears to be a disconnect in this thread.
>The subject refers to
>Action:draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt,
>which is the update to RFC 4068 Fast handover Mobile IP
>[behcet] No disconnect, it IS about this draft.
>This talk about context switching appears to relate to the FMIP/PMIP 
>interactions draft.
>[behcet] See below.
>Or are you stating that with things like those being defined in the 
>draft IEEE 802.21 that these sorts of functions are already covered 
>and do not need to be repeated in the new revised RFC 4068?
>[behcet] No.
>Or are you just arguing over the use of term/naming of handover initiate?
>[behcet] No.
>Or have I missed something else?
>[behcet]  Maybe so.
>I am suggesting that Hi/HAck exchange in Fig. 3 be removed. You 
>thought that that exchange was needed to establish PAR-NAR tunnel 
>but in fact it is not. As I mentioned before the exchange was added 
>the first time in draft-ietf-mipshop-fmipv6-rfc4068bis-02 (Please 
>check this from the tools server), seemingly in support of a 
>co-authored draft what you called FMIP/PMIP interactions draft which 
>uses the Hi/Hack exchange for "context switching".
>More details in the email conversion between me and Rajeev.
>
>
>


_______________________________________________
Mipshop mailing list
Mipshop@ietf.org
https://www.ietf.org/mailman/listinfo/mipshop