Analysis of Multihoming in Network Mobility Support
draft-ietf-nemo-multihoming-issues-07

Maybe I started reading this document with the wrong set of expectations, but one set of issues that I'd like to have seen discussed is how the choice of configuration interacts with higher layer protocols (transports and applications).

For example, in the (1,1,n) configuration, where you either have tunnel or you don't, the end-to-end path that is exposed to higher layers is already becoming a lot more dynamic than in a non-mobile case, but at least not significantly more so than with, say, basic MobileIP.

Compare that to the (n,n,n) configuration, especially if MRs try to become clever and start to load-balance, bandwidth-aggregate or path-select across all these connectivity options. There is a potential here to really mess up the control loops of higher-layer protocols. (More so than with basic MobileIP, because there mobility events are visible at the end system stack, and it is possible to involve the higher layers in the decision making. Not so with NEMO, because decisions are made on MR and the end systems remain unaware what's going on one hop away.)

Maybe this isn't the document to discuss this? Is NEMO looking at this problem space somewhere else?

  From the Gen-ART Review by Miguel Garcia ...

  The document is well written and easy to understand. I just have a
  few nits.

  - Section 1, second paragraph. The last sentence in this paragraph
  spans across 6 lines and lacks readability. It should be improved.

  - Section 1, first set of bullet points. There seems to be strange
  characters at the end of a sentence, or is it an arrow?

    o  multiple global prefixes are available in the mobile network.-->

  - Acronyms: The acronym MNP is first used in Section 1, 5th paragraph.
  However, it is not expanded there, but it should. Expand the acronym AR
  in Figure 1. Expand W-PAN in Example 2 in Section 3.1.

  - Double reference. In Section 4.1 there is a double cross reference
  to reference [8]. I assume this is an error:

    "These are also discussed in [8] and [8] by the Shim6 WG."

  - Suggestion: add a informative reference to DHCPv6 in the last
  sentence of Section 2.

  - IDnits reports a number of outdated references, probably due to new
  updates while this document was frozen and progressing in the process. 
  It also reports some Down references, but they are not applicable, 
  because idnits considers the intended status is "Proposed Standard" 
  rather than Informational.