review of draft-ietf-dmm-best-practices-gap-analysis-02

Please find below some comments about draft-ietf-dmm-best-practices-gap-analysis-02.
Authors did a good job in merging two BCP and gap analysis drafts. I have some comments
though which may help to improve readability and gaining advantage from such document.

General notes:

I think it's important to consider MN capability in the gap analysis.
If a host cannot differentiate the type of source IP address (deprecated, current),
it's supposed to be a gap, isn't it? Not sure we can just assume the MN can handle
and use multiple IP addresses in a DMM-friendly way, means not
to use IP addresses from previous anchors for new data sessions.
Maybe a small section on host considerations would be good.

About Section 5, which is about the gap analysis, my personal opinion is that it's
better to match gaps against functional elements, which are required to enable
optimal decentralized deployment and optimal paths, instead of describing them
by a match against a list of requirements as per the DMM requirements draft.
The advantage of the match against identified functions for DMM is that the
protocol gap gets clear, e.g. export/import of HoA context and transfer between
anchors, data plane indirection to transport packets to an anchor, which imports
a topologically incorrect HoA,.. 
Just an opinion, not necessarily biased by being an author of a DMM framework draft ;-)


Section 1. Introduction

'.. how these functions can be reconfigured to work in a DMM environment..'

What does reconfiguration of functions mean? A HA or LMA have different function. These
are co-located. Now you can place one or multiple HAs on different locations in the topology
to enable DMM by exploiting e.g. multiple registration support. But the meaning of reconfiguration
in this context is not clear to me.

Section 2. Terminology

This section defines some terms for relevant functions. These should be related to IP mobility protocols
or refer to general functions, such as a router, which has no mobility functionality.

It defines Mobility Routing as the function to intercept packets. Typically that's the
topological anchor doing that, otherwise the packet won't arrive at that function.
Sect. 3 introduces the AF. If that's really considered a separate function compared to
the MR, I'd propose defining all relevant functions in the Terms section 2 instead of
introducing the AF in section 3. But IMHO, these are the same functions.

Location Management: Why not using known terms of locator and identifier IP addresses?
The Location Management resolved the HoA/HNP, which is treated as identifier, into the
locator IP address, which is the topologically correct address representing the MN's location,
e.g. the (proxy) CoA. The chosen term 'MN routing address' seems not so clear to me.
 

Section 3. Functions of existing mobility protocols

'..are both logically centralized mobility management approaches..'
 
Does this refer to fact that protocol specifications co-locate several of the
functions MR/AF, LM.. ? That's not centralized.
Or does it refer to the centralized deployment of mobility anchors? Here I would
disagree. You can deploy host MIP and PMIP in a decentralized way by placing LMAs/HAs
at the edge. Continuity of IP addresses works out of the box. Please clarify which kind of
centralization you refer to here.

'Internetwork Location Management'. Text needs IMO clarification about the
kind of resolution. This is a mobility-specific function and I'd describe it
as it resolves the HoA of the MN into a locator IP address, either a CoA
(MIP, PMIP) or a next mobility anchor (MAP). In case of HMIP, there is
simply a chain of LMs, each doing the same. It must be clear in the text
that the LM is a mobility protocol-specific function.

Section 4.1

'Since this document cannot be too exhaustive..'

I don't think that's the constraint to limit the number of pages of this document ;-)
I'd describe that the scope of the BCP and the gap analysis is determined clearly by given
IP mobility protocols and any kind of deployment options which do not violate the
original specification.

Point number 3 in the list:

'..IP flows of applications which do not need a constant IP address should not be handled by DMM..'

I don't think the DMM solution explicitly excludes traffic of such applications; that's how I read it.
What about this: "Applications which adopt to changes in the MN's IP address do not depend on DMM."

Point number 4 in this list: 
'4.  Mobility management and traffic redirection should only be
       triggered due to IP mobility reasons, that is when the MN moves
       from the point of attachment where the IP flow was originally
       initiated.'

Please clarify what's meant with 'point of attachment' here. Is it the
topological anchor of the MN's IP address (HA, LMA) or is it the
Access Point/Router, which represents the locator/CoA?

Section 4.2.2 Network-based IP DMM practices

'As with Mobile IPv6, plain Proxy Mobile IPv6 operation cannot be easily decentralized..'

I would not see it that strict, as the draft describes later that decentralized deployment
is possible by placing LMAs at the edge. That's decentralization. Also it results in a good
routing path to the MN (from the mobility anchor point of view). That path turns into
a more sub-optimal one after mobility. So, I would separate the problem of decentralized
operation and maintenance of optimal paths in this analysis.

Section 4.3. 3GPP network flattening approaches

I fully agree that 3GPP is a potential vendor of DMM solutions, but I am wondering
how relevant this larger section is in the BCP and gap analysis draft. It could be shortened
by just describing that 3GPP deploys local anchor points for MNs (to differentiate from
TOF-like hacks for UMTS) and has mechanisms for local anchor selection according
to the MN's location. Just as a note.

Section 5.1

It's written that for client MIP it's not an issue to manage multiple IP addresses
anchored at different anchors. Maybe it should be noted to have a gap on the
MN to handle IP addresses in a DMM-friendly way. That means IP addresses
of previous mobility anchors are classified as deprecated and should not
be used for new sessions.

This section describes the gap of transferring mobility context between anchors.
If the intention is to import mobility context including HoA into a different anchor,
a relevant gap is the forwarding of traffic to that importing anchor. That gap can
be seen in the routing plane above anchors or in mobility-protocols to forward
traffic from a topologically correct previous anchor to the importing anchor.
 

Best regards,
marco