Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6

[Hidetoshi Yokota <yokota at kddilabs.jp>]

Hi Ahmad,

Please see inline:

Ahmad Muhanna wrote:
> Hi Hidetoshi,
> Please see inline.
> 
> Regards,
> Ahmad
> 
>> -----Original Message-----
>> From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp] 
>>>> -----Original Message-----
>>>> From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
>>>> Sent: Thursday, September 17, 2009 4:48 PM
>>>> To: Muhanna, Ahmad (RICH1:2H10)
>>>> Cc: Mipshop; draft-ietf-mipshop-pfmipv6 at tools.ietf.org; Jari Arkko
>>>> Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
>>>>
>>>> Hi Ahmad,
>>>>
>>>> Here is the proposed revision:
>>>>
>>>> In Section 4.2:
>>>>       [... message with the same sequence number.] The necessary
>>>>    information MUST be transferred in the HI/HAck messages to
>>>>    distinguish MN's packets for forwarding in advance or 
>> at this time.
>>>>    Such information includes the MN ID and/or GRE key(s).  
>> Typically,
>>>>    the NMAG selects the GRE key for the downlink packets 
>> and the PMAG
>>>>    selects that for the uplink packets.  Each key is conveyed in 
>>>> either
>>>>    the HI or HAck message separately when GRE Key Option 
>> [GREKEY] is
>>>>    used. [For the downlink ...]
>>>>
>>> [Ahmad]
>>> In addition to what Vijay mentioned with respect to 
>> Typically (which 
>>> should be removed), I believe the draft needs to be clear on the 
>>> mechanism that is used for exchanging the GRE keys. When you say 
>>> "...when the GRE Key Option [GREKEY] is used." What happens 
>> if the GRE 
>>> key option is NOT used. Is there another mechanism?
>> As an alternative way, Vendor-Specific Mobility Option could 
>> be used. As you pointed out, the restriction introduced by 
>> GRE Key Option is that it can convey only one key in one 
>> message. If multiple keys need to be conveyed at one time for 
>> some reason, this alternative solution could be used. Should 
>> that also be in the document?
> 
> [Ahmad]
> Honestly, I do not care. However, there MUST be a default mechanism that
> MUST be clearly described in this draft and MUST be supported for
> Interoperability. That choice being GRE Key option or VS MO, it does not
> matter as long as the default mechanism is clearlu defined. Is that a
> reasonable request?

I just want this document to cover as many use cases as possible. A
default mechanism should be GRE Key Option. Thinking it over and in the
case of Vendor-specific Mobility Option, it would be necessary to define
the whole message format internally, which may be beyond the scope of
this document. Thus, it would be better to describe only the use of GRE
Key Option in the document.

Regarding the rest of your questions below, if GRE keys are not used
between the LMA and MAG (on the PMIPv6 tunnel), the flow should be
identifiable by the HNP, correct? In this case, GRE keys are not
mandatory on the inter-MAG tunnel. At the same time, this spec does not
mention any other encapsulation mechanism.

Based on the above observations, the following paragraph is proposed:

-----
The necessary information MUST be transferred in the HI/HAck messages to
distinguish MN's packets for forwarding in advance or at this time. Such
information includes the HNP (or IPv4-MN-HoA) and/or GRE keys. Regarding
the GRE key selection, the NMAG selects the GRE key for the downlink
packets and the PMAG selects that for the uplink packets. Each key is
conveyed in either the HI or HAck message separately with GRE Key Option
[GREKEY].
-----

How about it?

Regards,
-- 
Hidetoshi

>>> Since the GRE keys are necessary to establish the lateral 
>> tunnel and 
>>> identify the MN traffic, the draft must specify a default mechanism.
>>> Other mechanisms can be used or specified some where else 
>> if needed, 
>>> but we need a default one here. Right?
>>>
>>> Also, you replaced the **HoA of the MN** with the **MN 
>> ID**. What is 
>>> the reason for this change?
>> Since the MN ID is the required option, I thought I fixed it 
>> there, but maybe the HNP will also be needed.
> 
> [Ahmad]
> Well, the question is why and/or GRE keys?
> If the GRE Keys are NOT included what is the tunneling mechanism that is
> being used. This is sort of vague and NOT clearly defined. I find it
> hard to follow what the draft is proposing and the details of the
> protocol.
>
>>> And how this should work NOW while you have ".. and/or GRE Keys"?
>> If the HNP (or IPv4-MN-HoA) is transferred, would that be sufficient?
> [Ahmad]
> It depends on the encapsulation mechanism that is being used. My
> understanding is the following: If it is optional to exchange GRE keys
> between the PMAG and NMAG, then it means that there is another type of
> encapsulation/tunneling mechanism. Right? Could be GRE without keys,
> etc..
> What is it? How it works to map all sessions, etc. These details are
> missing in the draft, but it could be only me.
>
> Regards,
> Ahmad
> 
>> Regards,
>> --
>> Hidetoshi
>>
>>>> If the above description is acceptable, I will submit the revised 
>>>> version by the end of the week.
>>>>
>>>> Regards,
>>>> --
>>>> Hidetoshi
>>>>
>>>> Ahmad Muhanna wrote:
>>>>> Hi Hidetoshi,
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
>>>>>> Sent: Monday, September 14, 2009 7:37 AM
>>>>>> To: Muhanna, Ahmad (RICH1:2H10)
>>>>>> Cc: Mipshop; draft-ietf-mipshop-pfmipv6 at tools.ietf.org; 
>> Jari Arkko
>>>>>> Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
>>>>>>
>>>>>> Hi Ahmad,
>>>>>>
>>>>>> Thanks for your comment. I'm glad to hear an opinion from
>>>> a GRE key
>>>>>> expert. Please see inline:
>>>>>>
>>>>>> Ahmad Muhanna wrote:
>>>>>>> Hi Hidetoshi,
>>>>>>>
>>>>>>> I just have one quick comment and question.
>>>>>>>
>>>>>>> Reading the draft, it seems to me that the GRE keys are
>>>>>> somehow sent
>>>>>>> from the NAR to PAR in the HI (section 4.2). Is that the
>>>> case? This
>>>>>>> means both the DL and UP GRE keys for the bilateral
>>>> tunnels between
>>>>>>> the two AR(s). Is my understanding correct? It also
>>>>>> mentions that the
>>>>>>> format
>>>>>> In terms of the GRE keys for the bilateral tunnel, the working 
>>>>>> assumption is that the DL key is selected by the NAR and
>>>> the UL key
>>>>>> is selected by the PAR. Depending on the fast handover 
>> mode, those 
>>>>>> keys are transferred to the other MAG via either the HI or Hack.
>>>>>>
>>>>>>> of these keys are based on the GRE keys for PMIPv6 
>> draft (section 
>>>>>>> 6.2.6).
>>>>>> Correct.
>>>>>>
>>>>>>> It seems to me that there should be more text to define
>>>> which keys
>>>>>>> exchange in the HI and which in the HaCK
>>>>>> If the above assumption works, I would like to add more 
>> text along 
>>>>>> that line.
>>>>> [Ahmad]
>>>>> That is great. Please add some clarification text to
>>>> clearly indicate
>>>>> that only one key in the HI and the other in the HACK.
>>>>> Since some specification in 3GPP2 depends on this draft, I
>>>> appreciate
>>>>> if you can publish an updated version before the end of the week. 
>>>>> Thanks in advance!
>>>>>
>>>>>>> If both keys are exchanged in the same HI, How these keys are 
>>>>>>> identified at the pAR?
>>>>>>> In GRE keys for PMIPv6 draft, downlink GRE key is included
>>>>>> in the PBU
>>>>>>> and the uplink GRE key in included in the PBA. They never
>>>>>> exist in the
>>>>>>> same message and that way there is no confusing.
>>>>>> So far, each key is conveyed by either the HI or HAck. 
>>>>>> However, I haven't explored all of the possibilities. If you can 
>>>>>> think of any case that two keys must be conveyed in one message, 
>>>>>> please let me know.
>>>>> [Ahmad]
>>>>> I do not see any reason for this case (one key per 
>> message) not to 
>>>>> work for all implementation.
>>>>>  
>>>>>>> In addition, DL and UP GRE keys are generated by NAR and
>>>>>> sent inside
>>>>>>> the HI, my question: Is there any specific reason for 
>> the NAR to 
>>>>>>> specify both GRE keys for the bilateral tunnels?
>>>>>> It would be more problematic that the NAR determines the 
>> both keys 
>>>>>> and I would rather like to avoid it.
>>>>>>
>>>>>>> Sorry for this comment to be so late but hope that you have
>>>>>> the chance
>>>>>>> to take a look at it.
>>>>>> That's ok. The draft is under the review process. Your 
>> comment is 
>>>>>> highly appreciated.
>>>>>>
>>>>>> Regards,
>>>>>> --
>>>>>> Hidetoshi
>>>>>>
>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Regards,
>>>>>>> Ahmad
>>>>>>>  
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: mipshop-bounces at ietf.org
>>>>>>>> [mailto:mipshop-bounces at ietf.org] On Behalf Of Hidetoshi Yokota
>>>>>>>> Sent: Wednesday, September 02, 2009 11:12 PM
>>>>>>>> To: Jari Arkko
>>>>>>>> Cc: Mipshop; draft-ietf-mipshop-pfmipv6 at tools.ietf.org
>>>>>>>> Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
>>>>>>>>
>>>>>>>> Hi Jari,
>>>>>>>>
>>>>>>>> Thanks for your patience. The attached revised document is
>>>>>> supposed to
>>>>>>>> reflect the rest of your comments. Please also see inline,
>>>>>> where the
>>>>>>>> revised part is explained item by item. If there is no
>>>> outstanding
>>>>>>>> issue there, we will upload it shortly.
>>>>>>>>
>>>>>>>> [Apologize if you received it twice. Since the size just
>>>>>> exceeded the
>>>>>>>> limit of this ML, this mail is reposted without the 
>> attachment.]
>>>>>>>> Hidetoshi Yokota wrote:
>>>>>>>>> Hi Jari,
>>>>>>>>>
>>>>>>>>> Appreciate your detailed review. The editorial corrections
>>>>>>>> are mostly
>>>>>>>>> done and the revised version is attached to this mail. 
>>>>>> Regarding the
>>>>>>>>> technical comments, only the policies for the correction
>>>>>>>> are listed for
>>>>>>>>> now. The complete correction will be posted as soon as
>>>>>>>> possible. Please
>>>>>>>>> see inline for the responses to your questions and comments:
>>>>>>>>>
>>>>>>>>> Jari Arkko wrote:
>>>>>>>>>> I have reviewed this document. It was generally in good
>>>>>>>> shape and easy
>>>>>>>>>> to read. I did find a number of issues though. Please
>>>>>>>> discuss them with
>>>>>>>>>> me on this thread and/or revise the draft accordingly.
>>>>>>>>>>
>>>>>>>>>> Technical:
>>>>>>>>>>
>>>>>>>>>> I do not understand the IP host aspects of the
>>>> handover. For an
>>>>>>>>>> unmodified host, what kind of interfaces exist on the
>>>> host, what
>>>>>>>>>> addresses they have, and at what time are interfaces
>>>>>>>> removed or added? 
>>>>>>>>>> Is this exactly the same as in RFC 5213, or does PFMIPv6
>>>>>>>> introduce some
>>>>>>>>>> change here?
>>>>>>>>> The basic principle would be that this specification does
>>>>>>>> not require
>>>>>>>>> any additional IP-level function to the MN running in the
>>>>>>>> PMIPv6 domain.
>>>>>>>>> This MN should therefore be the same as defined in RFC5213.
>>>>>>>>>
>>>>>>>>> A typical network interface would be one with the
>>>>>> cellular network,
>>>>>>>>> where the network basically controls the movement of the
>>>>>>>> MN. Different
>>>>>>>>> types of interfaces could be involved such as different
>>>>>>>> generations (3G
>>>>>>>>> and 3.9G) or different radio access systems. Any type of
>>>>>> IP address
>>>>>>>>> could be assigned (IPv4/v6 or global/private), but the
>>>>>>>> assigned address
>>>>>>>>> must be preserved before and after the handover. PFMIPv6
>>>>>>>> should be able
>>>>>>>>> to handle the single radio situation, where only one
>>>>>>>> interface is active
>>>>>>>>> at any given time. This is a tougher situation in terms of
>>>>>>>> packet loss
>>>>>>>>> and delay.
>>>>>>>>>
>>>>>>>>>> I would like to see a new section on manageability
>>>>>>>> considerations. For
>>>>>>>>>> instance, Section 5 talks about some configuration issues. 
>>>>>>>> These should
>>>>>>>>>> be mentioned, and there should be a description of what
>>>>>>>> the operator
>>>>>>>>>> needs to configure in order to set up a PFMIPv6 network.
>>>>>>>>> We will add a new section for manageability considerations
>>>>>>>> to clarify
>>>>>>>>> the above and to reflect your suggestion.
>>>>>>>> A new subsection is added in Section 5 describing the
>>>>>> above aspects:
>>>>>>>> -------------------
>>>>>>>> 5.  PMIPv6-related Fast Handover Issues
>>>>>>>>
>>>>>>>> 5.1.  Manageability Considerations
>>>>>>>>
>>>>>>>>    This specification does not require any additional IP-level
>>>>>>>>    functionality on the LMA and the MN running in the PMIPv6 
>>>>>>>> domain.  A
>>>>>>>>    typical network interface that the MN could be
>>>> assumed to have
>>>>>>>> is one
>>>>>>>>    with the cellular network, where the network controls the 
>>>>>>>> movement of
>>>>>>>>    the MN.  Different types of interfaces could be
>>>> involved such as
>>>>>>>>    different generations (3G and 3.9G) or different 
>> radio access
>>>>>>>>    systems.  This specification supports a MN with the
>>>> single radio
>>>>>>>>    mode, where only one interface is active at any given
>>>> time.  The
>>>>>>>>    assigned IP address is preserved whether the physical
>>>> interface
>>>>>>>>    changes or not and the MN can identify which
>>>> interface should be
>>>>>>>> used
>>>>>>>>    if there are multiple ones.
>>>>>>>> --------------------
>>>>>>>>
>>>>>>>>
>>>>>>>>>>> If the new router's interface is configured to respond to 
>>>>>>>>>>> queries sent to link-layer addresses than its
>>>>>>>> own (e.g.,
>>>>>>>>>>> set to promiscuous mode), then it can respond to the
>>>> NUD probe,
>>>>>>>>>>> providing its link-layer address in the solicited Neighbor 
>>>>>>>>>>> Advertisement.
>>>>>>>>>> Is this according to RFC 5213? I seem to recall that RFC
>>>>>>>> 5213 operated
>>>>>>>>>> on the same link layer addresses.
>>>>>>>>> I think your observation is correct... I'll check with the
>>>>>>>> other authors
>>>>>>>>> to see if it is ok to rewrite it.
>>>>>>>> The new text doesn't mention the promiscuous mode and
>>>>>> emphasizes the
>>>>>>>> common link-layer address among all MAGs in the PMIPv6 domain:
>>>>>>>>
>>>>>>>> ---------------
>>>>>>>> 5.2.  Expedited Packet Transmission
>>>>>>>>
>>>>>>>>    [...]
>>>>>>>>
>>>>>>>>    The protocol specified in this document is applicable
>>>>>> regardless of
>>>>>>>>    whether link-layer addresses are used between a MN and
>>>>>> its access
>>>>>>>>    router.  A MN should be able to continue sending
>>>> packets on the
>>>>>>>>    uplink even when it changes link.  When link-layer
>>>> addresses are
>>>>>>>>    used, the MN performs Neighbor Unreachability 
>> Detection (NUD)
>>>>>>>>    [RFC4861], after attaching to a new link, probing the 
>>>>>>>> reachability of
>>>>>>>>    its default router.  The new router should respond 
>> to the NUD 
>>>>>>>> probe,
>>>>>>>>    providing its link-layer address in the solicited Neighbor
>>>>>>>>    Advertisement, which is common in the PMIPv6 domain.  
>>>>>>>> Implementations
>>>>>>>>    should allow the MN to continue to send uplink packets
>>>>>> while it is
>>>>>>>>    performing NUD.
>>>>>>>> ----------------
>>>>>>>>
>>>>>>>>>>> At least one mobility option MUST uniquely identify
>>>> the target
>>>>>>>>>>> MN (e.g., the Mobile Node
>>>>>> Identifier
>>>>>>>>>>> Option defined in RFC4283
>>>>>>>> <http://tools.ietf.org/html/rfc4283>) and
>>>>>>>>>>> the transferred context MUST be for one MN per message.
>>>>>>>>>>>   
>>>>>>>>>> I would like the required options to be specified in more
>>>>>>>> detail. Which
>>>>>>>>>> identity options are sufficient to satisfy the MUST?
>>>>>>>>> The required option should be the MN Identifier in the
>>>> Mobile Node
>>>>>>>>> Identifier Option.
>>>>>>>> The above description is added in Section 6.1.1:
>>>>>>>>
>>>>>>>> ---------
>>>>>>>>    Requested option
>>>>>>>>              In order to uniquely identify the target 
>> MN, the MN
>>>>>>>>              Identifier MUST be contained in the Mobile Node 
>>>>>>>> Identifier
>>>>>>>>              Option.
>>>>>>>> ---------
>>>>>>>>
>>>>>>>>>>> If a default set of context information is defined 
>> and always 
>>>>>>>>>>> sufficient, this option is not mandatory.  This
>>>>>>>> option is more
>>>>>>>>>>> useful to retrieve additional or dynamically 
>> selected context 
>>>>>>>>>>> information.
>>>>>>>>>>>
>>>>>>>>>>> Context Request Option is typically used for the
>>>> reactive (NAR-
>>>>>>>>>>> initiated) fast handover mode to retrieve the context
>>>>>> information
>>>>>>>>>>> from the PAR.  When this option is included in the HI
>>>>>> message, all
>>>>>>>>>>> the requested context information SHOULD be included
>>>> in the HAck
>>>>>>>>>>> message in the corresponding mobility option(s) (e.g.,
>>>>>>>> HNP, LMAA or
>>>>>>>>>>> MN-IID mobility options).
>>>>>>>>>>>   
>>>>>>>>>> Please specify what the default set of context
>>>>>> information is, by
>>>>>>>>>> listing the required options when the CRO is not present.
>>>>>>>>> The default context information to request is the Home
>>>>>>>> Network Prefix
>>>>>>>>> Option. If the Mobile Node link-layer is available and
>>>>>>>> used, the Mobile
>>>>>>>>> Node Link-layer Identifier Option MUST also be requested. 
>>>>>>>> With these two
>>>>>>>>> options and the MN identifier, the NMAG can construct the PBU.
>>>>>>>> The above description is added in Section 6.2.1:
>>>>>>>>
>>>>>>>> ----------
>>>>>>>>    The default context information to request is the
>>>> Home Network
>>>>>>>> Prefix
>>>>>>>>    Option.  If the Mobile Node link-layer is available and
>>>>>> used, the
>>>>>>>>    Mobile Node Link-layer Identifier Option MUST also be
>>>> requested.
>>>>>>>> ----------
>>>>>>>>
>>>>>>>>>> Editorial:
>>>>>>>>>>
>>>>>>>>>>>    HO-Initiate:
>>>>>>>>>>>         A generic signaling message, sent from the P-AN
>>>>>>>> to the PMAG that
>>>>>>>>>>>         indicates a MN handover.  While this signaling is
>>>>>>>> dependent on
>>>>>>>>>>>         the access technology, it is assumed that
>>>>>>>> HO-Initiate can carry
>>>>>>>>>>>         the information to identify the MN and to
>>>>>> assist the PMAG
>>>>>>>>>>>         resolve the NMAG and the new access point or the
>>>>>>>> base station to
>>>>>>>>>>>         which the MN is moving to.  The details of this
>>>>>>>> message are
>>>>>>>>>>>         outside the scope of this document.
>>>>>>>>>>>
>>>>>>>>>>> 4. Proxy-based FMIPv6 Protocol Overview
>>>>>>>>>> Section 4 would probably benefit from an additional
>>>>>>>> paragraph at the
>>>>>>>>>> beginning to explain what assumptions there exist about
>>>>>>>> lower layer
>>>>>>>>>> functionality.
>>>>>>>>> Yes, the predictive fast handover relies on the lower layer 
>>>>>>>>> functionality to trigger to send the HI. A new paragraph
>>>>>>>> will be added
>>>>>>>>> to clarify it.
>>>>>>>> -------------
>>>>>>>> 4.  Proxy-based FMIPv6 Protocol Overview
>>>>>>>>
>>>>>>>>    If the MAGs can be informed of the detachment and/or
>>>>>> attachment of
>>>>>>>>    the MN in a timely manner via e.g. the lower layer
>>>> signaling, it
>>>>>>>> will
>>>>>>>>    become possible to optimize the handover procedure,
>>>>>> which involves
>>>>>>>>    establishing a connection on the new link and
>>>> signaling between
>>>>>>>>    mobility agents, compared to the baseline specification
>>>>>> of PMIPv6.
>>>>>>>>   [...]
>>>>>>>> -------------
>>>>>>>>
>>>>>>>> All the other corrections pointed out below have also been 
>>>>>>>> reflected in the revised document.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> --
>>>>>>>> Hidetoshi
>>>>>>>>
>>>>>>>>>>> A new flag 'P' is defined for the HI and HAck messages to 
>>>>>>>>>>> distinguish from those in [RFC5268bis
>>>>>>>>>>>
>>>>>>>> <http://tools.ietf.org/html/draft-ietf-mipshop-pfmipv6-08#ref-
>>>>>>>> RFC5268bis>]
>>>>>>>>>>> and thus MUST
>>>>>>>>>>> be set in the entire document.
>>>>>>>>>>>   
>>>>>>>>>> This would be more readable as " ... those in
>>>>>>>> [RFC5268bis]. This flag
>>>>>>>>>> MUST be ..."
>>>>>>>>> Revised.
>>>>>>>>>
>>>>>>>>>>>    and the NAR creates a proxy NCE to receive those
>>>>>>>> packets for the NCoA
>>>>>>>>>> The term NCE has not been introduced at this stage yet.
>>>>>>>>> Spelled out as "Neighbor Cache Entry".
>>>>>>>>>
>>>>>>>>>>>    address that is used by the MN is MN-HoA.  Hence the
>>>>>>>> PAR forwards
>>>>>>>>>> The term MN-HOA has not been introduced before.
>>>>>>>>> Added the unabbreviated form "Mobile Node's Home Address" 
>>>>>> before it.
>>>>>>>>>>>         The access network to which the MN is attached
>>>>>>>> after handover.
>>>>>>>>>> New term MN, not introduced before.
>>>>>>>>>>
>>>>>>>>> Added "Mobile Node" before it.
>>>>>>>>>
>>>>>>>>>>> specifies forwarding when the MN uses HoA as its
>>>> on-link address
>>>>>>>>>> New term HoA...
>>>>>>>>> Changed to "Home Address".
>>>>>>>>>
>>>>>>>>>>>    as MN's NAI, Home Network Prefix (HNP), IPv4 Home
>>>>>> Address, are
>>>>>>>>>> New term NAI...
>>>>>>>>> Added "Network Access Identifier" before it.
>>>>>>>>>
>>>>>>>>>>>         flag set and include the MN ID, the MN-HNP, the
>>>>>>>> MN-IID and the
>>>>>>>>>> New terms MN-HNP and MN-IID (or at least they do not
>>>>>>>> appear in their
>>>>>>>>>> MN-XXX form before this point).
>>>>>>>>> Modified "MN-HNP" to "HNP" for consistency.
>>>>>>>>>
>>>>>>>>>>>         Inner destination address: HNP or IPv4-MN-HoA
>>>>>>>>>> IPv4-MN-HoA not defined earlier...
>>>>>>>>> Added "Mobile Node's IPv4 Home" before it.
>>>>>>>>>
>>>>>>>>>>>    between the PCoA and NCoA to forward packets for the
>>>>>>>> MN to the NAR,
>>>>>>>>>> New terms PCoA and NCoA... there's probably more undefined
>>>>>>>> terms in the
>>>>>>>>>> document, please check!
>>>>>>>>> Added "Previous Care-of Address" and "New Care-of Address". 
>>>>>>>> Will read
>>>>>>>>> through it to see if there is any other undefined acronym.
>>>>>>>>>
>>>>>>>>>>>    In (i),
>>>>>>>>>> In Step (i),
>>>>>>>>> Revised including other parts.
>>>>>>>>>
>>>>>>>>>>>           |(MN ID, Old AP ID) |     (MN ID, Old AP ID)    
>>>>>>>>  |        |
>>>>>>>>>> Old AP ID? AN ID? AR ID?
>>>>>>>>> AP ID stands for "Access Point Identifier", which is
>>>>>>>> defined in RFC5568.
>>>>>>>>> Added the unabbreviated form and citation.
>>>>>>>>>
>>>>>>>>> The rest of the part will be revised soon.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> --------------------------------------------------------------
>>>>>>>> ----------
>>>>>>>>> _______________________________________________
>>>>>>>>> Mipshop mailing list
>>>>>>>>> Mipshop at ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/mipshop
>>>>>>>> _______________________________________________
>>>>>>>> Mipshop mailing list
>>>>>>>> Mipshop at ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/mipshop
>>>>>>>>
>>>>>
>>>> --
>>>> Hidetoshi Yokota
>>>>
>>>> Mobile Network Lab
>>>> KDDI R&D Laboratories, Inc.
>>>> e-mail:yokota at kddilabs.jp
>>>>
>>>>
>>>
>>>
>>
> 
> 
>