Gap analysis comments

Hello,

Please see below for my comments on this document.


   The present document analyses deplyment practices of existing
   mobility protocols in a distributed mobility management environment.

Are the protocols mentioned in this document all deployed?? I don't think so.
It looks more like "protocols with specifications" that can be envisioned to be used in DMM style. Correct?



  1.  Anchoring function (AF): allocation to a mobile node of an IP
       addres/prefix (e.g., a HoA or HNP) topologically anchored by the
       delegating node (i.e., the anchor node is able to advertise a
       connected route into the routing infrastructure for the delegated
       IP prefixes).

   2.  Mobility Routing (MR) function: packets interception and
       forwarding to/from the IP address/prefix delegated to the MN,
       based on the internetwork location information, either to the
       destination or to some other network element that knows how to
       forward the packets to their destination;


   3.  Internetwork Location Management (LM) function: managing and
       keeping track of the internetwork location of an MN, which
       includes a mapping of the IP delegated address/prefix (e.g., HoA
       or HNP) to the mobility anchoring point where the MN is anchored
       to;

   4.  Location Update (LU): provisioning of MN location information to
       the LM function;


I perceive AF and MR are inseparable.
Also, LU is part of LM.
(if we really want to break LU out of LM, then we also need to enumerate the part that deals with encap/decap functionality)


       Typically, the a connection manager together
       with the operating system configure the source address selection
       mechanism of the IP stack. 

Does the CM really do that? I don't think so. CM selects the network to attach to. Whatever IP addresses are configured gets selected by the Src Address Selection algorithm, which does not interface with the CM as far as I know.

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

The term "constant IP address" is vague. We should mention both "IP session continuity" and "IP address reachability (of permanent IP address)", and state that providing the former is in the scope of DMM but not the latter. Note that both of these features deal with somewhat "constant" IP address, though with varying lifetime. In IP session continuity, the IP address is constant throughout out the IP session, and may change afterwards. In IP address reachability, the IP address is constant even when there is no IP session (you know, it's used for things like running a server on the MN, which needs to accept incoming connections at the published IP address).


The draft also mentions MOBIKE. But note that MOBIKE by itself does not give us a DMM solution. It provides a MM solution, and in a special setup it can be used for a DMM solution (e.g., by dynamically allocating the VPN server, etc.)


   o  Multiple (distributed) anchoring: ability to anchor different
      sessions of a single mobile node at different anchors.  In order
      to make this feature "DMM-friendly", some anchors might need to be
      placed closer to the mobile node.

What matters is placing the anchor closer to the direct IP path between the MN and the CN.
Closure to that direct path can be achieved by placing the anchor near the MN, and also near the CN.
So, I'd propose the following revision:

   o  Multiple (distributed) anchoring: ability to anchor different
      sessions of a single mobile node at different anchors.  In order
      to make this feature "DMM-friendly", some anchors might need to be
      placed closer to the mobile node or the corresponding node.

Or, if we don't want to get in this level of detail, we can say the following:

   o  Multiple (distributed) anchoring: ability to anchor different
      sessions of a single mobile node at different anchors.  In order
      to make this feature "DMM-friendly", some anchors need to be
      placed closer to direct IP path between the mobile node and the corresponding node.



   This for example implies
   having the knowledge of which sessions are active at the mobile node,
   which is something typically known only by the MN e.g., by its
   connection manager).  

Again, I don't think CM knows about the active IP sessions.

Cheers,

Alper

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm