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

[Hidetoshi Yokota <yokota at kddilabs.jp>]

Hi Xiangsong,

Please see inline:

Xiangsong Cui wrote:
> 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?

Error cases are not shown. The above situation is not an error case,
though. The NAR may need to know the information of the MN sufficiently
enough before preparing the imminent handover. If the timing of context
transfer and that of handover are always bound together, the NAR may not
be able to perform the handover procedure in a timely manner...

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

If the MN changes to the same link type, it may not even realize that
change in any manner. Even if the MN notices something, it may then try
to make sure its reacheability, which will take time. If the NAR can be
sure that the MN has been attached, it would be better that the NAR can
start sending packets without relying on the signaling from the MN.

On the other hand, if the MN changes to a different link type, which I
believe was part of the scope in NetExt2 BoF, then the MN may need to
express its intention, that is, whether this is a handover or
multihoming. There may need to be some signaling such as the UNA for
that purpose, which is still under discussion. I therefore also think
the MN-AR interaction is a good and important topic in NetExt(2).

Thanks for your comment and good discussion.

Regards,
-- 
Hidetoshi

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