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 _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
