Re: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt

[h chan <[e-mail]>]

Sri,

We have revised the problem statements in Section 4 in version 08. Our responses are in-line. Please check again.

4.  Problem Statement

   The problems that can be addressed with DMM are summarized in the
   following:

   PS1:  Non-optimal routes

         Routing via a centralized anchor often results in non-optimal
         routes, thereby increasing the end-to-end delay.  The problem
         is manifested, for example, when accessing a local server or
         servers of a Content Delivery Network (CDN), or when receiving
         locally available IP multicast or sending IP multicast packets.

   PS2:  Divergence from other evolutionary trends in network
         architectures such as distribution of content delivery.

         Centralized mobility management can become non-optimal with a
         flat network architecture.

   PS3:  Low scalability of centralized tunnel management and mobility
         context maintenance

         Setting up tunnels through a central anchor and maintaining
         mobility context for each MN usually requires more concentrated
         resources in a centralized design, thus reducing scalability.
         Distributing the tunnel maintenance function and the mobility
         context maintenance function among different network entities
         with proper signaling protocol design can increase scalability.

   PS4:  Single point of failure and attack

         Centralized anchoring designs may be more vulnerable to single
         points of failures and attacks than a distributed system.  The
         impact of a successful attack on a system with centralized
         mobility management can be far greater as well.

   PS5:  Unnecessary mobility support to nodes that do not need it

         IP mobility support is not always required, and not every
         parameter of mobility context is always used.  For example,
         some applications do not need a stable IP address during a
         handover to maintain session continuity.  Sometimes, the entire
         application session runs while the terminal does not change the
         point of attachment.  Besides, some sessions, e.g.  SIP-based
         sessions, can handle mobility at the application layer and
         hence do not need IP mobility support; it is then more
         efficient to deactivate IP mobility support for such sessions.

   PS6:  (Related problem) Mobility signaling overhead with peer-to-peer
         communication

         Wasting resources when mobility signaling (e.g., maintenance of
         the tunnel, keep alive signaling, etc.) is not turned off for
         peer-to-peer communication.  Peer-to-peer communications have
         particular traffic patterns that often do not benefit from
         mobility support from the network.  Thus, the associated
         mobility support signaling (e.g., maintenance of the tunnel,
         keep alive signaling, etc.) wastes network resources for no
         application gain.

   PS7:  (Related problem) Deployment with multiple mobility solutions

         There are already many variants and extensions of MIP.
         Deployment of new mobility management solutions can be
         challenging, and debugging difficult, when they must co-exist
         with solutions already in the field.

   PS8:  Duplicate multicast traffic

         IP multicast distribution over architectures using IP mobility
         solutions (e.g.  RFC6224) may lead to convergence of duplicated
         multicast subscriptions towards the downstream tunnel entity
         (e.g.  MAG in PMIPv6).  Concretely, when multicast subscription
         for individual mobile nodes is coupled with mobility tunnels
         (e.g.  PMIPv6 tunnel), duplicate multicast subscription(s) is
         prone to be received through different upstream paths.  This
         problem may also exist or be more severe in a distributed
         mobility environment.

The following have contributed to the above revisions in draft 08: Pierrick, Dapeng, and Jouni


From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Sri Gundavelli (sgundave)
Sent: Sunday, August 25, 2013 10:04 PM
To: [e-mail]<mailto:[e-mail]>
Subject: Re: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt

Please see inline for some comments.

Regards
Sri






4.  Problem Statement



   The problems that can be addressed with DMM are summarized in the

   following:



   PS1:  Non-optimal routes



         Routing via a centralized anchor often results in a longer

         route.

[Sri] "longer route" ?  I assume this is about routing/tx delay. Please re-word.



Accept and revised in version 08



The problem is manifested, for example, when accessing

         a local server or servers of a Content Delivery Network (CDN),

         or when receiving locally available IP multicast or sending IP

         multicast packets.



[Sri] Does RFC 6705, or RFC 6909 does not address this issue ? May be the CDN example is incorrect.



CDN example is also an important driver: distributing the mobility anchor is more compatible with distributing and replicating the contents, which may be more general to the particular protocol solutions. It may also include the case that there is a CDN server is in a neighboring network. Suggestions to reword (for version 09) are welcome.



   PS2:  Divergence from other evolutionary trends in network

         architectures such as distribution of content delivery.



         Centralized mobility management can become non-optimal with a

         flat network architecture.



[Sri] How is this making the case of DMM ? We want the MN to access content locally in the access network and we want localized routing. We have that in the form of 6705 and 6909. The other approach is give localized IP addresses and have the content locally accessed. There are simply two many considerations and points may be valid, but when we bring all those assumptions. We are bringing these points in a less logical manner without stating the assumptions.



Our response is similar to that in PS1. Also PS2 is referring to flat mobile network.



   PS3:  Low scalability of centralized tunnel management and mobility

         context maintenance



         Setting up tunnels through a central anchor and maintaining

         mobility context for each MN usually requires more concentrated

         resources in a centralized design, thus reducing scalability.

         Distributing the tunnel maintenance function and the mobility

         context maintenance function among different network entities

         with proper signaling protocol design can increase scalability.



   PS4:  Single point of failure and attack



         Centralized anchoring designs may be more vulnerable to single

         points of failures and attacks than a distributed system.  The

         impact of a successful attack on a system with centralized

         mobility management can be far greater as well.



   PS5:  Unnecessarily reserving resources to provide mobility support

         to nodes that do not need such support



         IP mobility support is not always required, and not every

         parameter of mobility context is always used.  For example,

         some applications do not need a stable IP address during a

         handover to maintain session continuity.  Sometimes, the entire

         application session runs while the terminal does not change the

         point of attachment.  Besides, some sessions, e.g.  SIP-based

         sessions, can handle mobility at the application layer and

         hence do not need IP mobility support; it is then more

         efficient to deactivate IP mobility support for such sessions.



[Sri]  Mobility systems today do support the aspect of service for the subscriber, as "Simple IP", or "Mobile IP". A PDSN can assign a local IP address and it does not have to be the home address. Network does have this intelligence, but what is missing is the client's ability to pick the correct type of IP address, among different IP addresses. The network is also the missing the aspect of marking those addresses with proper properties. The currently active drafts in IETF are to address this issue. We should talk about these missing semantics.

draft-bhandari-dhc-class-based-prefix-05<http://datatracker.ietf.org/doc/draft-bhandari-dhc-class-based-prefix/>

draft-korhonen-6man-prefix-properties-02<http://datatracker.ietf.org/doc/draft-korhonen-6man-prefix-properties/>



We need to find a suitable place to add these references. One place is to append to the end of Section 3 where it is talking about DMM work. The other possibility is to add it as one of the considerations list in the Introduction. Any suggestion?

   PS6:  (Related problem) Mobility signaling overhead with peer-to-peer

         communication



         Wasting resources when mobility signaling (e.g., maintenance of

         the tunnel, keep alive signaling, etc.) is not turned off for

         peer-to-peer communication.  Peer-to-peer communications have

         particular traffic patterns that often do not benefit from

         mobility support from the network.  Thus, the associated

         mobility support signaling (e.g., maintenance of the tunnel,

         keep alive signaling, etc.) wastes network resources for no

         application gain.  In such a case, it is better to enable

         mobility support selectively.



[Sri] How is PS6 different from PS5 ? We talk about application's ability to pick the address with or without mobility properties in PS5. So, the traffic patterns can be localized based on the application requirements. But, even if we take the argument that mobility is not required, operator needs visibility into these flows and so they can charge.  Again, we have 6705 and 6909 for adjusting to those traffic patterns. So, this P without those considerations is incomplete.



Both PS5 and PS6 have been revised in version 08. If desired, we can clarify further (version 09?) that PS6 is about turning off the tunneling and signaling.

   PS7:  (Related problem) Deployment with multiple mobility solutions



         There are already many variants and extensions of MIP.

         Deployment of new mobility management solutions can be

         challenging, and debugging difficult, when they must co-exist

         with solutions already in the field.







   PS8:  Duplicate multicast traffic



         IP multicast distribution over architectures using IP mobility

         solutions (e.g.  RFC6224) may lead to convergence of duplicated

         multicast subscriptions towards the downstream tunnel entity

         (e.g.  MAG in PMIPv6).  Concretely, when multicast subscription

         for individual mobile nodes is coupled with mobility tunnels

         (e.g.  PMIPv6 tunnel), duplicate multicast subscription(s) is







Chan (Ed.), et al.      Expires February 3, 2014               [Page 10]



Internet-Draft                  DMM-Reqs                     August 2013





         prone to be received through different upstream paths.  This

         problem may also exist or be more severe in a distributed

         mobility environment.



[Sri] Is this for MN's from different LMA's attached to the same MAG ?


It is one example.