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

[Xiangsong Cui <Xiangsong.Cui at huawei.com>]

Hi Hidetoshi,

Please see inline.

Regards/Xiangsong


----- Original Message ----- 
From: "Hidetoshi Yokota" <yokota at kddilabs.jp>
To: "Xiangsong Cui" <Xiangsong.Cui at huawei.com>
Cc: <mipshop at ietf.org>
Sent: Monday, August 24, 2009 9:42 PM
Subject: Re: [Mipshop] draft-ietf-mipshop-pfmipv6-08.txt


> 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, ..."?

Yes, you are right. This new statement is OK for me.

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

I see the purpose, but for this deep procedure, need we consider some more
situation? for example, after sent the first HI, the PAR cancelled the 
handover
procedure, does this case exist?

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

I don't know well the discussion you mentioned, but I do see some
discussion on UNA message in NETEXT2 BoF.
In my understanding, UNA is not a mobility protocol message,
RFC4861 is for IPv6 but not for mobile IP. Any IPv6 node can
transmit UNA message, this need't mobility extension.
Maybe we should discuss UNA message in a separate topic.

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

OK

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

OK, I see.

> Hope the above will clarify your questions.

Thanks!

> Regards,
> --
> Hidetoshi
>
> > Regards
> >
> > Xiangsong