Subject: [netlmm] AD review of draft-ietf-netlmm-mip-interactions

From: Jari Arkko <[email-masked]>
Date: Wed, 09 Dec 2009 13:41:41 +0200

I have finally made my AD review of this document. Apologies for the 
delay. Overall, the document was easy to read and I had no major 
problems. I do want you to revise the document for the following issues, 
however:

The document should state that the list of scenarios is not exhaustive. 
(Or convince the reader that the given scenarios are the only possible 
ones.)

Section 3.2 should talk about how you can identify nodes that get PMIP 
service and those that don't. This does not seem like a trivial 
exercise. You can make a policy lookup, but then you rely on the 
operator knowing what software your device has. I realize that you rule 
this out of scope later, and I do not ask you to explain the specific 
mechanisms. I am asking you to outline the implications of having a 
mechanism.

I would also like the authors to respond to Christian Vogt's review 
(posted October 1st). I did not see a response, but maybe I missed it.

What about Basavaraj Patil's question in the mailing list on October 
21st? Is there a need to add something to the document about his scenario?

>    The solution for this scenario may depend on the access network being
>    able to determine that a particular mobile node wants to use Mobile
>    IPv6.  
Only a "may depend"? How would it otherwise work? I would suggest /s/may 
depend/depend/

> As described in
> [RFC4877 <http://tools.ietf.org/html/rfc4877>], the identifier of the MN is known by the Home Agent
> after the IKEv2 exchange, but this is not used in the MIPv6
> signaling, nor as a lookup key for the binding cache.

Maybe you should bring that if authentication is performed at the MIP 
layer (authentication option) then this information is available. In 
other words, authentication mechanisms differ with respect to the ease 
that the identifier will be available.

> Since all these steps must be performed by the mobile node before
> sending the Binding Update, they have an impact on the handover
> latency experienced by the MN.  For this reason it is recommended
> that the mobile node establishes the IPsec security association (and
> consequently is provided by the HA/LMA with a MIPv6-HoA) when it is
> still attached to the PMIPv6 domain.

But the steps are configuration tasks, and there is no need to perform 
them on a per-movement basis. A far better recommendation would be to 
move the steps to mobile node initialization time or to a periodic process.

> The MAG needs to discover the
> HA/LMA; however the current version of [RFC5213 <http://tools.ietf.org/html/rfc5213>] assumes that the LMA
> is assigned to the MAG or discovered by the MAG when the mobile node
> attaches to the MAG. the exact mechanism is not specified in
> [RFC5213 <http://tools.ietf.org/html/rfc5213>]. 

I think it would be fair to state somewhere that in configurations where 
there is just one of these nodes, the discovery is not an issue.

> This document requires that the a home agent that also implements the
> PMIPv6 LMA functionality should allow both the mobile node and the
> authorized MAGs to modify the binding cache entries for the mobile
> node.  Note that the compromised MAG threat described in [RFC4832 <http://tools.ietf.org/html/rfc4832>]
> applies also here.
>   

I would like to see a discussion of what the security policy database 
entries need to look like in this situation. For instance, is it 
possible to have such a configuration?

> The scenarios where Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6
> (MIPv6) protocols are both deployed in a network require some
> analysis and considerations.  This document describes all identified
> possible scenarios, which require an interaction between PMIPv6 and
> MIPv6 and discusses all issues related to these scenarios.  Solutions
> and recommendations to enable these scenarios are also described.

Clumsy language. Maybe "The use of Proxy Mobile IPv6 (PMIPv6) and Mobile 
IPv6 (MIPv6) in the same network requires some care. This document 
discusses scenarios where such mixed usage is appropriate and points out 
the need for interaction between the two mechanisms. Solutions ..."

>    Some SDOs are also investigating more complex scenarios where the
Expand the term SDO or use some other phrase.

> However, in case there are nodes that implement Mobile IPv6 and want
> to use this protocol, the network must offer MIPv6 service to them.
>   

There is no "MIPv6 service" in this case. It would be better to say, 
e.g., "must offer plain IP connectivity service without proxy mobility".

>    advertising the HNP, the MAG should advertise the topologically

The term HNP has not appeared before (at least not outside "MN-HNP" 
which is presumably another term).

> This section highlights some considerations that are applicable to
> scenario C where the LMA and HA are logically collocated and need to
> be evaluated when selecting the technical approach to be chosen.
>   

Complex sentence that seems to be repeating the same thing.

> based on the base specification [RFC3775 <http://tools.ietf.org/html/rfc3775>]

I'm sure there's a better way to write this...

>           ordered by a timestamp option. .

Garbage at the end.

> If a different LMA is
> assigned to the MAG, the mobile node will not be on the home
> link but will still have an active MIPv6 binding cache entry
> and this may be not desirable in some deployments..
>   

Garbage at the end. Please also explain why this is not desirable.

>    LMA hss changed, and therefore the mobile node sends a MIPv6 Binding

s/hss/has/

>    o  The downlink packets in the case where both the MIPv6 binding
>       cache entry and PMIPv6 binding cache entry exist are processed as
>       follows:
>
>    o
>
>       1.  The MIPv6 binding cache entry is processed first.  If the
>   

Odd indentation & bullet style.

Jari