comments about draft-zuniga-dmm-gap-analysis

Please find some comments about version 2 of draft-zuniga-dmm-gap-analysis below.

General comments:

I think the draft addresses a good set of available mobility protocols, even though I still believe
that support from non-mobility protocols should be considered to solve DMM.

Maybe protocols for anchor selection and reselection should be included to the analysis? Depends
on whether the selection of anchors during initial attach and relocation of a mobility anchor is in
scope of the solution to be specified.

I think it's very valuable to analyze how each protocol can contribute to DMM and the draft
matches the available protocol components against the defined requirements. What's not clear
from the chosen bottom-up approach is whether such contribution is needed in a solution and
how the contribution fits into the overall DMM scenario. The WG never converged on any
design constraints and design goals so far. That's a major weak point, IMHO. I think we need
to go bottom-up as well as top-down.  On the very top, we may agree and define design constraints
and the associated scenarios (role of the MN in DMM; capability to handle multiple IP addresses,
one for continued use after anchor relocation, another one, which is topologically correct at the
MN's current anchor). Maybe such design constraints can be anchored in the requirements draft.

Some concrete comments:

Why does the draft refer sometimes to 3GPP analogies, e.g. in Sect. 2.2.2? Is it to x-check applicability
in the evolved packet core? Well, personally I think it makes sense to consider hooks to the DMM
solution to enable inter-working with and support from external components. But this is not
really related to the analysis of gaps with available IP mobility protocols.

Section 3.1.2, HA switch
Isn't it a gap to enable IP address continuity at the relocated HA? So, MIPv6 could provide means
for the MN to convey HoA context from the previous HA. An appropriate extension to MIPv6
could close that gap. Correct? Such information may be provided with the analysis draft as well.

Section 3.1.6, LMA runtime assignment
The draft says '..not clear how the technology can be used to achieve DMM..' well, the document
should go beyond a suitability analysis. From the spec of LMA runtime assignment I understand
that it's meant to be used solely at the MN's attach. So a loaded LMA can refer to a different
one. A gap is to perform the operation at any time. Further gap is that it's the current anchor
that initiates relocation. Maybe not a gap, but at least a limitation. Another gap, since out of scope
of the specification, is the transfer of registration context between LMAs. 

The analysis should try to assess suitability of a protocol component to support DMM and
identify the functional components that need to be added to enable re-use of the existing
protocol. Such missing functional component can be added either to the existing protocol,
or provided by other protocols.

Section 4.
I think in general it's useful to summarize all findings in a table, but in this case I have
difficulties to conclude how each protocol can find itself in the DMM solution. Here,
according to my opinion, a parallel top-down approach can help. Knowing about design
goals and constraints, we can have a common picture of a solution in mind.
Then it's easier to understand how each of these protocols contribute to that picture.

Hope it helps.

marco