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

From: "fan zhao" <[email-masked]>
Date: Tue, 4 Nov 2008 13:39:29 -0800

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)?

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.

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.

Thanks.

Sincerely,
fan
_______________________________________________
Mipshop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mipshop

---

From: Hidetoshi Yokota <[email-masked]>
Date: Fri, 07 Nov 2008 14:48:14 +0900

Hi Fan,

Thanks for your questions. I think the draft needs more text to make the
procedures clearer. Please see inline:

> 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.

> It seems to me that it is the PAR that sends the HI message and receives

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.

> 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?

Regards,
-- 
Hidetoshi

---

From: "fan zhao" <[email-masked]>
Date: Fri, 7 Nov 2008 18:09:45 -0800

Hi Yokota-san,

Thanks for your reply. Please see below.

> exchanged. So, step (e) is not mandatory, and this should be described
OK.

> and when the NAR is ready to accept those packets, it asks the PAR to
I see your point. Maybe you can clarify the behaviors of the NAR and the PAR
in the next version.

> 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

---

From: Hidetoshi Yokota <[email-masked]>
Date: Tue, 11 Nov 2008 20:18:14 +0900

Hi Fan,

See inline:

> access network, the home address should be used.

Ok. If your draft covers the predictive mode, the NCoA has to be
configured in the previous network in one way or another. I think it is
also a good idea to refer to draft-ietf-netlmm-mip-interactions-00.txt,
which describes several scenarios for the MIP-PMIP interaction.

Regards,
-- 
Hidetoshi