[DMM] Comments on draft-patil-dmm-issues-and-approaches2dmm-00
Peter McCann <Peter.McCann@huawei.com> Tue, 06 March 2012 21:49 UTC
Return-Path: <Peter.McCann@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 698FE21E8013 for <dmm@ietfa.amsl.com>; Tue, 6 Mar 2012 13:49:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 GOVVYJv3GBVH for <dmm@ietfa.amsl.com>; Tue, 6 Mar 2012 13:49:09 -0800 (PST)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id BA67E21F8464 for <dmm@ietf.org>; Tue, 6 Mar 2012 13:49:09 -0800 (PST)
Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AED86942; Tue, 06 Mar 2012 16:49:09 -0500 (EST)
Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 6 Mar 2012 13:48:22 -0800
Received: from DFWEML504-MBX.china.huawei.com ([10.124.31.30]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Tue, 6 Mar 2012 13:48:17 -0800
From: Peter McCann <Peter.McCann@huawei.com>
To: "basavaraj.patil@nokia.com" <basavaraj.patil@nokia.com>, "carlw@mcsr-labs.org" <carlw@mcsr-labs.org>, "jouni.nospam@gmail.com" <jouni.nospam@gmail.com>
Thread-Topic: Comments on draft-patil-dmm-issues-and-approaches2dmm-00
Thread-Index: Acz74tbaKHHVfQwFSOaADK0zCMsIqw==
Date: Tue, 06 Mar 2012 21:48:17 +0000
Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716447E36@dfweml504-mbx>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.193.125.95]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dmm@ietf.org" <dmm@ietf.org>
Subject: [DMM] Comments on draft-patil-dmm-issues-and-approaches2dmm-00
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: Tue, 06 Mar 2012 21:49:10 -0000
Hi, Raj, Carl, and Jouni, I have some comments on draft-patil-dmm-issues-and-approaches2dmm-00. I agree with most of Section 4, "Issues with current mobility models". However, I'd like to point out that existing networks are not just centralized in the manner you point out, they also tend to have a hierarchical structure, e.g., the S-GW/P-GW split in 3GPP EPC. Therefore, the issue you outline in Section 4.3 ("Inefficient Routing and signaling overhead") is not quite true of the 3GPP EPC, which can handle many mobility events in a localized manner similar to HMIP. The first paragraph of Section 7 talks about source address selection, and the need to modify applications so that they request the kind of address that they want. I tend to think that applications will remain unmodified for some time to come; however, most applications fit into the paradigm of opening short-lived connections to a server and could be accommodated with some sort of automatic handling in the MN's IP stack. I found the last paragraph of Section 7 quite interesting. I too think that there is an important piece missing that you call "seamless mobility anchor relocation". I think that the use of an interior routing protocol is spot on. In fact, if you read draft-mccann-dmm-flatarch-00, I propose just that. I think we can use such an anchor relocation protocol to make each access router in an autonomous system (or smaller region of an autonomous system) a temporary anchor for a given prefix. In my draft I propose running I-BGP on each AR and sending BGP UPDATES into the network upon localized mobility events. Such a protocol can also be used as a substitute for the proxy ND technique that is currently specified to "grab" the MN's packets at the HA. By using a routing protocol, the HA can reach across several routing hops so it doesn't necessarily need to be on the home link (which can be the first AR to which the MN attached). I think this would also enable us to unify the authentication protocols used at the AR with the authentication protocol used at the HA. The ARs are just like HAs that don't have to tunnel the data anywhere because the MN is locally connected. Does it make sense to you? -- Peter J. McCann Huawei Technologies (USA) Peter.McCann@Huawei.com +1 908 541 3563 Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ 08807-2863 USA
- Re: [DMM] Comments on draft-patil-dmm-issues-and-… Basavaraj.Patil
- [DMM] Comments on draft-patil-dmm-issues-and-appr… Peter McCann
- Re: [DMM] Comments on draft-patil-dmm-issues-and-… jouni korhonen
- Re: [DMM] Comments on draft-patil-dmm-issues-and-… Peter McCann
- Re: [DMM] Comments on draft-patil-dmm-issues-and-… jouni korhonen
- Re: [DMM] Comments on draft-patil-dmm-issues-and-… Peter McCann