Re: [DMM] comments on draft-ietf-dmm-best-practices-gap-analysis-01
Liu Dapeng <maxpassion@gmail.com> Wed, 07 August 2013 03:37 UTC
Return-Path: <maxpassion@gmail.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 002E821E80B5 for <dmm@ietfa.amsl.com>; Tue, 6 Aug 2013 20:37:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.766
X-Spam-Level:
X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]
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 TfimHx5WJNfI for <dmm@ietfa.amsl.com>; Tue, 6 Aug 2013 20:37:54 -0700 (PDT)
Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB3211E80EA for <dmm@ietf.org>; Tue, 6 Aug 2013 20:37:54 -0700 (PDT)
Received: by mail-ve0-f170.google.com with SMTP id 15so1245527vea.1 for <dmm@ietf.org>; Tue, 06 Aug 2013 20:37:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o1HZOwCMlXUfGSgxE8itukrsWZqKU9j+2v8h1VKNOxE=; b=Vq4TDlKPL7qPRj8s9BXzuNcds3e4HSkkBTQ/K2sGV+R051pdqBtuU/xikL8rEx26OI KqnpBkBnmdBDOdLzumly2WbH2BWJG7gf+YTQdHxGvvkBjcO0JqdeTqlPhvsc0PDnBbd/ AJ1H2NECC1scU00sv4qSClRL+M/zr39bL081eNm7IJbosNUXPZy8SH7zyHW9Nvjcx6GV sZD+Wir7ZEakgC9Wdc/gnPerEPVKJYHpJwveucPbK2uxixDJXile2c25VaTkiyD/rLBU CVAzTQzJUgv2ql2SOS4L4zPMVXQ5hJPJwUb3QO//jqpJ5jjSi2dvndugh8l5nGKMlNSn RlnQ==
MIME-Version: 1.0
X-Received: by 10.58.24.201 with SMTP id w9mr363474vef.82.1375846671079; Tue, 06 Aug 2013 20:37:51 -0700 (PDT)
Received: by 10.220.142.130 with HTTP; Tue, 6 Aug 2013 20:37:51 -0700 (PDT)
In-Reply-To: <51FA13C9.2050806@gmail.com>
References: <72EF3457-5B8A-4F5C-8BEA-2EDC5DBF850E@gmail.com> <51FA13C9.2050806@gmail.com>
Date: Wed, 07 Aug 2013 11:37:51 +0800
Message-ID: <CAKcc6Adb+LFEtQr6aXJCTz3pEjewo_JTu7SeKpGuTdhc=fQ2pA@mail.gmail.com>
From: Liu Dapeng <maxpassion@gmail.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Content-Type: multipart/alternative; boundary="047d7b2e75ec185ece04e35344fe"
Cc: dmm <dmm@ietf.org>
Subject: Re: [DMM] comments on draft-ietf-dmm-best-practices-gap-analysis-01
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: Wed, 07 Aug 2013 03:37:59 -0000
Hi Alex, 2013/8/1 Alexandru Petrescu <alexandru.petrescu@gmail.com> > Hello DMMers, > > I follow on the Chair invitation to suggest gaps to the gap analysis > document. I must though say I have been following this discussion only > remotely so I am not up to date. > > 1. The Route Optimization feature of Mobile IPv6 does not support > mobile network prefixes - it only works for a full /128 Home > Address. There is a security problem in extending the RR tests for > prefixes. But if done, it will allow direct communications from an > LFN in the moving network to an arbitrary Correspondent Node in the > Internet. > > [Dapeng] Mobile IPv6 Route Optimization is analysed in section 4.2.1. Do you propose any changes of current text? > 2. Anchoring a Mobile Node's Home Address at multiple points may be a > very good goal, but one wonders whether it could be achieved within > useful limits. An IP address is typically valid at a single point > in the Internet. Anchoring it at more places involves the use of > route updates or of tunnelling. It is a question whether this could > be achieved within measurable and advantageous limits, compared to > changing the IP address, or prefer still anchor at remote HA. > [Dapeng] Some current proposal in DMM WG use multiple home addresses for multiple anchors. > > 3. Simultaneous use of multiple interfaces at a same mobile router is > something that is not supported by Mobile IPv6 today (although it > does support multiple Care-of Addresses). If done, it allows > bandwidth augmentation (i.e. add 10 cellular interfaces to a Mobile > Router deployed in a bus, and thus multiply the bandwidth by ten) > for all kinds of applications. > > [Dapeng] I am not sure whether mobile router case should be in the scope of DMM? > These are some thoughts about gaps. If necessary I can try to provide > text, provided I understand the current context. > [Dapeng] Yes, text will be appreciated. Dapeng > Alex > > Le 24/07/2013 14:54, Jouni Korhonen a écrit : > > Authors, >> >> I finally read the draft and below are some comments to hopefully >> help completing and improving the draft. >> >> In Section 4.2. it is stated: >> >> "view using common and standardized protocols. Since WiFi is the >> most widely deployed wireless access technology nowadays, we take it >> as" >> >> Do you have some data/reference to backup your claim? >> >> In Section 4.2.1. it is stated: >> >> "at different point of attachment. However there is no mechanism >> specified to enable an efficient dynamic discovery of available" >> >> I would add a clarification here that there is no such mechanism >> available within IETF specifications. Other SDOs do have such >> mechanism (e.g. 3GPP). >> >> Furthermore, around the bulleted list for the MIPv6 RO discussion, I >> would mention that nothing prevents a MN to use its CoA directly >> when communicating CNs on the same link or anywhere in the internet. >> Of course there is no mobility in that case but it is a valid >> scenario to mention IMHO (and also part of our charter). I recon the >> HMIPv6 text mentions at least the use of RCoA already. >> >> In Section 4.2.2. where the text describes RFC6463, I would also >> reference to RFC6097 since that has quite a bit of text regarding the >> discovery procedure of the LMA. >> >> While I found Section 4.2. good in general I was somehow expecting to >> see text regarding MOBIKE (RFC4555). We can safely assume MOBIKE is >> probably the most deployed client mobility enabling technology out >> there today. >> >> In Section 4.3. it says: >> >> "GPRS Tunnelling Protocol (GTP) [3GPP.29.060] is a network-based >> mobility protocol specified for 3GPP networks (S2a, S2b, S5 and S8 >> interfaces)." >> >> While 29.060 is about GTP, for the above referenced interfaces >> 29.281 and 29.274 are probably more appropriate. >> >> "A Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO) >> enabled network [3GPP.23.829] allows offloading some IP services at" >> >> I would say referencing to e.g. 23.401 on LIPA/SIPTO is more >> appropriate these days, since the TR23.829 is somewhat left behind >> and the LIPA/SIPTO functionality is part of the main stage-2 specs >> already. >> >> I found Section 4 in general quite nice. However, I was somehow >> expecting to see a bit of text of WiMAX. Or can we safely state that >> no IPv6 deployments ever took place in WiMAX? Anyway, at least a >> reference to WiMAX would be nice, since they spent quite a bit of >> time developing both CMIPv6 and PMIPv6 functionality into their >> architecture. >> >> In Section 4.3. I would reference to 3GPP TS29.303 and say something >> about 3GPP's heavy use of DNS as the "gateway location database" and >> how that is used to discover gateways with both topological and >> gateway collocation in mind >> >> In Section 5. it is stated: >> >> "o The dynamic anchor relocation needs to ensure that IP address >> continuity is guaranteed for sessions that need it at the relocated >> anchor. This for example implies having the knowledge" >> >> Since our charter _allows_ solutions where mobility is used "when >> needed" that fact should be reflected above. Even if there is >> mobility supported only locally within a limited area, it might meet >> the requirements from the MN or the application point of view i.e. >> when the MN or the application does not care about a "full >> longstanding mobility" to be provided. >> >> "o Dynamic discovery and selection of anchors. There might be more >> than one available anchor for a mobile node to use. Currently, there >> is no efficient mechanism that allows to dynamically discover the >> presence of nodes that can play the role of anchor, discover their >> capabilities and allow the selection of the most suitable one." >> >> Within 3GPP TS29.303 makes that possible and is deployed. >> >> In general the draft is heading to a good direction IMHO! Just >> complete it fast ;-) >> >> - Jouni >> >> ______________________________**_________________ dmm mailing list >> dmm@ietf.org https://www.ietf.org/mailman/**listinfo/dmm<https://www.ietf.org/mailman/listinfo/dmm> >> >> >> > > ______________________________**_________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/**listinfo/dmm<https://www.ietf.org/mailman/listinfo/dmm> > -- ------ Best Regards, Dapeng Liu
- [DMM] comments on draft-ietf-dmm-best-practices-g… Jouni Korhonen
- [DMM] comment on draft-ietf-dmm-best-practices-ga… karagian
- Re: [DMM] comments on draft-ietf-dmm-best-practic… Liu Dapeng
- Re: [DMM] comments on draft-ietf-dmm-best-practic… Alexandru Petrescu
- Re: [DMM] comment on draft-ietf-dmm-best-practice… Liu Dapeng
- Re: [DMM] comments on draft-ietf-dmm-best-practic… Liu Dapeng
- Re: [DMM] comments on draft-ietf-dmm-best-practic… pierrick.seite
- Re: [DMM] comments on draft-ietf-dmm-best-practic… Alexandru Petrescu