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

Folks,

I did some brief reading on the -02 version (mainly to trigger even
some discussion!). Here are my initial comments.

I am quite pleased with the sections up to 5. Good stuff.

In Section 5.2. 

   whether the allocated IP addresses are anchored).  However, there are
   ongoing IETF works that are proposing that the network could indicate
   the different IP addresses properties during assignment procedures
   [I-D.bhandari-dhc-class-based-prefix],
   [I-D.korhonen-6man-prefix-properties].

* Here I would also reference to latest MPVD activities in Mif, since in my
  mind PVDs could.. could'ish.. also be used to carry properties & information
  about prefixes.

* Anyway, I would like to stress in this section that even if we have individual
  attempts to fix the gap, there is no solution in IETF.. not even close that 
  would be accepted & endorsed by IETF.

Section 5.8.

  "o  Existing solutions do only provide an optimal initial anchor
      assignment, a gap being the lack of dynamic anchor change/new
      anchor assignment.  Neither the HA switch nor the LMA runtime
      assignment allow changing the anchor during an ongoing session."

* In theory MOBIKE could be used to switch from a gateway to another  
  mid-session.. from the MN point of view. There is no protocol for the
  network side (there _was_ an attempt to do a gw-to-gw thing years ago).
  Agree that there is nothing for (P)MIPv6.

  "o  Currently, there is no efficient mechanism specified by the IETF
      that allows to dynamically discover the presence of nodes that can
      play the role of anchor, discover their capabilities and allow the
      selection of the most suitable one."

* Hmm, DHAAD? H-flag in RA? The MAP option in RAs? We do have multiple
  mechanisms it seems. In some cases we can even distinguish between a
  "local" vs. "normal" anchor. Using DHAAD one could use anycast to
  locate topologically close HAs.

* For RFC5685 allows us to do IKEv2 to anycast address. That combined to
  RFC5026 would allow discover topologically close HA. Same for with
  RFC4555 to enhance MOBIKE gateway selection. Routing infra  would be
  used to select the "most suitable" from locality point of view.

* What is meant by the "capability" of an anchor? Local vs. non-local?
  I do agree we only can distinguish between on-link HA vs. MAP vs.
  something beyond on-link. And that is not much.

I would say the above existing mechanisms need to be reflected in the 
document.

  "o  The mobile node needs to simultaneously use multiple IP addresses,
      which requires additional support which might not be available on
      the mobile node's stack, especially for the case of network-based
      solutions."

* This gap means what? Is the additional support what REQ2 is about?
  Like giving a meaning to prefixes which are anchored and which not?

  "o  While existing network-based DMM practices may allow to deploy
      multiple LMAs and dynamically select the best one, this requires
      to still keep some centralization in the control plane, to access
      on the policy store (as defined in RFC5213)."

* Ok.. so you are saying a subscriber database or AAA server, which is
  central makes a mobility protocol centralized?

Since I got the feeling folks want to work more on the control and data
plane separation, the summary should state the lack of solutions in
that space more clearly (ok.. there is now stuff coming from Netext
for PMIP but still).

And about the table. An 'X' means a gap? It is not really said anywhere
how to interpret the table.

By the way, I would add a disclaimer that this document does not consider
transport layer solutions like mptcp since they are not mobility protocols
per se. I think we need this disclaimer, since e.g. mptcp is now deployed
to allow mobility with specific services.

- Jouni