Re: [Mipshop] draft-ietf-mipshop-pfmipv6-08.txt

[Hidetoshi Yokota <yokota at kddilabs.jp>]

Hi Xiangsong,

I'm terribly sorry for the late response. Thanks for your questions and
comments. Please see in line:

Xiangsong Cui wrote:
> Hi Hidetoshi,
> 
> I have just read draft-ietf-mipshop-pfmipv6-09.txt and
> I have some comments for it.
> 
> 1, In section 4, it says:
>  "the Handover
>   Initiate (HI) and Handover Acknowledge (HAck) messages in [RFC5568]
>   are used for context transfer, in which parameters such as MN's NAI,
>   Home Network Prefix (HNP), IPv4 Home Address, are transferred from
>   the PMAG."
> The HI and HAck messages you used in this document are not from
> RFC5568, you are using new HI and HAck messages.
> "the Handover Initiate (HI) and Handover Acknowledge (HAck) messages
>  defined in this specification are used for ..." is better, IMO.

The HI and HAck messages in this document actually use the same MH types
of those in RFC5568. In this sense, those message are not new. However,
since new flags are defined, how about the following: "the Handover
Initiate (HI) and Handover Acknowledge (HAck) messages in [RFC5568] are
extended for context transfer, ..."?

> 2, In section 4.1 (page 11), the steps (c) to (e) in the flow, they are 
> not clear.
>   You imply such a case: in step c and step d, it is not decided whether
>   to do buffering and where to do buffering, and in step e, NAR sends
>   a new HI message to PAR with U bit set (DL data buffered in PAR),
>   and later NAR sends another HI message to PAR with F bit set (DL data
>   forwarded to NAR from this time). Is it true?

The first HI/HAck exchange is meant only for context transfer, and the
second exchange is meant for buffering or forwarding. This is not a
mandatory procedure, and they can be done at once.

>   I don't understand what benefit we can get for this complex procedure.
>   I suggest we provide the buffer indication in the step c, U bit set in 
> the
>   HI message, and DL data is buffered in NAR. NAR knows when to forward
>   DL data to MN and it is more fit to buffer DL data.
>   If it was accepted, step (e) should be removed and steps (c) and (d)
>   should be modified (U bit and the operation added).

In some systems, context information needs to be transferred way before
the movement of the MN, whereas the best timing for the buffering or
forwarding is immediately before the movement of the MN. These multiple
HI/HAck exchanges are meant to capture this situation. As mentioned
above and described in the document as well, this is an optional procedure.

> 3, In section 4.1 (page 12), it says:
> "Since the NAR obtains the LLA (MN IID)
>   and MN-HNP by the HI, it can create the NCE for the MN and deliver
>   packets to it even before the MN can perform Neighbor Discovery."
>   NAR can know the HoA and CoA of the MN, but at the initiatory time,
>   the state of the MN in the NAR is not reachable, the NAR can't send
>   data to MN in this state. NAR should begin to send data to MN after
>   the cached state changed to reachable. This needs a Neighbor
>   Discovery message (from MN) in the flow. Although UNA message is
>   not part of the handover procedure, I still suggest including this
>   message in the flow, as RFC5568 has done.

There were some discussions on this issue before. Since the MN is not
involved with IP mobility protocol operations, the usage of the UNA is
not applicable as stated in the third paragraph of Section 4. An
alternative solution is to use the NUD operation, but the primary issue
about it is that the MN is not able to receive any packet until then,
which is thus not an optimal solution. If the MN is attached to the new
link and can receive packets, the NAR should be able to send packets as
soon as possible. Note that in this situation, the MN may not even
realize the change of its link. In any case, this procedure relies on
the L2 support and is used only if it is applicable.

> 4, In section 4.1 (page 12), it says:
> "The HI message with the U flag set
>   may be sent earlier if the timing of buffering is different from that
>   of forwarding. "
>   Because AR can not do buffering and forwarding (for the same DL data
>   flow) at the same time,  so the if condition is meaningless.
>   In fact, if my second comment (mentioned above) was accepted, we
>   even don't need F bit.

The opposite operation of the above is not buffering and forwarding at
the same time. The situation that the above sentence tries to describe
is that the NAR may want to ask the PAR just to buffer the packets. In
this case, the NAR has to ask the PAR to forward the buffered packets at
a later time. So, the F flag (or any other signaling to trigger
forwarding) is needed.

> 5, In section 6.1.1 (page 19),  the introduction to Mobility options,
>   It is not clear which options from RFC3775 are available for the newly
>   defined HI message, and I also think the options introduced in section 
> 6.2
>   should be mentioned in this subclause.
>   HAck message is same.

Any mobility options assigned by IANA. What is said in this part is that
the encoding and formats that are defined in [RFC3775] are used in this
specification. The mobility options are defined in multiple documents
(such as RFC5213) besides RFC3775.

Hope the above will clarify your questions.

Regards,
-- 
Hidetoshi

> 
> Regards
> 
> Xiangsong
> 
> 
>