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

[Jari Arkko <jari.arkko at piuha.net>]

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?

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.

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

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

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

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.

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

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

>    address that is used by the MN is MN-HoA.  Hence the PAR forwards

The term MN-HOA has not been introduced before.


>         The access network to which the MN is attached after handover.

New term MN, not introduced before.


> specifies forwarding when the MN uses HoA as its on-link address

New term HoA...

>    as MN's NAI, Home Network Prefix (HNP), IPv4 Home Address, are

New term NAI...

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

>         Inner destination address: HNP or IPv4-MN-HoA

IPv4-MN-HoA not defined earlier...



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

>    In (i),
In Step (i),

>           |(MN ID, Old AP ID) |     (MN ID, Old AP ID)     |        |

Old AP ID? AN ID? AR ID?

Jari