[DMM] draft-ietf-dmm-requirements-10.txt

[h chan <[e-mail]>]

May I propose to complete the requirements draft with the following schedule:

Sri mentioned there are editorial issues during the IETF meeting and will respond by end of coming Sunday.
If anyone else have further comments, please keep to this deadline of Sunday November 17.

I don't mean to suggest a deadline in short notice, but the WGLC had already closed about half year ago. I do thank all of you for all the comments received both before and after WGLC, which have contributed so much to improve the requirements draft.

Also, if there are additional comments, I hope to finish resolving them within next week.

So when you make these late comments, please also provide suggested text changes. That will shorten the cycles to go back and forth to resolve these comments.

The requirements draft can then proceed with the next step.

Completing the existing items of requirements and gap analyses are helpful as we look forward to new interesting work items.

Thanks to all of you.

H Anthony Chan

From: h chan
Sent: Tuesday, November 05, 2013 4:31 PM
To: 'Sri Gundavelli (sgundave)'; '[e-mail]'
Subject: RE: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt

May I request anyone with any more comments or un-closed issue on the requirements to please speak up with suggested text changes to agree on now. I can do one more revision by Thursday to enable the wg to move to the next step before the Friday DMM meeting.

The gap analysis draft is waiting for the requirements draft to complete.

And the future interesting work of this wg (including yours) are waiting for the gap analysis draft to complete.

H Anthony Chan

From: h chan
Sent: Saturday, September 28, 2013 8:28 AM
To: 'Sri Gundavelli (sgundave)'; '[e-mail]'
Subject: RE: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt

Sri,
It appears that version 09 has attempted to address all your comments. Please check.

H Anthony Chan

From: h chan
Sent: Saturday, September 28, 2013 10:25 AM
To: 'Sri Gundavelli (sgundave)'; '[e-mail]'
Subject: RE: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt

Sri,

We have revised the Introduction Section and PS1 in version 09. Our responses are in-line.

The following have contributed to the above revisions in draft 09: 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.



RFC6909 is clarified further in the Introduction Section in version 09.
   (1)  Mobile users are, more than ever, consuming Internet content;
        such traffic imposes new requirements on mobile core networks
        for data traffic delivery.  The presence of content providers
        closer to Internet Service Providers (ISP) network requires
        taking into account local Content Delivery Networks (CDNs) while
        providing mobility services.  Moreover, when the traffic demand
        exceeds available capacity, service providers need to implement
        new strategies such as selective IPv4 traffic offload (e.g.
        [RFC6909], 3GPP work items LIPA/SIPTO [TS.23.401]) through
        alternative access networks (e.g.  WLAN) [Paper-

        Mobile.Data.Offloading].



RFC6705 is clarified under PS1 in version 09
   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 nearby server or
         servers of a Content Delivery Network (CDN), or when receiving
         locally available IP multicast or sending IP multicast packets.
         (Existing route optimization is only a host-based solution.  On
         the other hand, localized routing with PMIPv6 [RFC6705]
         addresses only a part of the problem where both the MN and the
         CN are located in the PMIP domain and attached to a MAG, and is
         not applicable when the CN is outside the PMIP domain or does
         not behave like an MN.)







   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/>



These references have been added in the Introduction Section in version 09


   (2)  Today's mobile networks present service providers with new
        challenges.  Mobility patterns indicate that mobile nodes often
        remain attached to the same point of attachment for considerable
        periods of time [Paper-Locating.User].  Specific IP mobility
        management support is not required for applications that launch
        and complete their sessions while the mobile node is connected
        to the same point of attachment.  However, currently, IP
        mobility support is designed for always-on operation,
        maintaining all parameters of the context for each mobile
        subscriber for as long as they are connected to the network.
        This can result in a waste of resources and unnecessary costs
        for the service provider.  Infrequent node mobility coupled with
        application intelligence suggest that mobility support could be
        provided selectively such as in [I-D.bhandari-dhc-class-based-
        prefix] and [I-D.korhonen-6man-prefix-properties], thus reducing
        the amount of context maintained in the network.