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

[Hidetoshi Yokota <yokota at kddilabs.jp>]

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