Subject: RE: Re: [Mipshop] FMIPv6 Reactive Handover - HI/HAck

From: "Junghoon Jee" <[email-masked]>
Date: Wed, 24 Aug 2005 02:24:15 +0900

Hello Charles,
Regarding capturing packets still in flight to PAR,
I think that using only FBU without HI/HAck may be enough in this reactive case.
 
Regards,
Junghoon

-------------------------------------------------------------------------------------------------- 

Hello Junghoon, 

HI may be needed to capture packets still in flight to PAR. 
This is independent of context transfer, but that reinforces 
the point. 

Please excuse if this answer has already been provided in 
previous e-mail discussion. 

Regards, 
Charlie P. 

Junghoon Jee wrote: 

> Hi Vidya, 
> I made the same question through DNA WG recently regarding FMIP-DNA I-D. 
> You can find the previous discussion through the attached message. 
> I am still questioning why HI/HAck for the access control is required 
> after MN has already attached to NAR in the reactive case. 
> Junghoon 
>> -----Original Message----- 
>> From: Rajeev Koodli [mailto:[email-masked]] 
>> Sent: Tuesday, July 19, 2005 8:46 AM 
>> To: Junghoon Jee 
>> Cc: 'Syam Madanapalli'; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]> 
>> Subject: Re: [DNA] draft-koodli-dna-fmip-00.txt 
>> 
>> 
>> 
>> 
>> Junghoon Jee wrote: 
>> 
>> > Rajeev, 
>> > 
>> > 
>> >>For both predictive and reactive modes, HI/HAck can be useful for 
>> >>access control. NAR can forward packets for the MN without forcing 
>> >>access control, through HI/HAck. 
>> > 
>> 
>> One could use HI/HAck for CT, but I am not referring to that. 
>> 
>> When FBU processing is successful, PAR's message (HI) to NAR 
>> can allow NAR to "validate" the ND cache entry for NCoA. 
>> No Context Transfer is involved. The fields in HI (PCoA, NCoA, 
>> LLA) are sufficient for the purpose. 
>> 
>> -Rajeev 
>> 
>> 
>> 
>> 
>> 
>> > 
>> > Are you saying about context transfer by HI/HAck ? 
>> > 
>> > Regards, 
>> > Junghoon 
>> > 
>> > 
>> >>(If it is not clear, FMIP-DNA is applicable when DNA+oDAD is 
>> >>available, 
>> >> and no neighborhood information is available for FMIP) 
>> >> 
>> >>-Rajeev 
>> >> 
>> >> 
>> >> 
>> >>Syam Madanapalli wrote: 
>> >> 
>> >> 
>> >>>Hello Junghoon, 
>> >>> 
>> >>>Thanks for reviewing the draft. 
>> >>> 
>> >>> 
>> >>>>Hi Syam, 
>> >>>>It's an interesting work. 
>> >>>>After reviewing this I-D, I've come up with a following question. 
>> >>>> 
>> >>>>About the role of HI/HACK in this reactive FMIPv6-DNA : 
>> >>>>I thought that these messages are required to confirm the MN's 
>> >>>>prospective NCoA in predictive mode. 
>> >>>>In the FMIPv6-DNA, MN configures the NCoA by optimistic 
>> DAD in the 
>> >>>>reactive mode, so why do those messages needed to be 
>> >> 
>> >>transferred and 
>> >> 
>> >>>>what's their roles ? 
>> >>>>Just to prepare for future optional behavior the same as 
>> >> 
>> >>specified in 
>> >> 
>> >>>>the draft-ietf-mipshop-fast-mipv6-03 ? 
>> >>>>I guess that my question may also apply to the reactive mode of 
>> >>>>draft-ietf-mipshop-fast-mipv6-03. 
>> >>> 
>> >>> 
>> >>>As you mentioned, currently there is no new use of HI/HACK 
>> >> 
>> >>other than 
>> >> 
>> >>>what is mentioned in FMIPv6 RFC. That is, NAR can make use of the 
>> >>>knowledge that its trusted peer (i.e., PAR) has a trust 
>> >> 
>> >>relationship 
>> >> 
>> >>>with the 
>> >>>MN. 
>> >>> 
>> >>> 
>> >>> 
>> >>>>Regards, 
>> >>>>Junghoon 
>> >>>> 
>> >>> 
>> > 
>> 
> 
>------------------------------------------------------------------------ 
> 
>_______________________________________________ 
>Mipshop mailing list 
>[email-masked] 
>https://www1.ietf.org/mailman/listinfo/mipshop 
>  
> 

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