Re: [DMM] comments on draft-ietf-dmm-best-practices-gap-analysis-01
Alexandru Petrescu <alexandru.petrescu@gmail.com> Wed, 21 August 2013 09:44 UTC
Return-Path: <alexandru.petrescu@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 F2EEB11E81BA for <dmm@ietfa.amsl.com>; Wed, 21 Aug 2013 02:44:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.099
X-Spam-Level:
X-Spam-Status: No, score=-11.099 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
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 VNf33QMYohMJ for <dmm@ietfa.amsl.com>; Wed, 21 Aug 2013 02:44:12 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 2209911E80ED for <dmm@ietf.org>; Wed, 21 Aug 2013 02:44:11 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r7L9iAUl030353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Aug 2013 11:44:10 +0200
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r7L9i9pn017733; Wed, 21 Aug 2013 11:44:09 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r7L9hoJN009042; Wed, 21 Aug 2013 11:44:09 +0200
Message-ID: <52148BD6.6080703@gmail.com>
Date: Wed, 21 Aug 2013 11:43:50 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Liu Dapeng <maxpassion@gmail.com>
References: <72EF3457-5B8A-4F5C-8BEA-2EDC5DBF850E@gmail.com> <51FA13C9.2050806@gmail.com> <CAKcc6Adb+LFEtQr6aXJCTz3pEjewo_JTu7SeKpGuTdhc=fQ2pA@mail.gmail.com>
In-Reply-To: <CAKcc6Adb+LFEtQr6aXJCTz3pEjewo_JTu7SeKpGuTdhc=fQ2pA@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
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, 21 Aug 2013 09:44:18 -0000
Le 07/08/2013 05:37, Liu Dapeng a écrit : > Hi Alex, > > > 2013/8/1 Alexandru Petrescu <alexandru.petrescu@gmail.com > <mailto: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? It currently says: > o The RO mode is only supported by Mobile IPv6. There is no route > optimization support standardized for the NEMO protocol, although > many different solutions have been proposed. It should say: > o The RO mode is only supported by Mobile IPv6 for Mobile Hosts. > There is no agreement for route optimization support for a Mobile > Router running the NEMO extensions. The difficulty lies, among other > things, in extending the Return Routability tests of RO from a single > address (the Home Address) to an entire set of addresses (the mobile > network prefix). Although no common RO solution for Mobile Router is > agreed, many different solutions have been proposed; the Network > Mobility Route Optiomization Solution Space Analysis is in RFC4889. > 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. Yes, and all have advantages and inconvenients (no session continuity). > 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? I do not know either. The charter is explicit about the use of NEMO, but not sure whether current DMM works consider this Mobile Router paradigm from start or for later. Alex > > 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 <mailto:dmm@ietf.org> > https://www.ietf.org/mailman/__listinfo/dmm > <https://www.ietf.org/mailman/listinfo/dmm> > > > > > _________________________________________________ dmm mailing list > dmm@ietf.org <mailto: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