Re: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt
h chan <h.anthony.chan@huawei.com> Sat, 28 September 2013 15:28 UTC
Return-Path: <h.anthony.chan@huawei.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D14321E8051 for <dmm@ietfa.amsl.com>; Sat, 28 Sep 2013 08:28:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.546
X-Spam-Level:
X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-sTRF6EnDcp for <dmm@ietfa.amsl.com>; Sat, 28 Sep 2013 08:28:40 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 682D821E8090 for <dmm@ietf.org>; Sat, 28 Sep 2013 08:28:37 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYJ39022; Sat, 28 Sep 2013 15:28:36 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 28 Sep 2013 16:28:35 +0100
Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 28 Sep 2013 16:28:34 +0100
Received: from szxeml557-mbx.china.huawei.com ([169.254.5.217]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.03.0146.000; Sat, 28 Sep 2013 23:28:31 +0800
From: h chan <h.anthony.chan@huawei.com>
To: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>, "dmm@ietf.org" <dmm@ietf.org>
Thread-Topic: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt
Thread-Index: AQHOogjoa3/L9muNGkS5wozrKtEQEpnXRZkQgABo14CAAJoKEIADLS4wgAAEQpA=
Date: Sat, 28 Sep 2013 15:28:29 +0000
Message-ID: <6E31144C030982429702B11D6746B98C370CBF5F@szxeml557-mbx.china.huawei.com>
References: <1377486056.79906.YahooMailNeo@web163805.mail.gq1.yahoo.com> <24C0F3E22276D9438D6F366EB89FAEA8116A4D4F@xmb-aln-x03.cisco.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.46.64.17]
Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C370CBF5Fszxeml557mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 28 Sep 2013 15:28:44 -0000
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)'; 'dmm@ietf.org' 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: dmm-bounces@ietf.org<mailto:dmm-bounces@ietf.org> [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: Sunday, August 25, 2013 10:04 PM To: dmm@ietf.org<mailto:dmm@ietf.org> 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.
- [DMM] I-D Action: draft-ietf-dmm-requirements-07.… internet-drafts
- Re: [DMM] I-D Action: draft-ietf-dmm-requirements… Sri Gundavelli (sgundave)
- Re: [DMM] I-D Action: draft-ietf-dmm-requirements… Jouni Korhonen
- Re: [DMM] I-D Action: draft-ietf-dmm-requirements… h chan
- Re: [DMM] I-D Action: draft-ietf-dmm-requirements… h chan
- Re: [DMM] I-D Action: draft-ietf-dmm-requirements… h chan
- Re: [DMM] I-D Action: draft-ietf-dmm-requirements… h chan
- Re: [DMM] I-D Action: draft-ietf-dmm-requirements… h chan
- Re: [DMM] I-D Action: draft-ietf-dmm-requirements… h chan
- Re: [DMM] I-D Action: draft-ietf-dmm-requirements… h chan
- Re: [DMM] I-D Action: draft-ietf-dmm-requirements… h chan
- Re: [DMM] I-D Action: draft-ietf-dmm-requirements… h chan
- [DMM] draft-ietf-dmm-requirements-10.txt h chan
- Re: [DMM] I-D Action: draft-ietf-dmm-requirements… Sri Gundavelli (sgundave)
- Re: [DMM] I-D Action: draft-ietf-dmm-requirements… h chan
- Re: [DMM] I-D Action: draft-ietf-dmm-requirements… h chan
- Re: [DMM] I-D Action: draft-ietf-dmm-requirements… Sri Gundavelli (sgundave)