Re: [Mipshop] comments on draft-ietf-mipshop-pfmipv6-00

Hi Yokota-san,

Thanks for your reply. Please see below.

On Thu, Nov 6, 2008 at 9:48 PM, Hidetoshi Yokota <yokota@kddilabs.jp> wrote:
> Hi Fan,
>
> Thanks for your questions. I think the draft needs more text to make the
> procedures clearer. Please see inline:
>
> fan zhao wrote:
>> Hi,
>>
>> I have some comments on this draft.
>>
>> 1) Section 4.1
>> "  (c)  The PAR sends the HI to the NAR.  The HI message MUST include
>>         the MN ID and SHOULD include the MN-HoA, the MN-HNP, the MN-IID
>>         and the address of the LMA that is currently serving the MN.
>> ...
>>
>>    (e)  The NAR requests the PAR to buffer or forward packets by setting
>>         U or F flags in the HI message, respectively."
>>
>>>From the figure, it seems to me that at step (e), a set of
>> new HI/Hack messages are exchanged for packet forwarding
>> while step (c) and (d) are for context transfer. Do I understand correctly?
>> Can (e) be combined with (c) and (d)?
>
> Yes, they can be combined if the context transfer and the tunnel setup
> for packet forwarding happen at the same time. If these two procedures
> are performed at different times, additional HI/HAck messages are
> exchanged. So, step (e) is not mandatory, and this should be described
> more clearly.
OK.

>
>> Also It seems to me that (e) should be "The PAR requests the NAR ..
>> in the HI .."
>>
>> 2) "The timing of the context transfer and that of packet forwarding may
>>    be different.  Thus, a new flag 'F' and the Option Code values for it
>>    in the HI message are defined to request forwarding.  To request
>>    buffering, 'U' flag has already been defined in [RFC5268].  If the
>>    PAR receives the HI message with F flag set and the Option Code value
>>    being 2, it starts forwarding packets for the MN."
>>
>> It seems to me that it is the PAR that sends the HI message and receives
>> the Hack message.
>
> The arrows go in both ways, which means that either may request
> buffering and/or forwarding. I admit that this should also be reflected
> to the text. In general, however, the NAR newly allocates resources for
> the MN, so during that time, the NAR asks the PAR to buffer the packets
> and when the NAR is ready to accept those packets, it asks the PAR to
> forward them.
I see your point. Maybe you can clarify the behaviors of the NAR and the PAR
in the next version.

>
>> 3) The case when the target access network supports MIP instead of PMIP
>> is described. I also submitted a draft,
>> http://tools.ietf.org/id/draft-zhao-mipshop-fmip-pfmip-00.txt.
>> Comments are very appreciated.
>
> I think this is workable, but I have one question: can the MN configure
> its NCoA in the previous network, where the PMIP is used?
I think it is doable as long as the MN obtains address configuration information
on the previous network where PMIP is used. In the FMIP protocol, this
is done by RtSolPr/PrRtAdv; maybe some access specific messages for the PMIP
domain can be used. On the other hand, if the PMIP is used in the target
access network, the home address should be used.

Sincerely,
fan

>
> Regards,
> --
> Hidetoshi
>
>> Thanks.
>>
>> Sincerely,
>> fan
>> _______________________________________________
>> Mipshop mailing list
>> Mipshop@ietf.org
>> https://www.ietf.org/mailman/listinfo/mipshop
>>
>>
>>
>
>
_______________________________________________
Mipshop mailing list
Mipshop@ietf.org
https://www.ietf.org/mailman/listinfo/mipshop