requirements-07

Hello,

Here's my review feedback on draft-ietf-dmm-requirements-07.


   The distributed mobility management (DMM) charter addresses two
   complementary aspects of mobility management procedures: the
   distribution of mobility anchors towards a more flat network and the
   dynamic activation/deactivation of mobility protocol support as an
   enabler to distributed mobility management.  The former aims at
   positioning mobility anchors (e.g., HA, LMA) closer to the user;
   ideally, mobility agents could be collocated with the first-hop
   router. 


The last sentence is aiming at one of the approaches (anchoring at the access network).
There's also another approach, anchoring near the corresponding network.

The important thing is not to deviate from most direct data-path between the MN and CN when providing mobility management.
This can be done by locating the mobility agent near the MN, and also by locating it near the CN.

In order not to limit the language to one of the approaches only, I'd recommend the following re-write for the last sentence:

   The former aims at
   positioning mobility anchors (e.g., HA, LMA) closer to the direct data-path between the MN and the CN;
   (e.g., mobility agents could be collocated with the first-hop router, or with a router near the CN).



   At the IP layer, a mobility management protocol supporting session
   continuity is typically based on the principle of distinguishing
   between identifier and routing address and maintaining a mapping
   between the two.  In Mobile IP, the home address serves as an
   identifier of the device whereas the care-of-address (CoA) takes the
   role of the routing address.  The binding between these two is
   maintained at the home agent (mobility anchor).  If packets can be
   continuously delivered to a mobile node at its home address, then all
   sessions using that home address are unaffected even though the
   routing address (CoA) changes.

I recommend we refer to both IP session continuity, and also IP address reachability.
In my understanding, we are definitely seeking solutions addressing IP session continuity.
Meanwhile, solutions addressing IP address reachability is welcome too.



   Mobility management functions may also be distributed to multiple
   networks as shown in Figure 2, so that a mobile node in any of these
   networks may be served by a nearby mobility function (MF).

I think the original intention was to state "near to MN". But like I explained above, that's just one approach. 
We can state "may be served by a mobility function that is located close to the direct MN-CN data-path".


          IP mobility, network access and routing solutions provided by
          DMM MUST enable distributed processing for mobility management
          so that traffic does not need to traverse centrally deployed
          mobility anchors and thereby avoid non-optimal routes.

Some people may consider an anchor located near CN as centralized, in some sense. 
But obviously, this is not the same kind of centralization caused by using a HA located in core network, and not causing the non-optimal route. In order to prevent such confusion, I'd recommend the following text:

          IP mobility, network access and routing solutions provided by
          DMM MUST enable distributed processing for mobility management
          so that traffic does not follow non-optimal routes caused by 
          having to traverse centrally deployed mobility anchors.


   This requirement addresses the problems PS1, PS2, PS3, and PS4
   described in Section 4.  (Existing route optimization is only a host-
   based solution.

Now there are also router-based solutions available (cnet-homing, flows-distribution-and-handoff).
So, I recommend we either provide a reference and qualify the term "existing", or remove this statement.


          DMM solutions MUST provide transparent mobility support above
          the IP layer when needed.

I'd say "SHOULD". We may consider some solutions that expose the IP address change to the apps, and expect apps to do something with it. We haven't discussed them yet, but I don't see a reason why we should shut the door on them.

Also: The present API-based approaches and the following text suggests some awareness on the app is useful.

   Infrequent node mobility
   coupled with application intelligence suggest that mobility support
   could be provided selectively, thus reducing the amount of context
   maintained in the network.

The motivation text does not seem to match this requirement either:

          Motivation: The motivation of this requirement is to enable
          more efficient use of network resources and more efficient
          routing by not maintaining context at the mobility anchor when
          there is no such need.


I'd recommend we modify the requirement as:

          DMM solutions SHOULD provide transparent mobility support above
          the IP layer when needed.  Such transparency is needed, for
          example, when, upon change of point of attachment to the
          network, an application flow cannot cope with a change in the
          IP address.  However, it is not always necessary to maintain a
          stable home IP address or prefix for every application or at
          all times for a mobile node. Some DMM solutions MAY expose 
          mobility to the layers above IP.





          DMM solutions SHOULD target IPv6 as the primary deployment
          environment and SHOULD NOT be tailored specifically to support
          IPv4, in particular in situations where private IPv4 addresses
          and/or NATs are used.

Is this the commonly-used language regarding the treatment of IPv4 in IETF, or something we came up with?
People may argue what is considered as "tailoring".


          A DMM solution SHOULD first consider reusing and extending
          IETF-standardized protocols before specifying new protocols.

I'd say "MUST". How can we not ? :-)

Thanks!

Alper

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