Re: [DMM] comments on draft-ietf-dmm-best-practices-gap-analysis-01
Liu Dapeng <maxpassion@gmail.com> Tue, 30 July 2013 08:46 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 52D2721E80BF for <dmm@ietfa.amsl.com>; Tue, 30 Jul 2013 01:46:11 -0700 (PDT)
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=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 szc87wvDp7fw for <dmm@ietfa.amsl.com>; Tue, 30 Jul 2013 01:46:09 -0700 (PDT)
Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE6E21F9C40 for <dmm@ietf.org>; Tue, 30 Jul 2013 01:45:20 -0700 (PDT)
Received: by mail-vb0-f49.google.com with SMTP id w15so3501148vbb.8 for <dmm@ietf.org>; Tue, 30 Jul 2013 01:45:19 -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=BwQooBinr6Ws6ikTU6XSzCF0+fg27VKEkqLISTqe5qk=; b=RBO4irZO58BOB9L8pGVJtaDwvSuSbo4Er0qNF7DgpHOpncpu4BR6tQsjX5dWSgXeh3 b1omidmfCXUCIdWuaDymZIX0g1RDLxQJv3r8t15+TQrgCIPHyqpBzdqbzeoPJAoh1v1M jbnSHAUwvDRdkLp7o086dkiI62U+rFKIikcSXiLN9dyKUZ227aw8K5gOmz1Zb8ZmcfNC IlnnZVuibVshSef3n0TuBSVSwJ8aDBhakYZqCnQhEYPKo20aI2L6zN7GrTLAX4wbRUyC A4/x0nyckoMcCVAXIEfrNnndfc37eXUAZFeZt4K3Iu6UWRG4mhudVTt0gFO7Wzk8c7f4 SE6g==
MIME-Version: 1.0
X-Received: by 10.58.236.70 with SMTP id us6mr26985062vec.89.1375173919632; Tue, 30 Jul 2013 01:45:19 -0700 (PDT)
Received: by 10.220.142.130 with HTTP; Tue, 30 Jul 2013 01:45:19 -0700 (PDT)
In-Reply-To: <72EF3457-5B8A-4F5C-8BEA-2EDC5DBF850E@gmail.com>
References: <72EF3457-5B8A-4F5C-8BEA-2EDC5DBF850E@gmail.com>
Date: Tue, 30 Jul 2013 16:45:19 +0800
Message-ID: <CAKcc6AesKy-=hzP1=iesEJy=Lx7423mcpc-=4OAx1=DsCWk+_w@mail.gmail.com>
From: Liu Dapeng <maxpassion@gmail.com>
To: Jouni Korhonen <jouni.nospam@gmail.com>
Content-Type: multipart/alternative; boundary="047d7bd6a906fc118c04e2b6a033"
Cc: Dapeng Liu <liudapeng@chinamobile.com>, "dmm@ietf.org" <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: Tue, 30 Jul 2013 08:46:11 -0000
Hi Jouni, Thanks for the comments. 2013/7/24 Jouni Korhonen <jouni.nospam@gmail.com> > 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? > [Dapeng] Maybe we can change the wording a little bit. e.g. remove 'most'. > 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). > [Dapeng] OK. > 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. > > [Dapeng] Agree. > 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. > [Dapeng] OK. > 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. > [Dapeng] We can add MOBIKE there. > 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. > [Dapeng] We will add those reference. "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. > [Dapeng] We will update this reference. > > 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. > [Dapeng] OK. > 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 > [Dapeng] OK. > 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. > [Dapeng] We can change the wording here. > "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. > > [Dapeng] We can scope the statement in IETF? > In general the draft is heading to a good direction IMHO! Just complete > it fast ;-) > [Dapeng] Thanks for the valuable comments. We will update the draft according to the comments soon. Dapeng - Jouni > > _______________________________________________ > dmm mailing list > dmm@ietf.org > 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