From alexandru.petrescu@gmail.com Thu Aug 1 00:52:58 2013 Return-Path: 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 27EAC21F9E24 for ; Thu, 1 Aug 2013 00:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.151 X-Spam-Level: X-Spam-Status: No, score=-11.151 tagged_above=-999 required=5 tests=[AWL=1.098, 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 DyNHU36bUhZq for ; Thu, 1 Aug 2013 00:52:51 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 5359A21F8A50 for ; Thu, 1 Aug 2013 00:52:51 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r717qlqs028972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 1 Aug 2013 09:52:47 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id r717qlO3017659 for ; Thu, 1 Aug 2013 09:52:47 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.2]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r717qgSj006870 for ; Thu, 1 Aug 2013 09:52:47 +0200 Message-ID: <51FA13C9.2050806@gmail.com> Date: Thu, 01 Aug 2013 09:52:41 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: dmm@ietf.org References: <72EF3457-5B8A-4F5C-8BEA-2EDC5DBF850E@gmail.com> In-Reply-To: <72EF3457-5B8A-4F5C-8BEA-2EDC5DBF850E@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 07:52:58 -0000 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. 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. 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. These are some thoughts about gaps. If necessary I can try to provide text, provided I understand the current context. 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 > > From karagian@cs.utwente.nl Thu Aug 1 00:58:51 2013 Return-Path: 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 95E6821F9E3F for ; Thu, 1 Aug 2013 00:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=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 U9BHzunW7HdZ for ; Thu, 1 Aug 2013 00:58:45 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 532DE21F9AD8 for ; Thu, 1 Aug 2013 00:58:41 -0700 (PDT) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 1 Aug 2013 09:58:36 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.13]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.02.0328.009; Thu, 1 Aug 2013 09:58:35 +0200 From: To: , , , , , Thread-Topic: comment on draft-ietf-dmm-best-practices-gap-analysis-01 Thread-Index: Ac6OjPOCygmof+3LTQKqYd7U/tPqbQ== Date: Thu, 1 Aug 2013 07:58:34 +0000 Message-ID: References: <72EF3457-5B8A-4F5C-8BEA-2EDC5DBF850E@gmail.com> In-Reply-To: <72EF3457-5B8A-4F5C-8BEA-2EDC5DBF850E@gmail.com> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mimectl: Produced By Microsoft Exchange V14.2.247.1 x-originating-ip: [130.129.20.24] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F3BB072EXMBX23adutwent_" MIME-Version: 1.0 Subject: [DMM] comment 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 07:58:51 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F3BB072EXMBX23adutwent_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, In this email I am repeting the comment that I had today on the mike: The current version of the draft is not using the requirements defined in t= he requirements draft to identify the gaps on existing mobility protocols. In my opinion it is important to use these requirements in order to identif= y the gaps. Best regards, Georgios --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F3BB072EXMBX23adutwent_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi,

 

In this email I am repe= ting the comment that I had today on the mike:

 

The current version of = the draft is not using the requirements defined in the requirements draft t= o identify the gaps on existing mobility protocols.

In my opinion it is imp= ortant to use these requirements in order to identify the gaps.

 

Best regards,

Georgios

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F3BB072EXMBX23adutwent_-- From alexandru.petrescu@gmail.com Thu Aug 1 01:47:17 2013 Return-Path: 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 CB88521F9CE7 for ; Thu, 1 Aug 2013 01:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.185 X-Spam-Level: X-Spam-Status: No, score=-10.185 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, 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 D+s8uzrCKX1n for ; Thu, 1 Aug 2013 01:47:11 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 701CE21F9DA0 for ; Thu, 1 Aug 2013 01:47:00 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id r718kogb015642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 1 Aug 2013 10:46:50 +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 r718koQP012707 for ; Thu, 1 Aug 2013 10:46:50 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.2]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r718kjNU026667 for ; Thu, 1 Aug 2013 10:46:50 +0200 Message-ID: <51FA2075.1070505@gmail.com> Date: Thu, 01 Aug 2013 10:46:45 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "dmm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [DMM] Comments on Correspondent Home Networking/Correspondent Routers X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 08:47:17 -0000 Comments on Correspondent Home Networking/CRs: When the CR (Correspondent Router) was presented some time ago I had some comments, that I re-iterate now. There is already a problem in deploying MIP6 CN RO functionality in the numerous IPv6 content servers in the Internet. It would be probably even more difficult to deploy CRs (or HA-close-to-each-CN) only to support mobility. (although now the status of MIP6 in the linux kernel is no longer EXPERIMENTAL, which is very good). The solution, as presented now, seems to rely extensively on the use of DNS - it returns the IP address of the CHA and the HoA. This is similar to what NAT64 does, and has its drawbacks as well: ping6 1::1 won't work. Finally, once a HoA specific to a CN is obtained at MN, then one must make sure that that HoA is not used by MN when browsing some other CN; i.e. a need to modify an application to use a particular IP address as src/dst for a particular application. Alex From ryuji.wakikawa@gmail.com Thu Aug 1 02:06:05 2013 Return-Path: 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 64AD921F9A81 for ; Thu, 1 Aug 2013 02:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 o92D8Dq++NTy for ; Thu, 1 Aug 2013 02:06:04 -0700 (PDT) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 3D90721F9D1B for ; Thu, 1 Aug 2013 02:06:01 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id mc17so568125pbc.32 for ; Thu, 01 Aug 2013 02:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=ERZFRz7bA9FPqdd7eJSUcQdKDwJUBcvArzIprVFZ/tQ=; b=MGWr20njel3m1j2xPzvUqYOLHMf57r7Xmqqft8Jlb4VpnSLoHY3dnK4o7xyPyz6+vz +vhhrPCMvBsUPbDdhFGfdV+FW8xlzI46ylFqV1TDR4vPiQrYJFVVjY+mUX3a4k3pEiyW LxsPjNRdr1P4J1sKaJB/2q7RxALoX9YEE4O7aNEpRu7UMYfqE0ap91xbGRbB8dsKeuOP hc3UYoEJLzrDV8FfLGBdbXHUZD8YUyk98MaHwFodqEHXp3e8y0HnivDb6oi9l+pHWpe+ QlQZcuhME3VKj18eKgW03IGmdJKjBJQcA+GBYkNozBOj+gUN2B4RK7FjSzclgc2whvaS rVdQ== X-Received: by 10.66.27.143 with SMTP id t15mr2665644pag.171.1375347959756; Thu, 01 Aug 2013 02:05:59 -0700 (PDT) Received: from dhcp-571d.meeting.ietf.org (dhcp-571d.meeting.ietf.org. [130.129.87.29]) by mx.google.com with ESMTPSA id qv4sm2840215pbc.16.2013.08.01.02.05.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 Aug 2013 02:05:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ryuji Wakikawa In-Reply-To: <51FA2075.1070505@gmail.com> Date: Thu, 1 Aug 2013 11:05:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51FA2075.1070505@gmail.com> To: dmm@ietf.org X-Mailer: Apple Mail (2.1508) Subject: Re: [DMM] Comments on Correspondent Home Networking/Correspondent Routers X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 09:06:05 -0000 Alper and Alex Here are some CR documents http://tools.ietf.org/html/draft-wakikawa-mext-cr-consideration http://tools.ietf.org/html/draft-wakikawa-nemo-orc-01 It's nice to see similar idea now;-) Thanks Alper for the work! BTMM (DNS-based mobility) can be found here. http://www.rfc-editor.org/rfc/rfc6281.txt regards, ryuj On Aug 1, 2013, at 10:46 AM, Alexandru Petrescu = wrote: > Comments on Correspondent Home Networking/CRs: >=20 > When the CR (Correspondent Router) was presented some time ago I had > some comments, that I re-iterate now. >=20 > There is already a problem in deploying MIP6 CN RO functionality in = the > numerous IPv6 content servers in the Internet. It would be probably > even more difficult to deploy CRs (or HA-close-to-each-CN) only to > support mobility. >=20 > (although now the status of MIP6 in the linux kernel is no longer > EXPERIMENTAL, which is very good). >=20 > The solution, as presented now, seems to rely extensively on the use = of > DNS - it returns the IP address of the CHA and the HoA. This is = similar > to what NAT64 does, and has its drawbacks as well: ping6 1::1 won't = work. >=20 > Finally, once a HoA specific to a CN is obtained at MN, then one must > make sure that that HoA is not used by MN when browsing some other CN; > i.e. a need to modify an application to use a particular IP address as > src/dst for a particular application. >=20 > Alex >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From cjbc@it.uc3m.es Thu Aug 1 02:16:05 2013 Return-Path: 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 F170821F9D28 for ; Thu, 1 Aug 2013 02:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 uRbGiJQuJhQO for ; Thu, 1 Aug 2013 02:16:00 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 3F94F21E80A9 for ; Thu, 1 Aug 2013 02:15:59 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5915911BFAC2 for ; Thu, 1 Aug 2013 11:15:53 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [130.129.85.5] (dhcp-5505.meeting.ietf.org [130.129.85.5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id CDAB511BF902 for ; Thu, 1 Aug 2013 11:15:52 +0200 (CEST) Message-ID: <1375348550.4376.2.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: 'dmm' Date: Thu, 01 Aug 2013 11:15:50 +0200 Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20050.006 X-TM-AS-Result: No--4.582-7.0-31-1 X-imss-scan-details: No--4.582-7.0-31-1 Subject: [DMM] Slides on client and network based DMM solution presented in IETF87 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 09:16:05 -0000 Hi, It seems that there were some issues with the PDF used during the presentation (automatically created by the meeting materials tools). For those interested, the slides (pptx format) can be found on: http://www.ietf.org/proceedings/87/slides/slides-87-dmm-7.pptx Thanks From cjbc@it.uc3m.es Thu Aug 1 02:23:08 2013 Return-Path: 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 AB85221F9C10 for ; Thu, 1 Aug 2013 02:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 D78J2jEfLG5l for ; Thu, 1 Aug 2013 02:23:04 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 063A021F9CC8 for ; Thu, 1 Aug 2013 02:22:19 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 3A68DCD573E; Thu, 1 Aug 2013 11:22:17 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [130.129.85.5] (dhcp-5505.meeting.ietf.org [130.129.85.5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id AD0A4CC6130; Thu, 1 Aug 2013 11:22:16 +0200 (CEST) Message-ID: <1375348935.4376.6.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Ryuji Wakikawa Date: Thu, 01 Aug 2013 11:22:15 +0200 In-Reply-To: References: <51FA2075.1070505@gmail.com> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20050.006 Cc: dmm@ietf.org Subject: Re: [DMM] Comments on Correspondent Home Networking/Correspondent Routers X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 09:23:08 -0000 Hi, On Thu, 2013-08-01 at 11:05 +0200, Ryuji Wakikawa wrote: > Alper and Alex > > Here are some CR documents > http://tools.ietf.org/html/draft-wakikawa-mext-cr-consideration > http://tools.ietf.org/html/draft-wakikawa-nemo-orc-01 > It's nice to see similar idea now;-) Thanks Alper for the work! One more, that Ryuji forgot to mention :p http://tools.ietf.org/html/draft-bernardos-mext-nemo-ro-cr-00 Carlos > > BTMM (DNS-based mobility) can be found here. > http://www.rfc-editor.org/rfc/rfc6281.txt > > regards, > ryuj > > > On Aug 1, 2013, at 10:46 AM, Alexandru Petrescu wrote: > > > Comments on Correspondent Home Networking/CRs: > > > > When the CR (Correspondent Router) was presented some time ago I had > > some comments, that I re-iterate now. > > > > There is already a problem in deploying MIP6 CN RO functionality in the > > numerous IPv6 content servers in the Internet. It would be probably > > even more difficult to deploy CRs (or HA-close-to-each-CN) only to > > support mobility. > > > > (although now the status of MIP6 in the linux kernel is no longer > > EXPERIMENTAL, which is very good). > > > > The solution, as presented now, seems to rely extensively on the use of > > DNS - it returns the IP address of the CHA and the HoA. This is similar > > to what NAT64 does, and has its drawbacks as well: ping6 1::1 won't work. > > > > Finally, once a HoA specific to a CN is obtained at MN, then one must > > make sure that that HoA is not used by MN when browsing some other CN; > > i.e. a need to modify an application to use a particular IP address as > > src/dst for a particular application. > > > > Alex > > > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From ryuji.wakikawa@gmail.com Thu Aug 1 02:24:45 2013 Return-Path: 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 681D821F9A06 for ; Thu, 1 Aug 2013 02:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 hnr3xdP7IABL for ; Thu, 1 Aug 2013 02:24:44 -0700 (PDT) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 69A5521F9AD1 for ; Thu, 1 Aug 2013 02:24:41 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id xb4so1866582pbc.22 for ; Thu, 01 Aug 2013 02:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Af0JWlbKuR++tFPQ5H59w5rjmcIZ9Jddno0+ZdGs19A=; b=UxPZqVFheNeoQdjcQy27HrBuQr0Rzd5r8ErghLZcWgix/KQCMCfFXb7O0zYPjnGclr CPS9LIIbUl+lZUIw1ynWxo5fXbxXNEJhfY/gfjo9eJXDiGbKpiFLK5OeCgxow4+LvMnj RuRIjHyhm+CgW0zysO5VfRHf7gZkZTDbbjACj60IGKuIZXQbKU9ed7ZLqR4i5QgDyZPZ tMmAkf09FmH3+XFDfXaUTw84lpJMHhPjV6d22Ffj/5TjLsMOjB1JsD9Qa47A8aBLz1cw jUu84KW8vr21Oej/j4SgXpWqwzpX710mE9dd4Cg+pYeav93Qtuy2AgbqfP54b5zgUtVc hffQ== X-Received: by 10.66.164.199 with SMTP id ys7mr2869116pab.104.1375349080851; Thu, 01 Aug 2013 02:24:40 -0700 (PDT) Received: from dhcp-571d.meeting.ietf.org (dhcp-571d.meeting.ietf.org. [130.129.87.29]) by mx.google.com with ESMTPSA id s5sm1388242pbo.38.2013.08.01.02.24.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 Aug 2013 02:24:40 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ryuji Wakikawa In-Reply-To: <1375348935.4376.6.camel@acorde.it.uc3m.es> Date: Thu, 1 Aug 2013 11:24:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0B1AE90B-B9DF-42B8-B490-CB06F9CACD67@gmail.com> References: <51FA2075.1070505@gmail.com> <1375348935.4376.6.camel@acorde.it.uc3m.es> To: cjbc@it.uc3m.es X-Mailer: Apple Mail (2.1508) Cc: dmm@ietf.org Subject: Re: [DMM] Comments on Correspondent Home Networking/Correspondent Routers X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 09:24:45 -0000 Thanks Carlos. My memory is limited these days.. ryuji On Aug 1, 2013, at 11:22 AM, Carlos Jes=FAs Bernardos Cano = wrote: > Hi, >=20 >=20 > On Thu, 2013-08-01 at 11:05 +0200, Ryuji Wakikawa wrote: >> Alper and Alex >>=20 >> Here are some CR documents >> http://tools.ietf.org/html/draft-wakikawa-mext-cr-consideration >> http://tools.ietf.org/html/draft-wakikawa-nemo-orc-01 >> It's nice to see similar idea now;-) Thanks Alper for the work! >=20 > One more, that Ryuji forgot to mention :p >=20 > http://tools.ietf.org/html/draft-bernardos-mext-nemo-ro-cr-00 >=20 > Carlos >=20 >>=20 >> BTMM (DNS-based mobility) can be found here. >> http://www.rfc-editor.org/rfc/rfc6281.txt >>=20 >> regards, >> ryuj >>=20 >>=20 >> On Aug 1, 2013, at 10:46 AM, Alexandru Petrescu = wrote: >>=20 >>> Comments on Correspondent Home Networking/CRs: >>>=20 >>> When the CR (Correspondent Router) was presented some time ago I had >>> some comments, that I re-iterate now. >>>=20 >>> There is already a problem in deploying MIP6 CN RO functionality in = the >>> numerous IPv6 content servers in the Internet. It would be probably >>> even more difficult to deploy CRs (or HA-close-to-each-CN) only to >>> support mobility. >>>=20 >>> (although now the status of MIP6 in the linux kernel is no longer >>> EXPERIMENTAL, which is very good). >>>=20 >>> The solution, as presented now, seems to rely extensively on the use = of >>> DNS - it returns the IP address of the CHA and the HoA. This is = similar >>> to what NAT64 does, and has its drawbacks as well: ping6 1::1 won't = work. >>>=20 >>> Finally, once a HoA specific to a CN is obtained at MN, then one = must >>> make sure that that HoA is not used by MN when browsing some other = CN; >>> i.e. a need to modify an application to use a particular IP address = as >>> src/dst for a particular application. >>>=20 >>> Alex >>>=20 >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 From k.pentikousis@huawei.com Thu Aug 1 02:26:15 2013 Return-Path: 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 CD5D621F8976 for ; Thu, 1 Aug 2013 02:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.124 X-Spam-Level: X-Spam-Status: No, score=-6.124 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, 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 FM5HYu83aCnS for ; Thu, 1 Aug 2013 02:26:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 47D6221F9A06 for ; Thu, 1 Aug 2013 02:26:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATZ58324; Thu, 01 Aug 2013 09:26:09 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 1 Aug 2013 10:25:35 +0100 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 1 Aug 2013 10:25:48 +0100 Received: from SZXEML511-MBX.china.huawei.com ([169.254.5.151]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.007; Thu, 1 Aug 2013 17:25:44 +0800 From: Konstantinos Pentikousis To: "dmm@ietf.org" Thread-Topic: mobileflow Thread-Index: Ac6OmRp4/dKK0gM2TvqWQcx9Msvtmw== Date: Thu, 1 Aug 2013 09:25:44 +0000 Message-ID: <8D38716F0C1A444BA0CD7E96454366C24BB29925@szxeml511-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.148.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [DMM] mobileflow X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 09:26:15 -0000 Hi all, The paper I mentioned during Ryuji's presentation is called "Mobileflow: To= ward software-defined mobile networks" You can get it from http://dx.doi.or= g/10.1109/MCOM.2013.6553677. If you do not have access to Xplore, let me kn= ow and I can email you a preprint. Best regards, Kostas From charliep@computer.org Thu Aug 1 02:32:16 2013 Return-Path: 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 0DA1F21F9FCF for ; Thu, 1 Aug 2013 02:32:16 -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] 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 9cW6xISqLwZg for ; Thu, 1 Aug 2013 02:32:11 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id A00F011E8105 for ; Thu, 1 Aug 2013 02:30:42 -0700 (PDT) Received: from [130.129.16.71] by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1V4pDS-0001JX-Js; Thu, 01 Aug 2013 05:30:38 -0400 Message-ID: <51FA2AB1.6090905@computer.org> Date: Thu, 01 Aug 2013 02:30:25 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <51FA2075.1070505@gmail.com> <1375348935.4376.6.camel@acorde.it.uc3m.es> In-Reply-To: <1375348935.4376.6.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8673222f82e324b7c37cd1ab95b041fd8b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.16.71 Cc: dmm@ietf.org Subject: Re: [DMM] Comments on Correspondent Home Networking/Correspondent Routers X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 09:32:16 -0000 Among the many... In fact, one of the original proposals for IPv6 mobility relied on such a CN mobility agent. It died a terrible death, suffering from scalability problems for managing security. Regards, Charlie P. On 8/1/2013 2:22 AM, Carlos Jesús Bernardos Cano wrote: > Hi, > > > On Thu, 2013-08-01 at 11:05 +0200, Ryuji Wakikawa wrote: >> Alper and Alex >> >> Here are some CR documents >> http://tools.ietf.org/html/draft-wakikawa-mext-cr-consideration >> http://tools.ietf.org/html/draft-wakikawa-nemo-orc-01 >> It's nice to see similar idea now;-) Thanks Alper for the work! > One more, that Ryuji forgot to mention :p > > http://tools.ietf.org/html/draft-bernardos-mext-nemo-ro-cr-00 > > Carlos > >> BTMM (DNS-based mobility) can be found here. >> http://www.rfc-editor.org/rfc/rfc6281.txt >> >> regards, >> ryuj >> >> >> On Aug 1, 2013, at 10:46 AM, Alexandru Petrescu wrote: >> >>> Comments on Correspondent Home Networking/CRs: >>> >>> When the CR (Correspondent Router) was presented some time ago I had >>> some comments, that I re-iterate now. >>> >>> There is already a problem in deploying MIP6 CN RO functionality in the >>> numerous IPv6 content servers in the Internet. It would be probably >>> even more difficult to deploy CRs (or HA-close-to-each-CN) only to >>> support mobility. >>> >>> (although now the status of MIP6 in the linux kernel is no longer >>> EXPERIMENTAL, which is very good). >>> >>> The solution, as presented now, seems to rely extensively on the use of >>> DNS - it returns the IP address of the CHA and the HoA. This is similar >>> to what NAT64 does, and has its drawbacks as well: ping6 1::1 won't work. >>> >>> Finally, once a HoA specific to a CN is obtained at MN, then one must >>> make sure that that HoA is not used by MN when browsing some other CN; >>> i.e. a need to modify an application to use a particular IP address as >>> src/dst for a particular application. >>> >>> Alex >>> >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > -- Regards, Charlie P. From h.anthony.chan@huawei.com Thu Aug 1 05:12:25 2013 Return-Path: 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 DB59511E80DF for ; Thu, 1 Aug 2013 05:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 IDNkzVHbix9W for ; Thu, 1 Aug 2013 05:12:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DB8B021F9E77 for ; Thu, 1 Aug 2013 05:10:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATZ73000; Thu, 01 Aug 2013 12:10:36 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 1 Aug 2013 13:10:10 +0100 Received: from SZXEML450-HUB.china.huawei.com (10.82.67.193) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 1 Aug 2013 13:10:07 +0100 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.202]) by szxeml450-hub.china.huawei.com ([10.82.67.193]) with mapi id 14.01.0323.007; Thu, 1 Aug 2013 20:09:45 +0800 From: h chan To: "Charles E. Perkins" , "dmm@ietf.org" Thread-Topic: [DMM] ticket #38 Thread-Index: AQHOQt0OqNCyFpvFd0ehSuZiOYwbCJmA2C/g Date: Thu, 1 Aug 2013 12:09:44 +0000 Message-ID: <6E31144C030982429702B11D6746B98C3709F53B@szxeml557-mbx.china.huawei.com> References: <517B198A.6020605@computer.org> In-Reply-To: <517B198A.6020605@computer.org> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.146.99] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] ticket #38 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 12:12:26 -0000 Charles, Is the following change from "IP multicast sessions" to "multicast flows" o= kay?=20 REQ7: Multicast: Version 06: DMM SHOULD consider multicast early so that solutions can be de= veloped not only to provide IP mobility to keep IP multicast sessions when = it is needed, but also to avoid network inefficiency issues in multicast tr= affic delivery=20 (such as duplicate multicast subscriptions towards the downstream tunnel en= tities). The multicast solutions should therefore avoid restricting the man= agement of all IP multicast traffic to a single host through a dedicated (t= unnel) interface on multicast-capable access routers. REQ7: Multicast: Version 07: DMM SHOULD consider multicast early so that solutions can be de= veloped not only to provide IP mobility to keep multicast flows when it is = needed, but also to avoid network inefficiency issues in multicast traffic = delivery=20 (such as duplicate multicast subscriptions towards the downstream tunnel en= tities). The multicast solutions should therefore avoid restricting the man= agement of all IP multicast traffic to a single host through a dedicated (t= unnel) interface on multicast-capable access routers. H Anthony Chan -----Original Message----- From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Charl= es E. Perkins Sent: Saturday, April 27, 2013 2:19 AM To: dmm@ietf.org Subject: [DMM] Editorial suggestions for draft-ietf-dmm-requirements-03 Hello folks, Here are some editorial suggestions for the document. Check for missing articles. For instance: "Gateway selection mechanism" --> "A gateway selection mechanism" "is also taking the" --> "also takes" Delete "However" before "assigning". Delete "Issues such as" Delete "When demand exceeds capacity," or else explain why the benefits ar= e unavailable otherwise. "In particular, there is an increase in direct communications among peers in the same geographical area." --> there has always been such locality... in fact maybe less now than previously. Otherwise, please provide a citation= . Delete "While deploying" "today's mobile networks, service providers face" --> "Today's mobile networks present service providers with" Delete "more often than not," Delete "Therefore it is not uncommon to observe that" "ever-increasing" --> "unnecessary" "provided" --> "managed" "non-optimal" --> "unnecessary" Delete "Given this motivational background in this section," "address these problems": at this point in the document, the problems have not been identified. As suggested earlier, there should be a section devoted to listing the problems, and then a cross reference to that section could go here. "changing IP address" --> "locator IP address" Insert "The" before "Gateway GPRS Support Node" "respectively, act" --> "all act" "SAE" --> "EPC" "closeby" --> "nearby" Center figure 2. (and might as well center figure 1 too) "future flat IP-based" --> "flat IP-based" (unwise to predict the future) "states the requirements as follows" --> "identifies the following r= equirements" "Distributed deployment" --> "Distributed processing" ... also in "REQ1" "of IP sessions" --> "of some flows" "an optimal manner" --> "to avoid known bottlenecks" "This requirement addresses problems PS1, PS2, PS3, and PS4 in the following." ... the following ?what? "each MN therein" .... the MNs are not "in" the tunnel, and they are not "in" the mobility anch= or. "Centralized anchoring" --> "Centralized anchoring designs" "Distributing the tunnel maintenance function and the mobility context maintenance function among different network entities can increase scalability." --> only when the signaling protocol is properly designed= . "is to be inline" --> "conforms" "may need to interoperate with a network or mobile hosts/ routers that do not support DMM protocols." ... this is technically infeasible. Suggested replacement: "may need to co-exist with a network or mobile hosts/ routers that do not support DMM protocols." Delete "The motivations of this requirement are" -- Regards, Charlie P. _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm From brian@innovationslab.net Thu Aug 1 05:38:56 2013 Return-Path: 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 A5E5B21F9C59 for ; Thu, 1 Aug 2013 05:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 IdSlH49POt70 for ; Thu, 1 Aug 2013 05:38:49 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id EBA1A21F964C for ; Thu, 1 Aug 2013 05:35:04 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 634B88814A for ; Thu, 1 Aug 2013 05:35:03 -0700 (PDT) Received: from 10252091.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id BC5D113680FE for ; Thu, 1 Aug 2013 05:35:02 -0700 (PDT) Message-ID: <51FA55F9.1040109@innovationslab.net> Date: Thu, 01 Aug 2013 08:35:05 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: dmm@ietf.org References: <517B198A.6020605@computer.org> <6E31144C030982429702B11D6746B98C3709F53B@szxeml557-mbx.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C3709F53B@szxeml557-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [DMM] ticket #38 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 12:38:56 -0000 I agree with Charlie's request to move away from the term "session". It really does not have much meaning in UDP-based applications. However, the term "flow" does have some issues as well. Are we using the term "flow" the way it is defined in RFC 5101? If not, then it needs to be defined in this draft. Regards, Brian On 8/1/13 8:09 AM, h chan wrote: > Charles, > Is the following change from "IP multicast sessions" to "multicast flows" okay? > > REQ7: Multicast: > Version 06: DMM SHOULD consider multicast early so that solutions can be developed not only to provide IP mobility to keep IP multicast sessions when it is needed, but also to avoid network inefficiency issues in multicast traffic delivery > (such as duplicate multicast subscriptions towards the downstream tunnel entities). The multicast solutions should therefore avoid restricting the management of all IP multicast traffic to a single host through a dedicated (tunnel) interface on multicast-capable access routers. > > REQ7: Multicast: > Version 07: DMM SHOULD consider multicast early so that solutions can be developed not only to provide IP mobility to keep multicast flows when it is needed, but also to avoid network inefficiency issues in multicast traffic delivery > (such as duplicate multicast subscriptions towards the downstream tunnel entities). The multicast solutions should therefore avoid restricting the management of all IP multicast traffic to a single host through a dedicated (tunnel) interface on multicast-capable access routers. > > H Anthony Chan > > -----Original Message----- > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Charles E. Perkins > Sent: Saturday, April 27, 2013 2:19 AM > To: dmm@ietf.org > Subject: [DMM] Editorial suggestions for draft-ietf-dmm-requirements-03 > > Hello folks, > > Here are some editorial suggestions for the document. > > Check for missing articles. For instance: > "Gateway selection mechanism" --> "A gateway selection mechanism" > > "is also taking the" --> "also takes" > > Delete "However" before "assigning". > > Delete "Issues such as" > > Delete "When demand exceeds capacity," or else explain why the benefits are unavailable otherwise. > > "In particular, there is an increase in direct communications among > peers in the same geographical area." > --> there has always been such locality... in fact maybe less > now than previously. Otherwise, please provide a citation. > > Delete "While deploying" > > "today's mobile networks, service providers face" --> > "Today's mobile networks present service providers with" > > Delete "more often than not," > > Delete "Therefore it is not uncommon to observe that" > > "ever-increasing" --> "unnecessary" > > "provided" --> "managed" > > "non-optimal" --> "unnecessary" > > Delete "Given this motivational background in this section," > > "address these problems": at this point in the document, the > problems have not been identified. As suggested earlier, > there should be a section devoted to listing the problems, > and then a cross reference to that section could go here. > > "changing IP address" --> "locator IP address" > > Insert "The" before "Gateway GPRS Support Node" > > "respectively, act" --> "all act" > > "SAE" --> "EPC" > > "closeby" --> "nearby" > > Center figure 2. (and might as well center figure 1 too) > > "future flat IP-based" --> "flat IP-based" > (unwise to predict the future) > > "states the requirements as follows" --> > "identifies the following requirements" > > "Distributed deployment" --> "Distributed processing" > ... also in "REQ1" > > "of IP sessions" --> "of some flows" > > "an optimal manner" --> "to avoid known bottlenecks" > > "This requirement addresses problems PS1, PS2, PS3, and PS4 in the > following." > ... the following ?what? > > "each MN therein" .... the MNs are not "in" the tunnel, and they are > not "in" the mobility anchor. > > "Centralized anchoring" --> "Centralized anchoring designs" > > "Distributing > the tunnel maintenance function and the mobility context > maintenance function among different network entities can > increase scalability." > --> only when the signaling protocol is properly designed. > > "is to be inline" --> "conforms" > > "may need to interoperate with a network or mobile hosts/ > routers that do not support DMM protocols." > ... this is technically infeasible. > Suggested replacement: > "may need to co-exist with a network or mobile hosts/ > routers that do not support DMM protocols." > > Delete "The motivations of this requirement are" > > -- > Regards, > Charlie P. > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > From h.anthony.chan@huawei.com Thu Aug 1 08:07:25 2013 Return-Path: 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 1294E21E80FF for ; Thu, 1 Aug 2013 08:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 7gAlQ+Js7LRc for ; Thu, 1 Aug 2013 08:07:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4B59121E8114 for ; Thu, 1 Aug 2013 08:07:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATZ86689; Thu, 01 Aug 2013 15:07:07 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 1 Aug 2013 16:06:52 +0100 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 1 Aug 2013 16:07:04 +0100 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.202]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Thu, 1 Aug 2013 23:06:58 +0800 From: h chan To: Brian Haberman , "dmm@ietf.org" Thread-Topic: [DMM] ticket #38 Thread-Index: AQHOjrnXTzflqTrDL0msVGWRcV/aRZmAcLIw Date: Thu, 1 Aug 2013 15:06:57 +0000 Message-ID: <6E31144C030982429702B11D6746B98C3709F589@szxeml557-mbx.china.huawei.com> References: <517B198A.6020605@computer.org> <6E31144C030982429702B11D6746B98C3709F53B@szxeml557-mbx.china.huawei.com> <51FA55F9.1040109@innovationslab.net> In-Reply-To: <51FA55F9.1040109@innovationslab.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.140.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] ticket #38 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 15:07:25 -0000 I also agree "IP session" is not the right term. An alternative is to call = it "application session" or just "session" if it is also not necessary for = a requirement draft to introduce "flow".=20 It is some "applications" that need session continuity. There is then no ne= ed to introduce "flow" for a requirement draft to keep it simple. Then "IP session" in REQ1 can change to "application session" "IP multicast session" in REQ7 can change to "multicast session" Do we agree? If not, please suggest alternative text.=20 H Anthony Chan -----Original Message----- From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Brian= Haberman Sent: Thursday, August 01, 2013 2:35 PM To: dmm@ietf.org Subject: Re: [DMM] ticket #38 I agree with Charlie's request to move away from the term "session". It re= ally does not have much meaning in UDP-based applications. However, the te= rm "flow" does have some issues as well. Are we using the term "flow" the = way it is defined in RFC 5101? If not, then it needs to be defined in this= draft. Regards, Brian On 8/1/13 8:09 AM, h chan wrote: > Charles, > Is the following change from "IP multicast sessions" to "multicast flows"= okay? > > REQ7: Multicast: > Version 06: DMM SHOULD consider multicast early so that solutions can=20 > be developed not only to provide IP mobility to keep IP multicast session= s when it is needed, but also to avoid network inefficiency issues in multi= cast traffic delivery (such as duplicate multicast subscriptions towards th= e downstream tunnel entities). The multicast solutions should therefore avo= id restricting the management of all IP multicast traffic to a single host = through a dedicated (tunnel) interface on multicast-capable access routers. > > REQ7: Multicast: > Version 07: DMM SHOULD consider multicast early so that solutions can=20 > be developed not only to provide IP mobility to keep multicast flows when= it is needed, but also to avoid network inefficiency issues in multicast t= raffic delivery (such as duplicate multicast subscriptions towards the down= stream tunnel entities). The multicast solutions should therefore avoid res= tricting the management of all IP multicast traffic to a single host throug= h a dedicated (tunnel) interface on multicast-capable access routers. > > H Anthony Chan > > -----Original Message----- > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of=20 > Charles E. Perkins > Sent: Saturday, April 27, 2013 2:19 AM > To: dmm@ietf.org > Subject: [DMM] Editorial suggestions for=20 > draft-ietf-dmm-requirements-03 > > Hello folks, > > Here are some editorial suggestions for the document. > > Check for missing articles. For instance: > "Gateway selection mechanism" --> "A gateway selection mechanism" > > "is also taking the" --> "also takes" > > Delete "However" before "assigning". > > Delete "Issues such as" > > Delete "When demand exceeds capacity," or else explain why the benefits = are unavailable otherwise. > > "In particular, there is an increase in direct communications among > peers in the same geographical area." > --> there has always been such locality... in fact maybe less > now than previously. Otherwise, please provide a citat= ion. > > Delete "While deploying" > > "today's mobile networks, service providers face" --> > "Today's mobile networks present service providers with" > > Delete "more often than not," > > Delete "Therefore it is not uncommon to observe that" > > "ever-increasing" --> "unnecessary" > > "provided" --> "managed" > > "non-optimal" --> "unnecessary" > > Delete "Given this motivational background in this section," > > "address these problems": at this point in the document, the > problems have not been identified. As suggested earlie= r, > there should be a section devoted to listing the proble= ms, > and then a cross reference to that section could go her= e. > > "changing IP address" --> "locator IP address" > > Insert "The" before "Gateway GPRS Support Node" > > "respectively, act" --> "all act" > > "SAE" --> "EPC" > > "closeby" --> "nearby" > > Center figure 2. (and might as well center figure 1 too) > > "future flat IP-based" --> "flat IP-based" > (unwise to predict the future) > > "states the requirements as follows" --> > "identifies the followin= g requirements" > > "Distributed deployment" --> "Distributed processing" > ... also in "REQ1" > > "of IP sessions" --> "of some flows" > > "an optimal manner" --> "to avoid known bottlenecks" > > "This requirement addresses problems PS1, PS2, PS3, and PS4 in the > following." > ... the following ?what? > > "each MN therein" .... the MNs are not "in" the tunnel, and they are > not "in" the mobility a= nchor. > > "Centralized anchoring" --> "Centralized anchoring designs" > > "Distributing > the tunnel maintenance function and the mobility context > maintenance function among different network entities can > increase scalability." > --> only when the signaling protocol is properly desig= ned. > > "is to be inline" --> "conforms" > > "may need to interoperate with a network or mobile hosts/ > routers that do not support DMM protocols." > ... this is technically infeasible. > Suggested replacement: > "may need to co-exist with a network or mobile hosts/ > routers that do not support DMM protocols." > > Delete "The motivations of this requirement are" > > -- > Regards, > Charlie P. > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm From h.anthony.chan@huawei.com Thu Aug 1 08:42:56 2013 Return-Path: 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 3FA0E21E81FD for ; Thu, 1 Aug 2013 08:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 kRm00LA2iwXc for ; Thu, 1 Aug 2013 08:42:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4394721E8195 for ; Thu, 1 Aug 2013 08:42:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATZ88957; Thu, 01 Aug 2013 15:42:46 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 1 Aug 2013 16:42:31 +0100 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 1 Aug 2013 16:42:44 +0100 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.202]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.007; Thu, 1 Aug 2013 23:42:39 +0800 From: h chan To: Brian Haberman , "dmm@ietf.org" Thread-Topic: [DMM] ticket #38 Thread-Index: AQHOjrnXTzflqTrDL0msVGWRcV/aRZmAcLIwgAAJWQA= Date: Thu, 1 Aug 2013 15:42:39 +0000 Message-ID: <6E31144C030982429702B11D6746B98C3709F598@szxeml557-mbx.china.huawei.com> References: <517B198A.6020605@computer.org> <6E31144C030982429702B11D6746B98C3709F53B@szxeml557-mbx.china.huawei.com> <51FA55F9.1040109@innovationslab.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.140.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] ticket #38 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 15:42:56 -0000 Let me try to revise again if it helps to clarify the meaning: "IP session" in REQ1 (in version 03) can change to "application session" (i= n version 07 to be uploaded today) REQ7: Multicast: Version 07: DMM SHOULD consider multicast early so that solutions can be de= veloped not only to provide IP mobility to keep multicast application sessi= ons when it is needed, but also to avoid network inefficiency issues in mul= ticast traffic delivery (such as duplicate multicast subscriptions towards = the downstream tunnel entities). The multicast solutions should therefore a= void restricting the management of all IP multicast traffic to a single hos= t through a dedicated (tunnel) interface on multicast-capable access router= s. Or simply (less words) REQ7: Multicast: Version 07: DMM SHOULD consider multicast early so that solutions can be de= veloped not only to provide IP mobility support to multicast applications w= hen it is needed, but also to avoid network inefficiency issues in multicas= t traffic delivery (such as duplicate multicast subscriptions towards the d= ownstream tunnel entities). The multicast solutions should therefore avoid = restricting the management of all IP multicast traffic to a single host thr= ough a dedicated (tunnel) interface on multicast-capable access routers. H Anthony Chan -----Original Message----- From: h chan=20 Sent: Thursday, August 01, 2013 5:07 PM To: 'Brian Haberman'; dmm@ietf.org Subject: RE: [DMM] ticket #38 I also agree "IP session" is not the right term. An alternative is to call = it "application session" or just "session" if it is also not necessary for = a requirement draft to introduce "flow".=20 It is some "applications" that need session continuity. There is then no ne= ed to introduce "flow" for a requirement draft to keep it simple. Then "IP session" in REQ1 can change to "application session" "IP multicast session" in REQ7 can change to "multicast session" Do we agree? If not, please suggest alternative text.=20 H Anthony Chan -----Original Message----- From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Brian= Haberman Sent: Thursday, August 01, 2013 2:35 PM To: dmm@ietf.org Subject: Re: [DMM] ticket #38 I agree with Charlie's request to move away from the term "session". It re= ally does not have much meaning in UDP-based applications. However, the te= rm "flow" does have some issues as well. Are we using the term "flow" the = way it is defined in RFC 5101? If not, then it needs to be defined in this= draft. Regards, Brian On 8/1/13 8:09 AM, h chan wrote: > Charles, > Is the following change from "IP multicast sessions" to "multicast flows"= okay? > > REQ7: Multicast: > Version 06: DMM SHOULD consider multicast early so that solutions can=20 > be developed not only to provide IP mobility to keep IP multicast session= s when it is needed, but also to avoid network inefficiency issues in multi= cast traffic delivery (such as duplicate multicast subscriptions towards th= e downstream tunnel entities). The multicast solutions should therefore avo= id restricting the management of all IP multicast traffic to a single host = through a dedicated (tunnel) interface on multicast-capable access routers. > > REQ7: Multicast: > Version 07: DMM SHOULD consider multicast early so that solutions can=20 > be developed not only to provide IP mobility to keep multicast flows when= it is needed, but also to avoid network inefficiency issues in multicast t= raffic delivery (such as duplicate multicast subscriptions towards the down= stream tunnel entities). The multicast solutions should therefore avoid res= tricting the management of all IP multicast traffic to a single host throug= h a dedicated (tunnel) interface on multicast-capable access routers. > > H Anthony Chan > > -----Original Message----- > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of=20 > Charles E. Perkins > Sent: Saturday, April 27, 2013 2:19 AM > To: dmm@ietf.org > Subject: [DMM] Editorial suggestions for > draft-ietf-dmm-requirements-03 > > Hello folks, > > Here are some editorial suggestions for the document. > > Check for missing articles. For instance: > "Gateway selection mechanism" --> "A gateway selection mechanism" > > "is also taking the" --> "also takes" > > Delete "However" before "assigning". > > Delete "Issues such as" > > Delete "When demand exceeds capacity," or else explain why the benefits = are unavailable otherwise. > > "In particular, there is an increase in direct communications among > peers in the same geographical area." > --> there has always been such locality... in fact maybe less > now than previously. Otherwise, please provide a citat= ion. > > Delete "While deploying" > > "today's mobile networks, service providers face" --> > "Today's mobile networks present service providers with" > > Delete "more often than not," > > Delete "Therefore it is not uncommon to observe that" > > "ever-increasing" --> "unnecessary" > > "provided" --> "managed" > > "non-optimal" --> "unnecessary" > > Delete "Given this motivational background in this section," > > "address these problems": at this point in the document, the > problems have not been identified. As suggested earlie= r, > there should be a section devoted to listing the proble= ms, > and then a cross reference to that section could go her= e. > > "changing IP address" --> "locator IP address" > > Insert "The" before "Gateway GPRS Support Node" > > "respectively, act" --> "all act" > > "SAE" --> "EPC" > > "closeby" --> "nearby" > > Center figure 2. (and might as well center figure 1 too) > > "future flat IP-based" --> "flat IP-based" > (unwise to predict the future) > > "states the requirements as follows" --> > "identifies the followin= g requirements" > > "Distributed deployment" --> "Distributed processing" > ... also in "REQ1" > > "of IP sessions" --> "of some flows" > > "an optimal manner" --> "to avoid known bottlenecks" > > "This requirement addresses problems PS1, PS2, PS3, and PS4 in the > following." > ... the following ?what? > > "each MN therein" .... the MNs are not "in" the tunnel, and they are > not "in" the mobility a= nchor. > > "Centralized anchoring" --> "Centralized anchoring designs" > > "Distributing > the tunnel maintenance function and the mobility context > maintenance function among different network entities can > increase scalability." > --> only when the signaling protocol is properly desig= ned. > > "is to be inline" --> "conforms" > > "may need to interoperate with a network or mobile hosts/ > routers that do not support DMM protocols." > ... this is technically infeasible. > Suggested replacement: > "may need to co-exist with a network or mobile hosts/ > routers that do not support DMM protocols." > > Delete "The motivations of this requirement are" > > -- > Regards, > Charlie P. > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm From Peter.McCann@huawei.com Thu Aug 1 09:02:30 2013 Return-Path: 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 526A621E818D for ; Thu, 1 Aug 2013 09:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, 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 gfpf-ALAT68u for ; Thu, 1 Aug 2013 09:02:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2E03121E815C for ; Thu, 1 Aug 2013 09:02:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATZ90115; Thu, 01 Aug 2013 16:02:23 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 1 Aug 2013 17:02:09 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 1 Aug 2013 17:02:22 +0100 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.163]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.007; Thu, 1 Aug 2013 09:02:20 -0700 From: Peter McCann To: Marco Liebsch , "dmm@ietf.org" Thread-Topic: Elements of a DMM Solution Thread-Index: Ac6NFTnvNwdJkIljSBKhE1ur31iYxgBKeN3gACPS1AA= Date: Thu, 1 Aug 2013 16:02:19 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716F51828@dfweml512-mbx.china.huawei.com> References: <5963DDF1F751474D8DEEFDCDBEE43AE716F5138A@dfweml512-mbx.china.huawei.com> <69756203DDDDE64E987BC4F70B71A26D55310296@DAPHNIS.office.hd> In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D55310296@DAPHNIS.office.hd> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] Elements of a DMM Solution X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 16:02:30 -0000 Hi, Marco, Marco Liebsch wrote: > Hi Pete, >=20 > I support your proposal. Please see (so far brief) feedback inline. >=20 >> -----Original Message----- >> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of >> Peter McCann >> Sent: Dienstag, 30. Juli 2013 13:09 >> To: dmm@ietf.org >> Subject: [DMM] Elements of a DMM Solution >>=20 >> I think that the DMM work can be subdivided into a small number of >> "modules", each of which can be implemented in a number of different >> ways. >>=20 >>=20 >> I. Limited-scope (localized) network-based mobility scheme >>=20 >> This is probably what most people have in mind when they think of a DMM >> "protocol". This is the mechanism that gets packets to the current >> point of attachment. We have seen the following proposed as options >> for this module: >>=20 >> A. Something based on PMIP >> B. Something based on GTP >> C. Something based on a routing protocol (e.g., BGP) >> D. Something based on SDN >> We should be able to "plug in" any of the above solutions to an overall >> DMM framework. This module needs to be signaled when an MN attaches or >> changes its point of attachment. An identifier of the MN and an >> identifier of the attachment point should be provided in this signal. >> This module needs to interact with the address allocation/management >> module to obtain the set of IP prefixes currently in use by the mobile >> node, so that redirection/tunneling of packets destined to those >> prefixes can be set up. This may require a network- queryable database >> of prefixes that can be indexed by mobile node identifier. This >> database could be stored in something like an HSS or in a DNS >> server. >=20 > Yes, or an IP mobility anchor control plane function, or a registry > associated with an SDN controller, or.. something that can treat the > MN's IP address (prefix) as identifier and select an appropriate > routable locator IP address. I fully support that view that any DMM > solution should consider hooks to external (non- mobility) protocols to > optimize (D)MM operation and is well aligned with the methodology in our > framework draft. I don't think the MN's IP address (prefix) will necessarily be the identifi= er of choice. Perhaps an NAI or other identifier authenticated at the time of access is the right one to use. It's good to have this discussion; once we pin down the interface between Module I and the rest of the system we can work independently on the pieces= . >> II. Address allocation/management >>=20 >> This module lives in both the MN and the network. The MN maintains a >> pool of addresses, each one topologically related to the point of >> attachment at the time it was assigned. The MN should be made aware of >> which of its addresses are currently on-link at its current attachment >> point, courtesy of Module I. The MN should maintain information about >> how it is using each address so that unused addresses can be released >> and in-use addresses can have their leases renewed at the appropriate >> times. Address allocation/deallocation should NOT be coupled to node >> mobility. It should be possible to have a mobility event without >> allocating a new address (to avoid excessive numbers of addresses being >> allocated) and even if Module I cannot provide network-based relocation >> of a prefix, mobility to an attachment point where an address is not >> on-link SHOULD NOT trigger deallocation of the address, because the MN >> might have a client- based mobility scheme that enables it to continue >> using the address (Module III). Some mechanism to renew the lease on >> the address from a remote location should be provided, such as >> obtaining a global unicast IP address of a DHCP server. Security >> considerations for such remote renewal need to be investigated and >> addressed. >=20 > So, on-link addresses are routable addresses associated with the MN's > current anchor, whereas other addresses (off-link?) are associated > with the previous anchor (or point of attachment) and considered deprecat= ed. > Correct?=20 I really dislike the term "anchor". It seems to imply there is a fixed=20 point in the network through which the MN's traffic is flowing and is also semantically linked to tunnel-based solutions. When I say "on-link" I mean the prefix is currently advertised in an RA on the current link (in IPv6 terms). The degree to which it is topological= ly aggregateable may vary depending on how far the MN has moved. It may or may not be marked as "deprecated" by the advertising AR; in any case, it=20 is available for use by ongoing sessions or possibly new sessions according to logic inside the MN. Addresses that are not advertised on-link, if they are still needed, should be supported with a client-based tunnel. > Dependent on the solution for DMM, this IP address is not > routable anymore if imported to the current anchor to enable IP > address continuity or remains routable through the MN's previous > anchor. In the latter case the MN may have multiple anchors which may > have to be added to the address management module, at least in case of > client-based mobility. Again, don't like "anchor". Hopefully the above explanation tells you how I am defining my terms. >> Module I must be provided with a list of prefixes currently allocated >> to the MN. The database storing this information could be updated by >> the network element that allocates the address (e.g., DHCP server) or >> could be updated by the MN. A network element initiated update may be >> more appropriate for an HSS-stored database, whereas an MN-initiated >> update may be more appropriate for a DNS- based database. >=20 > Well, in general this is about a dynamic binding in a database between > one or more IP addresses of the MN and associated locator(s). > Important is that this can be something else than what is provided by > Mobile IP protocols. And this makes sense, as it applies to the > routing space above mobility anchor level (southbound to MM U-Plane > function, or attachment point according to your terminology). > Who updates the database is up to a particular solution. Again, I think the binding is from some other identifier (like NAI) to a set of currently allocated/assigned IP addresses. While there are=20 mechanisms to allocate IP addresses using Mobile IP, I don't think they necessarily will be used by DMM because most addresses should be=20 topologically correct a the time they are assigned instead of being routed through a home agent. Agree that database update details are a property of individual solutions. >> III. An optional global, client-based mobility scheme >>=20 >> Any network-based mobility scheme will necessarily have a limited >> scope. This is especially true in the DMM case because the Internet >> attachment points are by definition close to the MN in the access >> (visited) network. Consider a roaming mobile node with home network H >> that attaches to visited network V1. It obtains DMM service from V1, >> obtaining an IP address topologically routed from the Internet directly >> to V1. Now consider this MN performing a handoff from V1 to another >> visited network V2. V2 has a roaming agreement with H (otherwise the >> MN would not be able to get service) but has absolutely no business >> arrangement with V1. Therefore, it is impossible for the network-based >> mobility scheme to support re-routing or tunneling the packets destined >> to the original V1 address to network V2. We must therefore support >> fall-back to a client-based OTT global mobility scheme, using the fact >> that both V1 and V2 offer connectivity to the same Internet, if the MN >> wants to keep using the address it got while connected to V1. >>=20 >> Allocation of a global mobility anchor should be coupled to allocation >> of the address for which global mobility is needed. There are already >> DHCP extensions to carry HA IP addresses which could be used for this >> purpose. The MN-HA security association should also be bootstrapped at >> this time, so that the establishment of security does not add latency >> at the time the global mobility service is invoked. We need to >> investigate whether the current DHCP extension provides the right kind >> of HA identifier to the MN or whether a DNS name would be more helpful >> in bootstrapping security. >>=20 >> The global mobility anchor may invoke Module I to get the HoA- >> addressed packets delivered to itself before tunneling them to the MN's >> CoA. The MN should make use of Module I for its CoA in its new visited >> network to minimize the number of global mobility location update >> messages it needs to send to the anchor point. >>=20 >>=20 >> IV. Security >>=20 >> Module I depends on a secure network access control protocol to provide >> an authenticated MN identity. Similarly, Module III requires >> bootstrapping a security association between MN and HA. So far, the >> AAA suite of protocols have been used for this purpose. However, it >> may be possible to further optimize this process and unify the >> credentials used by the various nodes if new solutions are >> investigated. Eliminating the round-trip to the home AAA server would >> dramatically improve the performance of network attachment and MN- HA >> SA establishment. Making use of DNS-based public key credentials that >> can be locally cached may allow the elimination of this round-trip and >> improve the scalability of home network infrastructure. >>=20 >> These enhancements to security can be decoupled from the rest of the >> architecture and investigated separately. >>=20 >>=20 >>=20 >>=20 >> I think it's important for the DMM working group to investigate all 4 >> of the above solution components, even though most people in the group >> are probably focused on Module I for now. We need to understand how >> the pieces will fit together into an overall system. To the extent we >> need to make changes to MN implementation practices, we should publish >> advice in Informational RFCs. To the extent we need to modify protocols >> that are outside the scope of DMM, we should send requirements to other >> working groups and encourage the work to get done. >=20 >=20 > Makes sense to me. Ok, good. Maybe if we can get agreement on the various pieces we can arrive at an updated framework document. -Pete >=20 > marco >=20 >>=20 >>=20 >> -- >> 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 >>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From Peter.McCann@huawei.com Thu Aug 1 09:08:09 2013 Return-Path: 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 06C7C21E80BE for ; Thu, 1 Aug 2013 09:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, 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 n--TO3tgDSrL for ; Thu, 1 Aug 2013 09:08:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6374121E8088 for ; Thu, 1 Aug 2013 09:08:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATZ90466; Thu, 01 Aug 2013 16:07:59 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 1 Aug 2013 17:07:41 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 1 Aug 2013 17:07:54 +0100 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.163]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.007; Thu, 1 Aug 2013 09:07:47 -0700 From: Peter McCann To: "karagian@cs.utwente.nl" , "dmm@ietf.org" Thread-Topic: Elements of a DMM Solution Thread-Index: Ac6NFTnvNwdJkIljSBKhE1ur31iYxgBoBjiAAAbsI2A= Date: Thu, 1 Aug 2013 16:07:47 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716F5183A@dfweml512-mbx.china.huawei.com> References: <5963DDF1F751474D8DEEFDCDBEE43AE716F5138A@dfweml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] Elements of a DMM Solution X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 16:08:09 -0000 Hi, Georgios, Essentially, yes. And we can talk separately about the solution for each module. And different operators might make different choices for which solution(s) to deploy in their network. -Pete karagian@cs.utwente.nl wrote: > Hi Peter, >=20 >=20 >=20 > I agree with the main message of your email, which I am translating into: >=20 >=20 >=20 > *) Define protocol agnostic Functional Framework to build DMM > solutions around existing mobility protocols: > o) can apply to solutions that are solely based on existing IP > mobility protocols=20 > o) can apply to solutions which get support from > non mobility protocols >=20 >=20 >=20 > Best regards, >=20 > Georgios >=20 > ________________________________ >=20 > Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens Peter McCann > [Peter.McCann@huawei.com] Verzonden: dinsdag 30 juli 2013 13:09 To: > dmm@ietf.org Onderwerp: [DMM] Elements of a DMM Solution >=20 >=20 > I think that the DMM work can be subdivided into a small number of > "modules", each of which can be implemented in a number of different > ways. >=20 >=20 > I. Limited-scope (localized) network-based mobility scheme >=20 > This is probably what most people have in mind when they think of a > DMM "protocol". This is the mechanism that gets packets to the > current point of attachment. We have seen the following proposed as > options for this > module: >=20 > A. Something based on PMIP > B. Something based on GTP > C. Something based on a routing protocol (e.g., BGP) > D. Something based on SDN > We should be able to "plug in" any of the above solutions to an > overall DMM framework. This module needs to be signaled when an MN > attaches or changes its point of attachment. An identifier of the MN > and an identifier of the attachment point should be provided in this sign= al. > This module needs to interact with the address allocation/management > module to obtain the set of IP prefixes currently in use by the mobile > node, so that redirection/tunneling of packets destined to those > prefixes can be set up. This may require a network-queryable database > of prefixes that can be indexed by mobile node identifier. This > database could be stored in something like an HSS or in a DNS server. >=20 >=20 > II. Address allocation/management >=20 > This module lives in both the MN and the network. The MN maintains a > pool of addresses, each one topologically related to the point of > attachment at the time it was assigned. The MN should be made aware > of which of its addresses are currently on-link at its current > attachment point, courtesy of Module I. The MN should maintain > information about how it is using each address so that unused > addresses can be released and in-use addresses can have their leases > renewed at the appropriate times. Address allocation/deallocation > should NOT be coupled to node mobility. It should be possible to have > a mobility event without allocating a new address (to avoid excessive > numbers of addresses being > allocated) and even if Module I cannot provide network-based > relocation of a prefix, mobility to an attachment point where an > address is not on-link SHOULD NOT trigger deallocation of the address, > because the MN might have a client-based mobility scheme that enables > it to continue using the address (Module III). Some mechanism to > renew the lease on the address from a remote location should be > provided, such as obtaining a global unicast IP address of a DHCP > server. Security considerations for such remote renewal need to be > investigated and addressed. >=20 > Module I must be provided with a list of prefixes currently allocated > to the MN. > The database storing this information could be updated by the network > element that allocates the address (e.g., DHCP server) or could be > updated by the MN. A network element initiated update may be more > appropriate for an HSS-stored database, whereas an MN-initiated update > may be more appropriate for a DNS-based database. >=20 >=20 > III. An optional global, client-based mobility scheme >=20 > Any network-based mobility scheme will necessarily have a limited > scope. This is especially true in the DMM case because the Internet > attachment points are by definition close to the MN in the access > (visited) network. Consider a roaming mobile node with home network H > that attaches to visited network V1. > It obtains DMM service from V1, obtaining an IP address topologically > routed from the Internet directly to V1. Now consider this MN > performing a handoff from V1 to another visited network V2. V2 has a > roaming agreement with H (otherwise the MN would not be able to get > service) but has absolutely no business arrangement with V1. > Therefore, it is impossible for the network-based mobility scheme to > support re-routing or tunneling the packets destined to the original > V1 address to network V2. We must therefore support fall-back to a > client-based OTT global mobility scheme, using the fact that both V1 > and V2 offer connectivity to the same Internet, if the MN wants to > keep using the address it got while connected to V1. >=20 > Allocation of a global mobility anchor should be coupled to allocation > of the address for which global mobility is needed. There are already > DHCP extensions to carry HA IP addresses which could be used for this > purpose. The MN-HA security association should also be bootstrapped > at this time, so that the establishment of security does not add > latency at the time the global mobility service is invoked. We need > to investigate whether the current DHCP extension provides the right > kind of HA identifier to the MN or whether a DNS name would be more > helpful in bootstrapping security. >=20 > The global mobility anchor may invoke Module I to get the > HoA-addressed packets delivered to itself before tunneling them to the > MN's CoA. The MN should make use of Module I for its CoA in its new > visited network to minimize the number of global mobility location > update messages it needs to send to the anchor point. >=20 >=20 > IV. Security >=20 > Module I depends on a secure network access control protocol to > provide an authenticated MN identity. Similarly, Module III requires > bootstrapping a security association between MN and HA. So far, the > AAA suite of protocols have been used for this purpose. However, it > may be possible to further optimize this process and unify the > credentials used by the various nodes if new solutions are > investigated. Eliminating the round-trip to the home AAA server would > dramatically improve the performance of network attachment and MN-HA > SA establishment. Making use of DNS-based public key credentials that > can be locally cached may allow the elimination of this round-trip and > improve the scalability of home network infrastructure. >=20 > These enhancements to security can be decoupled from the rest of the > architecture and investigated separately. >=20 >=20 >=20 >=20 > I think it's important for the DMM working group to investigate all 4 > of the above solution components, even though most people in the group > are probably focused on Module I for now. We need to understand how > the pieces will fit together into an overall system. To the extent we > need to make changes to MN implementation practices, we should publish > advice in Informational RFCs. > To the extent we need to modify protocols that are outside the scope > of DMM, we should send requirements to other working groups and > encourage the work to get done. >=20 > From Marco.Liebsch@neclab.eu Thu Aug 1 09:42:25 2013 Return-Path: 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 EB91121E8195 for ; Thu, 1 Aug 2013 09:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 xrH7a8ROKgiu for ; Thu, 1 Aug 2013 09:42:20 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id D50CB21E815C for ; Thu, 1 Aug 2013 09:42:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 19AC3105190; Thu, 1 Aug 2013 18:41:32 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfmTGa8AU8bB; Thu, 1 Aug 2013 18:41:32 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id F2A4B10518F; Thu, 1 Aug 2013 18:41:21 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.153]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 1 Aug 2013 18:42:05 +0200 From: Marco Liebsch To: Peter McCann Thread-Topic: Elements of a DMM Solution Thread-Index: Ac6NFTnvNwdJkIljSBKhE1ur31iYxgBKeN3gACPS1AAAAelJYQ== Date: Thu, 1 Aug 2013 16:42:05 +0000 Message-ID: References: <5963DDF1F751474D8DEEFDCDBEE43AE716F5138A@dfweml512-mbx.china.huawei.com> <69756203DDDDE64E987BC4F70B71A26D55310296@DAPHNIS.office.hd>, <5963DDF1F751474D8DEEFDCDBEE43AE716F51828@dfweml512-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716F51828@dfweml512-mbx.china.huawei.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dmm@ietf.org" Subject: Re: [DMM] Elements of a DMM Solution X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 16:42:25 -0000 Hi Pete, please see inline. On 01.08.2013, at 18:02, "Peter McCann" wrote: > Hi, Marco, >=20 > Marco Liebsch wrote: >> Hi Pete, >>=20 >> I support your proposal. Please see (so far brief) feedback inline. >>=20 >>> -----Original Message----- >>> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of >>> Peter McCann >>> Sent: Dienstag, 30. Juli 2013 13:09 >>> To: dmm@ietf.org >>> Subject: [DMM] Elements of a DMM Solution >>>=20 >>> I think that the DMM work can be subdivided into a small number of >>> "modules", each of which can be implemented in a number of different >>> ways. >>>=20 >>>=20 >>> I. Limited-scope (localized) network-based mobility scheme >>>=20 >>> This is probably what most people have in mind when they think of a DMM >>> "protocol". This is the mechanism that gets packets to the current >>> point of attachment. We have seen the following proposed as options >>> for this module: >>>=20 >>> A. Something based on PMIP >>> B. Something based on GTP >>> C. Something based on a routing protocol (e.g., BGP) >>> D. Something based on SDN >>> We should be able to "plug in" any of the above solutions to an overall >>> DMM framework. This module needs to be signaled when an MN attaches or >>> changes its point of attachment. An identifier of the MN and an >>> identifier of the attachment point should be provided in this signal. >>> This module needs to interact with the address allocation/management >>> module to obtain the set of IP prefixes currently in use by the mobile >>> node, so that redirection/tunneling of packets destined to those >>> prefixes can be set up. This may require a network- queryable database >>> of prefixes that can be indexed by mobile node identifier. This >>> database could be stored in something like an HSS or in a DNS >>> server. >>=20 >> Yes, or an IP mobility anchor control plane function, or a registry >> associated with an SDN controller, or.. something that can treat the >> MN's IP address (prefix) as identifier and select an appropriate >> routable locator IP address. I fully support that view that any DMM >> solution should consider hooks to external (non- mobility) protocols to >> optimize (D)MM operation and is well aligned with the methodology in our >> framework draft. >=20 > I don't think the MN's IP address (prefix) will necessarily be the identi= fier > of choice. Perhaps an NAI or other identifier authenticated at the time = of > access is the right one to use. In terms of routing/switching U-plane traffic to the MN's current point of = attachment (aka anchor ;-) it is the IP address that is used as key for a l= ocator lookup. These packets do not carry NAIs. In terms of authentication,= you are probably right. >=20 > It's good to have this discussion; once we pin down the interface between > Module I and the rest of the system we can work independently on the piec= es. Good. >=20 >=20 >>> II. Address allocation/management >>>=20 >>> This module lives in both the MN and the network. The MN maintains a >>> pool of addresses, each one topologically related to the point of >>> attachment at the time it was assigned. The MN should be made aware of >>> which of its addresses are currently on-link at its current attachment >>> point, courtesy of Module I. The MN should maintain information about >>> how it is using each address so that unused addresses can be released >>> and in-use addresses can have their leases renewed at the appropriate >>> times. Address allocation/deallocation should NOT be coupled to node >>> mobility. It should be possible to have a mobility event without >>> allocating a new address (to avoid excessive numbers of addresses being >>> allocated) and even if Module I cannot provide network-based relocation >>> of a prefix, mobility to an attachment point where an address is not >>> on-link SHOULD NOT trigger deallocation of the address, because the MN >>> might have a client- based mobility scheme that enables it to continue >>> using the address (Module III). Some mechanism to renew the lease on >>> the address from a remote location should be provided, such as >>> obtaining a global unicast IP address of a DHCP server. Security >>> considerations for such remote renewal need to be investigated and >>> addressed. >>=20 >> So, on-link addresses are routable addresses associated with the MN's >> current anchor, whereas other addresses (off-link?) are associated >> with the previous anchor (or point of attachment) and considered depreca= ted. >> Correct?=20 >=20 > I really dislike the term "anchor". It seems to imply there is a fixed=20 > point in the network through which the MN's traffic is flowing and is als= o > semantically linked to tunnel-based solutions. >=20 Yes,I understood your comment during today's session. > When I say "on-link" I mean the prefix is currently advertised in an RA > on the current link (in IPv6 terms). The degree to which it is topologic= ally > aggregateable may vary depending on how far the MN has moved. It may or > may not be marked as "deprecated" by the advertising AR; in any case, it= =20 > is available for use by ongoing sessions or possibly new sessions accordi= ng > to logic inside the MN. >=20 > Addresses that are not advertised on-link, if they are still needed, shou= ld > be supported with a client-based tunnel. >=20 >> Dependent on the solution for DMM, this IP address is not >> routable anymore if imported to the current anchor to enable IP >> address continuity or remains routable through the MN's previous >> anchor. In the latter case the MN may have multiple anchors which may >> have to be added to the address management module, at least in case of >> client-based mobility. >=20 > Again, don't like "anchor". Hopefully the above explanation tells you ho= w > I am defining my terms. Yes. >=20 >>> Module I must be provided with a list of prefixes currently allocated >>> to the MN. The database storing this information could be updated by >>> the network element that allocates the address (e.g., DHCP server) or >>> could be updated by the MN. A network element initiated update may be >>> more appropriate for an HSS-stored database, whereas an MN-initiated >>> update may be more appropriate for a DNS- based database. >>=20 >> Well, in general this is about a dynamic binding in a database between >> one or more IP addresses of the MN and associated locator(s). >> Important is that this can be something else than what is provided by >> Mobile IP protocols. And this makes sense, as it applies to the >> routing space above mobility anchor level (southbound to MM U-Plane >> function, or attachment point according to your terminology). >> Who updates the database is up to a particular solution. >=20 > Again, I think the binding is from some other identifier (like NAI) to > a set of currently allocated/assigned IP addresses. While there are=20 > mechanisms to allocate IP addresses using Mobile IP, I don't think they > necessarily will be used by DMM because most addresses should be=20 > topologically correct a the time they are assigned instead of being > routed through a home agent. >=20 Sure the NAI can be associated with the binding. I was referring to a bindi= ng between a continued address after relocation of a Point of attachment an= d a locator or other routing info to deliver a downlink packet to the MN's = current point of attachment. Example BGP resolves the MN's address into a p= er-host route and associated next hop. > Agree that database update details are a property of individual=20 Ok. Marco >=20 >>> III. An optional global, client-based mobility scheme >>>=20 >>> Any network-based mobility scheme will necessarily have a limited >>> scope. This is especially true in the DMM case because the Internet >>> attachment points are by definition close to the MN in the access >>> (visited) network. Consider a roaming mobile node with home network H >>> that attaches to visited network V1. It obtains DMM service from V1, >>> obtaining an IP address topologically routed from the Internet directly >>> to V1. Now consider this MN performing a handoff from V1 to another >>> visited network V2. V2 has a roaming agreement with H (otherwise the >>> MN would not be able to get service) but has absolutely no business >>> arrangement with V1. Therefore, it is impossible for the network-based >>> mobility scheme to support re-routing or tunneling the packets destined >>> to the original V1 address to network V2. We must therefore support >>> fall-back to a client-based OTT global mobility scheme, using the fact >>> that both V1 and V2 offer connectivity to the same Internet, if the MN >>> wants to keep using the address it got while connected to V1. >>>=20 >>> Allocation of a global mobility anchor should be coupled to allocation >>> of the address for which global mobility is needed. There are already >>> DHCP extensions to carry HA IP addresses which could be used for this >>> purpose. The MN-HA security association should also be bootstrapped at >>> this time, so that the establishment of security does not add latency >>> at the time the global mobility service is invoked. We need to >>> investigate whether the current DHCP extension provides the right kind >>> of HA identifier to the MN or whether a DNS name would be more helpful >>> in bootstrapping security. >>>=20 >>> The global mobility anchor may invoke Module I to get the HoA- >>> addressed packets delivered to itself before tunneling them to the MN's >>> CoA. The MN should make use of Module I for its CoA in its new visited >>> network to minimize the number of global mobility location update >>> messages it needs to send to the anchor point. >>>=20 >>>=20 >>> IV. Security >>>=20 >>> Module I depends on a secure network access control protocol to provide >>> an authenticated MN identity. Similarly, Module III requires >>> bootstrapping a security association between MN and HA. So far, the >>> AAA suite of protocols have been used for this purpose. However, it >>> may be possible to further optimize this process and unify the >>> credentials used by the various nodes if new solutions are >>> investigated. Eliminating the round-trip to the home AAA server would >>> dramatically improve the performance of network attachment and MN- HA >>> SA establishment. Making use of DNS-based public key credentials that >>> can be locally cached may allow the elimination of this round-trip and >>> improve the scalability of home network infrastructure. >>>=20 >>> These enhancements to security can be decoupled from the rest of the >>> architecture and investigated separately. >>>=20 >>>=20 >>>=20 >>>=20 >>> I think it's important for the DMM working group to investigate all 4 >>> of the above solution components, even though most people in the group >>> are probably focused on Module I for now. We need to understand how >>> the pieces will fit together into an overall system. To the extent we >>> need to make changes to MN implementation practices, we should publish >>> advice in Informational RFCs. To the extent we need to modify protocols >>> that are outside the scope of DMM, we should send requirements to other >>> working groups and encourage the work to get done. >>=20 >>=20 >> Makes sense to me. >=20 > Ok, good. Maybe if we can get agreement on the various pieces we can > arrive at an updated framework document. >=20 > -Pete >=20 >>=20 >> marco >>=20 >>>=20 >>>=20 >>> -- >>> 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 >>>=20 >>>=20 >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 >=20 From Peter.McCann@huawei.com Thu Aug 1 09:56:20 2013 Return-Path: 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 906E221E8117 for ; Thu, 1 Aug 2013 09:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, 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 RINZdpP5g3qU for ; Thu, 1 Aug 2013 09:56:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C798721E80BE for ; Thu, 1 Aug 2013 09:56:06 -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.5-GA FastPath queued) with ESMTP id AVQ47100; Thu, 01 Aug 2013 16:56:03 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 1 Aug 2013 17:55:26 +0100 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 1 Aug 2013 17:55:39 +0100 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.163]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Thu, 1 Aug 2013 09:55:33 -0700 From: Peter McCann To: Marco Liebsch Thread-Topic: Elements of a DMM Solution Thread-Index: Ac6NFTnvNwdJkIljSBKhE1ur31iYxgBKeN3gACPS1AAAAelJYQAAHGdw Date: Thu, 1 Aug 2013 16:55:32 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716F51868@dfweml512-mbx.china.huawei.com> References: <5963DDF1F751474D8DEEFDCDBEE43AE716F5138A@dfweml512-mbx.china.huawei.com> <69756203DDDDE64E987BC4F70B71A26D55310296@DAPHNIS.office.hd>, <5963DDF1F751474D8DEEFDCDBEE43AE716F51828@dfweml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] Elements of a DMM Solution X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 16:56:20 -0000 Hi, Marco, Marco Liebsch wrote: > Hi Pete, > please see inline. >=20 > On 01.08.2013, at 18:02, "Peter McCann" wrote: >=20 >> Hi, Marco, >>=20 >> Marco Liebsch wrote: >>> Hi Pete, >>>=20 >>> I support your proposal. Please see (so far brief) feedback inline. >>>=20 >>>> -----Original Message----- >>>> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf >>>> Of Peter McCann >>>> Sent: Dienstag, 30. Juli 2013 13:09 >>>> To: dmm@ietf.org >>>> Subject: [DMM] Elements of a DMM Solution >>>>=20 >>>> I think that the DMM work can be subdivided into a small number of >>>> "modules", each of which can be implemented in a number of different >>>> ways. >>>>=20 >>>>=20 >>>> I. Limited-scope (localized) network-based mobility scheme >>>>=20 >>>> This is probably what most people have in mind when they think of a >>>> DMM "protocol". This is the mechanism that gets packets to the >>>> current point of attachment. We have seen the following proposed as >>>> options for this module: >>>>=20 >>>> A. Something based on PMIP >>>> B. Something based on GTP >>>> C. Something based on a routing protocol (e.g., BGP) D. >>>> Something based on SDN We should be able to "plug in" any of the >>>> above solutions to an overall DMM framework. This module needs to be >>>> signaled when an MN attaches or changes its point of attachment. An >>>> identifier of the MN and an identifier of the attachment point should >>>> be provided in this signal. This module needs to interact with the >>>> address allocation/management module to obtain the set of IP prefixes >>>> currently in use by the mobile node, so that redirection/tunneling of >>>> packets destined to those prefixes can be set up. This may require a >>>> network- queryable database of prefixes that can be indexed by mobile >>>> node identifier. This database could be stored in something like an >>>> HSS or in a DNS server. >>>=20 >>> Yes, or an IP mobility anchor control plane function, or a registry >>> associated with an SDN controller, or.. something that can treat >>> the MN's IP address (prefix) as identifier and select an >>> appropriate routable locator IP address. I fully support that view >>> that any DMM solution should consider hooks to external (non- >>> mobility) protocols to optimize (D)MM operation and is well aligned >>> with the methodology in our framework draft. >>=20 >> I don't think the MN's IP address (prefix) will necessarily be the >> identifier of choice. Perhaps an NAI or other identifier >> authenticated at the time of access is the right one to use. >=20 > In terms of routing/switching U-plane traffic to the MN's current > point of attachment (aka anchor ;-) it is the IP address that is used > as key for a locator lookup. These packets do not carry NAIs. In terms > of authentication, you are probably right. Ah, but the lookup from one IP address to another that you refer to only happens when there is a tunnel or NAT binding. Routing-based solutions don't need this. The mapping I am talking about is from the authenticated MN identifier at the time it attaches or moves to an access router, to a set of IPs currently assigned to that MN. The Module I needs to find the set of addresses that the MN owns, and then decide which of those addresses it can serve with a network-based DMM by making them on-link, and setting up forwarding/tunnel/NAT/whatever state in the network to make that happen. >> It's good to have this discussion; once we pin down the interface >> between Module I and the rest of the system we can work >> independently >> on the pieces. >=20 > Good. >=20 >>=20 >>=20 >>>> II. Address allocation/management >>>>=20 >>>> This module lives in both the MN and the network. The MN maintains a >>>> pool of addresses, each one topologically related to the point of >>>> attachment at the time it was assigned. The MN should be made aware >>>> of which of its addresses are currently on-link at its current >>>> attachment point, courtesy of Module I. The MN should maintain >>>> information about how it is using each address so that unused >>>> addresses can be released and in-use addresses can have their leases >>>> renewed at the appropriate times. Address allocation/deallocation >>>> should NOT be coupled to node mobility. It should be possible to >>>> have a mobility event without allocating a new address (to avoid >>>> excessive numbers of addresses being allocated) and even if Module I >>>> cannot provide network-based relocation of a prefix, mobility to an >>>> attachment point where an address is not on-link SHOULD NOT trigger >>>> deallocation of the address, because the MN might have a client- >>>> based mobility scheme that enables it to continue using the address >>>> (Module III). Some mechanism to renew the lease on the address from a >>>> remote location should be provided, such as obtaining a global >>>> unicast IP address of a DHCP server. Security considerations for >>>> such remote renewal need to be investigated and addressed. >>>=20 >>> So, on-link addresses are routable addresses associated with the MN's >>> current anchor, whereas other addresses (off-link?) are associated >>> with the previous anchor (or point of attachment) and considered >>> deprecated. Correct? >>=20 >> I really dislike the term "anchor". It seems to imply there is a >> fixed point in the network through which the MN's traffic is flowing >> and is also semantically linked to tunnel-based solutions. >>=20 >=20 > Yes,I understood your comment during today's session. Do you think we can come up with a different term? It needs to refer to the point in the network that a given address would route to, if there were no special DMM state in the network modifying this forwarding. It shouldn'= t be semantically coupled to the path that packets take when the MN has moved away from this point and the retained address is no longer completely topologically aggregateable. >> When I say "on-link" I mean the prefix is currently advertised in an RA >> on the current link (in IPv6 terms). The degree to which it is >> topologically aggregateable may vary depending on how far the MN has >> moved. It may or may not be marked as "deprecated" by the advertising >> AR; in any case, it is available for use by ongoing sessions or >> possibly new sessions according to logic inside the MN. >>=20 >> Addresses that are not advertised on-link, if they are still needed, >> should be supported with a client-based tunnel. >>=20 >>> Dependent on the solution for DMM, this IP address is not routable >>> anymore if imported to the current anchor to enable IP address >>> continuity or remains routable through the MN's previous anchor. In >>> the latter case the MN may have multiple anchors which may have to be >>> added to the address management module, at least in case of >>> client-based mobility. >>=20 >> Again, don't like "anchor". Hopefully the above explanation tells you >> how I am defining my terms. >=20 > Yes. Ok. Maybe you can suggest a better term. >>>> Module I must be provided with a list of prefixes currently allocated >>>> to the MN. The database storing this information could be updated by >>>> the network element that allocates the address (e.g., DHCP server) or >>>> could be updated by the MN. A network element initiated update may >>>> be more appropriate for an HSS-stored database, whereas an >>>> MN-initiated update may be more appropriate for a DNS- > based database. >>>=20 >>> Well, in general this is about a dynamic binding in a database between >>> one or more IP addresses of the MN and associated locator(s). >>> Important is that this can be something else than what is provided by >>> Mobile IP protocols. And this makes sense, as it applies to the >>> routing space above mobility anchor level (southbound to MM U-Plane >>> function, or attachment point according to your terminology). Who >>> updates the database is up to a particular solution. >>=20 >> Again, I think the binding is from some other identifier (like NAI) to >> a set of currently allocated/assigned IP addresses. While there are >> mechanisms to allocate IP addresses using Mobile IP, I don't think they >> necessarily will be used by DMM because most addresses should be >> topologically correct a the time they are assigned instead of being >> routed through a home agent. >>=20 >=20 > Sure the NAI can be associated with the binding. I was referring to a > binding between a continued address after relocation of a Point of > attachment and a locator or other routing info to deliver a downlink > packet to the MN's current point of attachment. Example BGP resolves > the MN's address into a per-host route and associated next hop. Again, such a binding is only needed for NAT and tunnel-based redirection. A routing solution would just route the addresses according to its forwardi= ng tables. The part that is common to all solutions is figuring out which addresses ar= e owned by the MN and setting up state in the network to get the packets addr= essed to those addresses to the current point of attachment. >> Agree that database update details are a property of individual solution= s. >=20 > Ok. >=20 > Marco >=20 >=20 >>=20 >>>> III. An optional global, client-based mobility scheme >>>>=20 >>>> Any network-based mobility scheme will necessarily have a limited >>>> scope. This is especially true in the DMM case because the Internet >>>> attachment points are by definition close to the MN in the access >>>> (visited) network. Consider a roaming mobile node with home network >>>> H that attaches to visited network V1. It obtains DMM service from >>>> V1, obtaining an IP address topologically routed from the Internet >>>> directly to V1. Now consider this MN performing a handoff from V1 to >>>> another visited network V2. V2 has a roaming agreement with H >>>> (otherwise the MN would not be able to get service) but has >>>> absolutely no business arrangement with V1. Therefore, it is >>>> impossible for the network-based mobility scheme to support >>>> re-routing or tunneling the packets destined to the original V1 >>>> address to network V2. We must therefore support fall-back to a >>>> client-based OTT global mobility scheme, using the fact that both V1 >>>> and V2 offer connectivity to the same Internet, if the MN wants to >>>> keep using the address it got while connected to V1. >>>>=20 >>>> Allocation of a global mobility anchor should be coupled to >>>> allocation of the address for which global mobility is needed. There >>>> are already DHCP extensions to carry HA IP addresses which could be >>>> used for this purpose. The MN-HA security association should also be >>>> bootstrapped at this time, so that the establishment of security does >>>> not add latency at the time the global mobility service is invoked.=20 >>>> We need to investigate whether the current DHCP extension provides >>>> the right kind of HA identifier to the MN or whether a DNS name would >>>> be more helpful in bootstrapping security. >>>>=20 >>>> The global mobility anchor may invoke Module I to get the HoA- >>>> addressed packets delivered to itself before tunneling them to the >>>> MN's CoA. The MN should make use of Module I for its CoA in its >>>> new visited network to minimize the number of global mobility >>>> location update messages it needs to send to the anchor point. >>>>=20 >>>>=20 >>>> IV. Security >>>>=20 >>>> Module I depends on a secure network access control protocol to >>>> provide an authenticated MN identity. Similarly, Module III requires >>>> bootstrapping a security association between MN and HA. So far, the >>>> AAA suite of protocols have been used for this purpose. However, it >>>> may be possible to further optimize this process and unify the >>>> credentials used by the various nodes if new solutions are >>>> investigated. Eliminating the round-trip to the home AAA server >>>> would dramatically improve the performance of network attachment and >>>> MN- HA SA establishment. Making use of DNS-based public key >>>> credentials that can be locally cached may allow the elimination of >>>> this round-trip and improve the scalability of home network >>>> infrastructure. >>>>=20 >>>> These enhancements to security can be decoupled from the rest of the >>>> architecture and investigated separately. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> I think it's important for the DMM working group to investigate >>>> all >>>> 4 of the above solution components, even though most people in the >>>> group are probably focused on Module I for now. We need to >>>> understand how the pieces will fit together into an overall system. >>>> To the extent we need to make changes to MN implementation >>>> practices, we should publish advice in Informational RFCs. To the >>>> extent we need to modify protocols that are outside the scope of >>>> DMM, we should send requirements to other working groups and > encourage the work to get done. >>>=20 >>>=20 >>> Makes sense to me. >>=20 >> Ok, good. Maybe if we can get agreement on the various pieces we >> can arrive at an updated framework document. >>=20 >> -Pete >>=20 >>>=20 >>> marco >>>=20 >>>>=20 >>>>=20 >>>> -- >>>> 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 From ietf-secretariat-reply@ietf.org Thu Aug 1 03:32:43 2013 Return-Path: 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 1A3A621F90CC for ; Thu, 1 Aug 2013 03:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 VyEeA4MT3mgT for ; Thu, 1 Aug 2013 03:32:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E058C21F9F21 for ; Thu, 1 Aug 2013 03:32:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130801103225.9949.95300.idtracker@ietfa.amsl.com> Date: Thu, 01 Aug 2013 03:32:25 -0700 From: IETF Secretariat X-Mailman-Approved-At: Thu, 01 Aug 2013 16:16:40 -0700 Subject: [DMM] Milestones changed for dmm WG X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 10:32:43 -0000 Changed milestone "Evaluate the need for additional working group document(s) for extensions to fill the identified gaps.", resolved as "Done". Changed milestone "Submit I-D 'Solution Requirements' to the IESG for consideration as an Informational RFC.", set due date to October 2013 from January 2013. Changed milestone "Submit I-D 'Gap Analysis' to the IESG for consideration as an Informational RFC.", set due date to November 2013 from March 2013. Changed milestone "Evaluate the need for further work based on the identified gaps and revise the milestones and/or the charter of the group", set due date to November 2013 from March 2013. URL: http://datatracker.ietf.org/wg/dmm/charter/ From h.anthony.chan@huawei.com Fri Aug 2 01:25:33 2013 Return-Path: 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 4D7DD11E82B5 for ; Fri, 2 Aug 2013 01:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 bpKSM1az8Q9G for ; Fri, 2 Aug 2013 01:25:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 094D521E8271 for ; Fri, 2 Aug 2013 01:24:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUA42415; Fri, 02 Aug 2013 08:24:34 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 2 Aug 2013 09:23:58 +0100 Received: from SZXEML460-HUB.china.huawei.com (10.82.67.203) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 2 Aug 2013 09:24:13 +0100 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.202]) by szxeml460-hub.china.huawei.com ([10.82.67.203]) with mapi id 14.01.0323.007; Fri, 2 Aug 2013 16:24:10 +0800 From: h chan To: Brian Haberman , "dmm@ietf.org" Thread-Topic: [DMM] ticket #38 Thread-Index: AQHOjrnXTzflqTrDL0msVGWRcV/aRZmBjtKQ Date: Fri, 2 Aug 2013 08:24:09 +0000 Message-ID: <6E31144C030982429702B11D6746B98C3709F609@szxeml557-mbx.china.huawei.com> References: <517B198A.6020605@computer.org> <6E31144C030982429702B11D6746B98C3709F53B@szxeml557-mbx.china.huawei.com> <51FA55F9.1040109@innovationslab.net> In-Reply-To: <51FA55F9.1040109@innovationslab.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.131.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] ticket #38 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 08:25:42 -0000 X-List-Received-Date: Fri, 02 Aug 2013 08:25:42 -0000 X-List-Received-Date: Fri, 02 Aug 2013 08:25:42 -0000 I am uploading version 07 with the following: REQ1: Distributed processing IP mobility, network access and routing solutions provided by DMM MUST enable distributed processing for mobility management so that traffic does not need to traverse centrally deployed mobility anchors and thereby avoid non-optimal routes. (deleted IP session) REQ7: Multicast considerations DMM SHOULD consider multicast early so that solutions can be developed not only to provide IP mobility support when it is needed, but also to avoid network inefficiency issues in multicast traffic delivery (such as duplicate multicast subscriptions towards the downstream tunnel entities). The multicast solutions should therefore avoid restricting the management of all IP multicast traffic to a single host through a dedicated (tunnel) interface on multicast-capable access routers. (deleted IP multicast session) H Anthony Chan -----Original Message----- From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Brian= Haberman Sent: Thursday, August 01, 2013 2:35 PM To: dmm@ietf.org Subject: Re: [DMM] ticket #38 I agree with Charlie's request to move away from the term "session". It re= ally does not have much meaning in UDP-based applications. However, the te= rm "flow" does have some issues as well. Are we using the term "flow" the = way it is defined in RFC 5101? If not, then it needs to be defined in this= draft. Regards, Brian On 8/1/13 8:09 AM, h chan wrote: > Charles, > Is the following change from "IP multicast sessions" to "multicast flows"= okay? > > REQ7: Multicast: > Version 06: DMM SHOULD consider multicast early so that solutions can=20 > be developed not only to provide IP mobility to keep IP multicast session= s when it is needed, but also to avoid network inefficiency issues in multi= cast traffic delivery (such as duplicate multicast subscriptions towards th= e downstream tunnel entities). The multicast solutions should therefore avo= id restricting the management of all IP multicast traffic to a single host = through a dedicated (tunnel) interface on multicast-capable access routers. > > REQ7: Multicast: > Version 07: DMM SHOULD consider multicast early so that solutions can=20 > be developed not only to provide IP mobility to keep multicast flows when= it is needed, but also to avoid network inefficiency issues in multicast t= raffic delivery (such as duplicate multicast subscriptions towards the down= stream tunnel entities). The multicast solutions should therefore avoid res= tricting the management of all IP multicast traffic to a single host throug= h a dedicated (tunnel) interface on multicast-capable access routers. > > H Anthony Chan > > -----Original Message----- > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of=20 > Charles E. Perkins > Sent: Saturday, April 27, 2013 2:19 AM > To: dmm@ietf.org > Subject: [DMM] Editorial suggestions for=20 > draft-ietf-dmm-requirements-03 > > Hello folks, > > Here are some editorial suggestions for the document. > > Check for missing articles. For instance: > "Gateway selection mechanism" --> "A gateway selection mechanism" > > "is also taking the" --> "also takes" > > Delete "However" before "assigning". > > Delete "Issues such as" > > Delete "When demand exceeds capacity," or else explain why the benefits = are unavailable otherwise. > > "In particular, there is an increase in direct communications among > peers in the same geographical area." > --> there has always been such locality... in fact maybe less > now than previously. Otherwise, please provide a citat= ion. > > Delete "While deploying" > > "today's mobile networks, service providers face" --> > "Today's mobile networks present service providers with" > > Delete "more often than not," > > Delete "Therefore it is not uncommon to observe that" > > "ever-increasing" --> "unnecessary" > > "provided" --> "managed" > > "non-optimal" --> "unnecessary" > > Delete "Given this motivational background in this section," > > "address these problems": at this point in the document, the > problems have not been identified. As suggested earlie= r, > there should be a section devoted to listing the proble= ms, > and then a cross reference to that section could go her= e. > > "changing IP address" --> "locator IP address" > > Insert "The" before "Gateway GPRS Support Node" > > "respectively, act" --> "all act" > > "SAE" --> "EPC" > > "closeby" --> "nearby" > > Center figure 2. (and might as well center figure 1 too) > > "future flat IP-based" --> "flat IP-based" > (unwise to predict the future) > > "states the requirements as follows" --> > "identifies the followin= g requirements" > > "Distributed deployment" --> "Distributed processing" > ... also in "REQ1" > > "of IP sessions" --> "of some flows" > > "an optimal manner" --> "to avoid known bottlenecks" > > "This requirement addresses problems PS1, PS2, PS3, and PS4 in the > following." > ... the following ?what? > > "each MN therein" .... the MNs are not "in" the tunnel, and they are > not "in" the mobility a= nchor. > > "Centralized anchoring" --> "Centralized anchoring designs" > > "Distributing > the tunnel maintenance function and the mobility context > maintenance function among different network entities can > increase scalability." > --> only when the signaling protocol is properly desig= ned. > > "is to be inline" --> "conforms" > > "may need to interoperate with a network or mobile hosts/ > routers that do not support DMM protocols." > ... this is technically infeasible. > Suggested replacement: > "may need to co-exist with a network or mobile hosts/ > routers that do not support DMM protocols." > > Delete "The motivations of this requirement are" > > -- > Regards, > Charlie P. > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm From brian@innovationslab.net Fri Aug 2 01:42:31 2013 Return-Path: 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 201F011E82DB for ; Fri, 2 Aug 2013 01:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 jCTeiMUuTUke for ; Fri, 2 Aug 2013 01:42:25 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id A766B21E8308 for ; Fri, 2 Aug 2013 01:36:33 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 988238814D; Fri, 2 Aug 2013 01:36:32 -0700 (PDT) Received: from 10252091.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id D09A813680FF; Fri, 2 Aug 2013 01:36:31 -0700 (PDT) Message-ID: <51FB6F8D.2040605@innovationslab.net> Date: Fri, 02 Aug 2013 04:36:29 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: h chan References: <517B198A.6020605@computer.org> <6E31144C030982429702B11D6746B98C3709F53B@szxeml557-mbx.china.huawei.com> <51FA55F9.1040109@innovationslab.net> <6E31144C030982429702B11D6746B98C3709F609@szxeml557-mbx.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C3709F609@szxeml557-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dmm@ietf.org" Subject: Re: [DMM] ticket #38 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 08:42:31 -0000 I am fine with this text. Brian On 8/2/13 4:24 AM, h chan wrote: > I am uploading version 07 with the following: > > REQ1: Distributed processing > > IP mobility, network access and routing solutions provided by > DMM MUST enable distributed processing for mobility management > so that traffic does not need to traverse centrally deployed > mobility anchors and thereby avoid non-optimal routes. > > (deleted IP session) > > REQ7: Multicast considerations > > DMM SHOULD consider multicast early so that solutions can be > developed not only to provide IP mobility support when it is > needed, but also to avoid network inefficiency issues in > multicast traffic delivery (such as duplicate multicast > subscriptions towards the downstream tunnel entities). The > multicast solutions should therefore avoid restricting the > management of all IP multicast traffic to a single host > through a dedicated (tunnel) interface on multicast-capable > access routers. > > (deleted IP multicast session) > > H Anthony Chan > > -----Original Message----- > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Brian Haberman > Sent: Thursday, August 01, 2013 2:35 PM > To: dmm@ietf.org > Subject: Re: [DMM] ticket #38 > > I agree with Charlie's request to move away from the term "session". It really does not have much meaning in UDP-based applications. However, the term "flow" does have some issues as well. Are we using the term "flow" the way it is defined in RFC 5101? If not, then it needs to be defined in this draft. > > Regards, > Brian > > On 8/1/13 8:09 AM, h chan wrote: >> Charles, >> Is the following change from "IP multicast sessions" to "multicast flows" okay? >> >> REQ7: Multicast: >> Version 06: DMM SHOULD consider multicast early so that solutions can >> be developed not only to provide IP mobility to keep IP multicast sessions when it is needed, but also to avoid network inefficiency issues in multicast traffic delivery (such as duplicate multicast subscriptions towards the downstream tunnel entities). The multicast solutions should therefore avoid restricting the management of all IP multicast traffic to a single host through a dedicated (tunnel) interface on multicast-capable access routers. >> >> REQ7: Multicast: >> Version 07: DMM SHOULD consider multicast early so that solutions can >> be developed not only to provide IP mobility to keep multicast flows when it is needed, but also to avoid network inefficiency issues in multicast traffic delivery (such as duplicate multicast subscriptions towards the downstream tunnel entities). The multicast solutions should therefore avoid restricting the management of all IP multicast traffic to a single host through a dedicated (tunnel) interface on multicast-capable access routers. >> >> H Anthony Chan >> >> -----Original Message----- >> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of >> Charles E. Perkins >> Sent: Saturday, April 27, 2013 2:19 AM >> To: dmm@ietf.org >> Subject: [DMM] Editorial suggestions for >> draft-ietf-dmm-requirements-03 >> >> Hello folks, >> >> Here are some editorial suggestions for the document. >> >> Check for missing articles. For instance: >> "Gateway selection mechanism" --> "A gateway selection mechanism" >> >> "is also taking the" --> "also takes" >> >> Delete "However" before "assigning". >> >> Delete "Issues such as" >> >> Delete "When demand exceeds capacity," or else explain why the benefits are unavailable otherwise. >> >> "In particular, there is an increase in direct communications among >> peers in the same geographical area." >> --> there has always been such locality... in fact maybe less >> now than previously. Otherwise, please provide a citation. >> >> Delete "While deploying" >> >> "today's mobile networks, service providers face" --> >> "Today's mobile networks present service providers with" >> >> Delete "more often than not," >> >> Delete "Therefore it is not uncommon to observe that" >> >> "ever-increasing" --> "unnecessary" >> >> "provided" --> "managed" >> >> "non-optimal" --> "unnecessary" >> >> Delete "Given this motivational background in this section," >> >> "address these problems": at this point in the document, the >> problems have not been identified. As suggested earlier, >> there should be a section devoted to listing the problems, >> and then a cross reference to that section could go here. >> >> "changing IP address" --> "locator IP address" >> >> Insert "The" before "Gateway GPRS Support Node" >> >> "respectively, act" --> "all act" >> >> "SAE" --> "EPC" >> >> "closeby" --> "nearby" >> >> Center figure 2. (and might as well center figure 1 too) >> >> "future flat IP-based" --> "flat IP-based" >> (unwise to predict the future) >> >> "states the requirements as follows" --> >> "identifies the following requirements" >> >> "Distributed deployment" --> "Distributed processing" >> ... also in "REQ1" >> >> "of IP sessions" --> "of some flows" >> >> "an optimal manner" --> "to avoid known bottlenecks" >> >> "This requirement addresses problems PS1, PS2, PS3, and PS4 in the >> following." >> ... the following ?what? >> >> "each MN therein" .... the MNs are not "in" the tunnel, and they are >> not "in" the mobility anchor. >> >> "Centralized anchoring" --> "Centralized anchoring designs" >> >> "Distributing >> the tunnel maintenance function and the mobility context >> maintenance function among different network entities can >> increase scalability." >> --> only when the signaling protocol is properly designed. >> >> "is to be inline" --> "conforms" >> >> "may need to interoperate with a network or mobile hosts/ >> routers that do not support DMM protocols." >> ... this is technically infeasible. >> Suggested replacement: >> "may need to co-exist with a network or mobile hosts/ >> routers that do not support DMM protocols." >> >> Delete "The motivations of this requirement are" >> >> -- >> Regards, >> Charlie P. >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > From satoru.matsushima@gmail.com Fri Aug 2 01:47:30 2013 Return-Path: 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 8FF3611E82CF for ; Fri, 2 Aug 2013 01:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 inzpMs3mos8J for ; Fri, 2 Aug 2013 01:47:30 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1EB11E82CC for ; Fri, 2 Aug 2013 01:47:29 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id wz12so435884pbc.39 for ; Fri, 02 Aug 2013 01:47:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=39mZpATFpq1BztsBqdo/KxH/Er52YC4s8+YzFywXa2A=; b=f0jV3pQAYO0J5yJo7/GhOAIMdMd8PuM4MUF2PrLU1hQug2U+h/vCESDn48Xlw5FtC0 I9Y9ryGZqMq32ZaPypXi2oR2CTc8eEpiclE6PmLdNBddwCuCfZM3uyvPVeovwy2laLSK NtLzZcW0VI7LKOLJEgJARfgLdqIAfIjQs6PKgSRblkFoUbW0GXdE3OWm1ph05Mtld4sD UAXpkV9bfs9gOHxNkjoUNj02DzCfnwoRYQVKhgROtiHBDD0mQ7alNgnidG2JCKjW0BZv QRsi9RYu2jz0BjNGQPI6rkzmMfSlusNMwdeGs8WgQ4kH5qHJ8y1ih1oNoDHQYCZeZw/I AOyA== X-Received: by 10.68.189.36 with SMTP id gf4mr6608613pbc.27.1375433246250; Fri, 02 Aug 2013 01:47:26 -0700 (PDT) Received: from dhcp-57a7.meeting.ietf.org (dhcp-57a7.meeting.ietf.org. [130.129.87.167]) by mx.google.com with ESMTPSA id sz6sm7919812pab.5.2013.08.02.01.47.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 Aug 2013 01:47:24 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Satoru Matsushima In-Reply-To: Date: Fri, 2 Aug 2013 10:47:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <53BF9008-CB4D-41E0-B524-EDAA6506D521@gmail.com> References: To: Basavaraj Patil X-Mailer: Apple Mail (2.1508) Cc: draft-matsushima-stateless-uplane-vepc@tools.ietf.org, dmm@ietf.org Subject: Re: [DMM] Comments on I-D: draft-matsushima-stateless-uplane-vepc X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 08:47:30 -0000 Hi Raj, Thanks for your comments and feedback. It's very helpful for us. In particular as Ryuji presented yesterday, BGP scalability and = performance should be investigated about the reality of current deployed systems. One example data in our uploaded slide shows the scalability and the = performance of=20 existing BGP implementation, but we need to continue to study on that.=20= Best regards, --satoru On 2013/07/26, at 23:06, Basavaraj Patil wrote: >=20 > Hi Ryuji, >=20 > Good to see a new approach to mobility for the evolved packet core > architecture. At the very high level it is using standard mobility > signaling but then enabling seamless mobility (with session continuity > etc.) without the need for tunnelling the user plane. =20 >=20 > Comments: >=20 > - The benefits of moving the mobility functions (MME/SGW/PGW) to the > cloud are very valid. Operators have a much greater degree of > flexibility in terms of capacity and can add or shrink depending on > the requirements and this allow for deployments that scale with > growth of subscribers, traffic etc. It also allows operators to be > decoupled from specific vendors of the mobility applicances (but > instead will have to rely on vEPC providers). >=20 > - I wonder if there are any examples or research papers showing the > implementation of EPC functions such as MME, S/PGW on a hypervisor. >=20 > - It is crtitical that the functions deployed in the NFV are > interoperable and hence the need to have specifications. >=20 > - The intent of using BGP for routing user plane traffic is > interesting. How about the scalability aspect? Have you done any > studies on this given that an EPC could be serving many millions of > nodes. >=20 > - What about the handover performance? Since the EPC-E router needs to > be updated with the new address, does that affect HO performance for > real-time applications? >=20 > - Backward compatibility will be essential in order to allow for > operators to deploy a new architecture like the vEPC while allowing > the ability to interwork or roam in networks that do not have the > same capability.=20 >=20 > The proposal looks promising and worth working on in the IETF. >=20 > -Raj >=20 > --=20 > Basavaraj Patil > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From internet-drafts@ietf.org Fri Aug 2 01:47:32 2013 Return-Path: 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 BFDBC11E82F5; Fri, 2 Aug 2013 01:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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+pwrXP464yo; Fri, 2 Aug 2013 01:47:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A83BF11E82D9; Fri, 2 Aug 2013 01:47:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130802084730.8952.24568.idtracker@ietfa.amsl.com> Date: Fri, 02 Aug 2013 01:47:30 -0700 Cc: dmm@ietf.org Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 08:47:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Distributed Mobility Management Working G= roup of the IETF. Title : Requirements for Distributed Mobility Management Author(s) : H Anthony Chan Dapeng Liu Pierrick Seite Hidetoshi Yokota Jouni Korhonen Filename : draft-ietf-dmm-requirements-07.txt Pages : 19 Date : 2013-08-02 Abstract: This document defines the requirements for Distributed Mobility Management (DMM) in IPv6 deployments. The hierarchical structure in traditional wireless networks has led to deployment models which are in practice centralized. Mobility management with logically centralized mobility anchoring in current mobile networks is prone to suboptimal routing and raises scalability issues. Such centralized functions can lead to single points of failure and inevitably introduce longer delays and higher signaling loads for network operations related to mobility management. The objective is to enhance mobility management in order to meet the primary goals in network evolution, i.e., improve scalability, avoid single points of failure, enable transparent mobility support to upper layers only when needed, and so on. Distributed mobility management must be secure and may co-exist with existing network deployments and end hosts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dmm-requirements-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dmm-requirements-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jouni.nospam@gmail.com Fri Aug 2 02:03:04 2013 Return-Path: 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 94EAE11E831E for ; Fri, 2 Aug 2013 02:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, 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 JOlScyjcrJh5 for ; Fri, 2 Aug 2013 02:02:57 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id B199C11E82F0 for ; Fri, 2 Aug 2013 01:56:48 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id kq13so438170pab.39 for ; Fri, 02 Aug 2013 01:56:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Va1nl+HCEJRBcIc0p292nJ+RFyAaMEPuCtnOuBZTLrA=; b=pPQGy9jHkrQ7Tldp3ehCcUuYeVHHuNo8rMLcsMSGKq8p4eM7oEnrjHrTGQ6wf/R/FD baNA8+9i01QeBJTmKRCCGAk3Wf0ZH5SzcI+69X5qgMQb/w5mdAI0lPGBeGkkQfswhCoO yy9ZCHzXd5gv0dJ0Omt6t22eSoeXXwdQYG64sHR9ed4pmB3EB7KdRUY6S02yLZpKV/xP KqvLFT6vWsu3PLigvQZhF6fCvwI8bN3UQy19mNq7Bw2Fk/7WgrY8IahRNOP7+TGdwtWz RFFvFOFshvDNO5+Q3HXi+r8otaS+VJM1ynUAHKzmFwxNMwLJmb9pmc/0YS6c64JxEVau ZNFw== X-Received: by 10.68.242.105 with SMTP id wp9mr6437263pbc.153.1375433793352; Fri, 02 Aug 2013 01:56:33 -0700 (PDT) Received: from ?IPv6:2001:df8::80:94aa:d2bc:f5eb:f76d? ([2001:df8:0:80:94aa:d2bc:f5eb:f76d]) by mx.google.com with ESMTPSA id ot4sm9265556pac.17.2013.08.02.01.56.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 Aug 2013 01:56:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: <6E31144C030982429702B11D6746B98C3709F609@szxeml557-mbx.china.huawei.com> Date: Fri, 2 Aug 2013 11:56:27 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <48058EDB-F2FB-4243-BD62-84F6CB063AD0@gmail.com> References: <517B198A.6020605@computer.org> <6E31144C030982429702B11D6746B98C3709F53B@szxeml557-mbx.china.huawei.com> <51FA55F9.1040109@innovationslab.net> <6E31144C030982429702B11D6746B98C3709F609@szxeml557-mbx.china.huawei.com> To: h chan X-Mailer: Apple Mail (2.1508) Cc: "dmm@ietf.org" Subject: Re: [DMM] ticket #38 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 09:03:06 -0000 Looks OK to me. - Jouni On Aug 2, 2013, at 11:24 AM, h chan wrote: > I am uploading version 07 with the following: >=20 > REQ1: Distributed processing >=20 > IP mobility, network access and routing solutions provided by > DMM MUST enable distributed processing for mobility = management > so that traffic does not need to traverse centrally deployed > mobility anchors and thereby avoid non-optimal routes. >=20 > (deleted IP session) >=20 > REQ7: Multicast considerations >=20 > DMM SHOULD consider multicast early so that solutions can be > developed not only to provide IP mobility support when it is > needed, but also to avoid network inefficiency issues in > multicast traffic delivery (such as duplicate multicast > subscriptions towards the downstream tunnel entities). The > multicast solutions should therefore avoid restricting the > management of all IP multicast traffic to a single host > through a dedicated (tunnel) interface on multicast-capable > access routers. >=20 > (deleted IP multicast session) >=20 > H Anthony Chan >=20 > -----Original Message----- > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of = Brian Haberman > Sent: Thursday, August 01, 2013 2:35 PM > To: dmm@ietf.org > Subject: Re: [DMM] ticket #38 >=20 > I agree with Charlie's request to move away from the term "session". = It really does not have much meaning in UDP-based applications. = However, the term "flow" does have some issues as well. Are we using = the term "flow" the way it is defined in RFC 5101? If not, then it = needs to be defined in this draft. >=20 > Regards, > Brian >=20 > On 8/1/13 8:09 AM, h chan wrote: >> Charles, >> Is the following change from "IP multicast sessions" to "multicast = flows" okay? >>=20 >> REQ7: Multicast: >> Version 06: DMM SHOULD consider multicast early so that solutions can=20= >> be developed not only to provide IP mobility to keep IP multicast = sessions when it is needed, but also to avoid network inefficiency = issues in multicast traffic delivery (such as duplicate multicast = subscriptions towards the downstream tunnel entities). The multicast = solutions should therefore avoid restricting the management of all IP = multicast traffic to a single host through a dedicated (tunnel) = interface on multicast-capable access routers. >>=20 >> REQ7: Multicast: >> Version 07: DMM SHOULD consider multicast early so that solutions can=20= >> be developed not only to provide IP mobility to keep multicast flows = when it is needed, but also to avoid network inefficiency issues in = multicast traffic delivery (such as duplicate multicast subscriptions = towards the downstream tunnel entities). The multicast solutions should = therefore avoid restricting the management of all IP multicast traffic = to a single host through a dedicated (tunnel) interface on = multicast-capable access routers. >>=20 >> H Anthony Chan >>=20 >> -----Original Message----- >> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of=20= >> Charles E. Perkins >> Sent: Saturday, April 27, 2013 2:19 AM >> To: dmm@ietf.org >> Subject: [DMM] Editorial suggestions for=20 >> draft-ietf-dmm-requirements-03 >>=20 >> Hello folks, >>=20 >> Here are some editorial suggestions for the document. >>=20 >> Check for missing articles. For instance: >> "Gateway selection mechanism" --> "A gateway selection mechanism" >>=20 >> "is also taking the" --> "also takes" >>=20 >> Delete "However" before "assigning". >>=20 >> Delete "Issues such as" >>=20 >> Delete "When demand exceeds capacity," or else explain why the = benefits are unavailable otherwise. >>=20 >> "In particular, there is an increase in direct communications among >> peers in the same geographical area." >> --> there has always been such locality... in fact maybe = less >> now than previously. Otherwise, please provide a = citation. >>=20 >> Delete "While deploying" >>=20 >> "today's mobile networks, service providers face" --> >> "Today's mobile networks present service providers with" >>=20 >> Delete "more often than not," >>=20 >> Delete "Therefore it is not uncommon to observe that" >>=20 >> "ever-increasing" --> "unnecessary" >>=20 >> "provided" --> "managed" >>=20 >> "non-optimal" --> "unnecessary" >>=20 >> Delete "Given this motivational background in this section," >>=20 >> "address these problems": at this point in the document, the >> problems have not been identified. As suggested = earlier, >> there should be a section devoted to listing the = problems, >> and then a cross reference to that section could go = here. >>=20 >> "changing IP address" --> "locator IP address" >>=20 >> Insert "The" before "Gateway GPRS Support Node" >>=20 >> "respectively, act" --> "all act" >>=20 >> "SAE" --> "EPC" >>=20 >> "closeby" --> "nearby" >>=20 >> Center figure 2. (and might as well center figure 1 too) >>=20 >> "future flat IP-based" --> "flat IP-based" >> (unwise to predict the future) >>=20 >> "states the requirements as follows" --> >> "identifies the = following requirements" >>=20 >> "Distributed deployment" --> "Distributed processing" >> ... also in "REQ1" >>=20 >> "of IP sessions" --> "of some flows" >>=20 >> "an optimal manner" --> "to avoid known bottlenecks" >>=20 >> "This requirement addresses problems PS1, PS2, PS3, and PS4 in the >> following." >> ... the following ?what? >>=20 >> "each MN therein" .... the MNs are not "in" the tunnel, and they are >> not "in" the = mobility anchor. >>=20 >> "Centralized anchoring" --> "Centralized anchoring designs" >>=20 >> "Distributing >> the tunnel maintenance function and the mobility context >> maintenance function among different network entities can >> increase scalability." >> --> only when the signaling protocol is properly = designed. >>=20 >> "is to be inline" --> "conforms" >>=20 >> "may need to interoperate with a network or mobile hosts/ >> routers that do not support DMM protocols." >> ... this is technically infeasible. >> Suggested replacement: >> "may need to co-exist with a network or mobile hosts/ >> routers that do not support DMM protocols." >>=20 >> Delete "The motivations of this requirement are" >>=20 >> -- >> Regards, >> Charlie P. >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >>=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From seiljeon@av.it.pt Fri Aug 2 02:09:49 2013 Return-Path: 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 C57E211E8325 for ; Fri, 2 Aug 2013 02:09:48 -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=[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 6W-GcEAau45y for ; Fri, 2 Aug 2013 02:09:43 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 530F621F8616 for ; Fri, 2 Aug 2013 02:05:53 -0700 (PDT) Received: from [192.168.20.190] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 70410828; Fri, 02 Aug 2013 10:05:39 +0100 From: "Seil Jeon" To: "'h chan'" References: <517B198A.6020605@computer.org> <6E31144C030982429702B11D6746B98C3709F53B@szxeml557-mbx.china.huawei.com> <51FA55F9.1040109@innovationslab.net> <6E31144C030982429702B11D6746B98C3709F609@szxeml557-mbx.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C3709F609@szxeml557-mbx.china.huawei.com> Date: Fri, 2 Aug 2013 10:05:40 +0100 Message-ID: <001401ce8f5f$76744700$635cd500$@av.it.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQN+sjcz9f41bjgO2N1RQGLIZol05wF4vftIAe0hYuABySYzDZX33O0A Content-Language: ko Cc: dmm@ietf.org Subject: Re: [DMM] ticket #38 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 09:09:49 -0000 Hi Anthony, I agree on the changed REQ1 title from distributed deployment to distributed processing, in the sense that the main points in DMM lies on how effectively DMM can distribute workload processing concentrated at single anchor. If my sense is right, looking at the text, "~ so that traffic does not need to traverse ... avoid non-optimal routes." doesn't seem to fit in well with the title. If we say "distributed processing", it has a meaning for load balancing, which can be implemented in a centralized mobility management. In conclusion, "distributed processing" and "optimal routes" come to me as two different subjects. The latter can be achieved through the former or in CMM. My opinion is not to get back to the previous title, but we need to distinguish them clearly. Regards, Seil -----Original Message----- From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of h chan Sent: Friday, August 02, 2013 9:24 AM To: Brian Haberman; dmm@ietf.org Subject: Re: [DMM] ticket #38 I am uploading version 07 with the following: REQ1: Distributed processing IP mobility, network access and routing solutions provided by DMM MUST enable distributed processing for mobility management so that traffic does not need to traverse centrally deployed mobility anchors and thereby avoid non-optimal routes. (deleted IP session) REQ7: Multicast considerations DMM SHOULD consider multicast early so that solutions can be developed not only to provide IP mobility support when it is needed, but also to avoid network inefficiency issues in multicast traffic delivery (such as duplicate multicast subscriptions towards the downstream tunnel entities). The multicast solutions should therefore avoid restricting the management of all IP multicast traffic to a single host through a dedicated (tunnel) interface on multicast-capable access routers. (deleted IP multicast session) H Anthony Chan -----Original Message----- From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Brian Haberman Sent: Thursday, August 01, 2013 2:35 PM To: dmm@ietf.org Subject: Re: [DMM] ticket #38 I agree with Charlie's request to move away from the term "session". It really does not have much meaning in UDP-based applications. However, the term "flow" does have some issues as well. Are we using the term "flow" the way it is defined in RFC 5101? If not, then it needs to be defined in this draft. Regards, Brian On 8/1/13 8:09 AM, h chan wrote: > Charles, > Is the following change from "IP multicast sessions" to "multicast flows" okay? > > REQ7: Multicast: > Version 06: DMM SHOULD consider multicast early so that solutions can > be developed not only to provide IP mobility to keep IP multicast sessions when it is needed, but also to avoid network inefficiency issues in multicast traffic delivery (such as duplicate multicast subscriptions towards the downstream tunnel entities). The multicast solutions should therefore avoid restricting the management of all IP multicast traffic to a single host through a dedicated (tunnel) interface on multicast-capable access routers. > > REQ7: Multicast: > Version 07: DMM SHOULD consider multicast early so that solutions can > be developed not only to provide IP mobility to keep multicast flows when it is needed, but also to avoid network inefficiency issues in multicast traffic delivery (such as duplicate multicast subscriptions towards the downstream tunnel entities). The multicast solutions should therefore avoid restricting the management of all IP multicast traffic to a single host through a dedicated (tunnel) interface on multicast-capable access routers. > > H Anthony Chan > > -----Original Message----- > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of > Charles E. Perkins > Sent: Saturday, April 27, 2013 2:19 AM > To: dmm@ietf.org > Subject: [DMM] Editorial suggestions for > draft-ietf-dmm-requirements-03 > > Hello folks, > > Here are some editorial suggestions for the document. > > Check for missing articles. For instance: > "Gateway selection mechanism" --> "A gateway selection mechanism" > > "is also taking the" --> "also takes" > > Delete "However" before "assigning". > > Delete "Issues such as" > > Delete "When demand exceeds capacity," or else explain why the benefits are unavailable otherwise. > > "In particular, there is an increase in direct communications among > peers in the same geographical area." > --> there has always been such locality... in fact maybe less > now than previously. Otherwise, please provide a citation. > > Delete "While deploying" > > "today's mobile networks, service providers face" --> > "Today's mobile networks present service providers with" > > Delete "more often than not," > > Delete "Therefore it is not uncommon to observe that" > > "ever-increasing" --> "unnecessary" > > "provided" --> "managed" > > "non-optimal" --> "unnecessary" > > Delete "Given this motivational background in this section," > > "address these problems": at this point in the document, the > problems have not been identified. As suggested earlier, > there should be a section devoted to listing the problems, > and then a cross reference to that section could go here. > > "changing IP address" --> "locator IP address" > > Insert "The" before "Gateway GPRS Support Node" > > "respectively, act" --> "all act" > > "SAE" --> "EPC" > > "closeby" --> "nearby" > > Center figure 2. (and might as well center figure 1 too) > > "future flat IP-based" --> "flat IP-based" > (unwise to predict the future) > > "states the requirements as follows" --> > "identifies the following requirements" > > "Distributed deployment" --> "Distributed processing" > ... also in "REQ1" > > "of IP sessions" --> "of some flows" > > "an optimal manner" --> "to avoid known bottlenecks" > > "This requirement addresses problems PS1, PS2, PS3, and PS4 in the > following." > ... the following ?what? > > "each MN therein" .... the MNs are not "in" the tunnel, and they are > not "in" the mobility anchor. > > "Centralized anchoring" --> "Centralized anchoring designs" > > "Distributing > the tunnel maintenance function and the mobility context > maintenance function among different network entities can > increase scalability." > --> only when the signaling protocol is properly designed. > > "is to be inline" --> "conforms" > > "may need to interoperate with a network or mobile hosts/ > routers that do not support DMM protocols." > ... this is technically infeasible. > Suggested replacement: > "may need to co-exist with a network or mobile hosts/ > routers that do not support DMM protocols." > > Delete "The motivations of this requirement are" > > -- > Regards, > Charlie P. > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm From charliep@computer.org Fri Aug 2 02:11:02 2013 Return-Path: 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 9125511E8342 for ; Fri, 2 Aug 2013 02:11:02 -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] 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 5K1wD0608HZ7 for ; Fri, 2 Aug 2013 02:10:56 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9D50811E8369 for ; Fri, 2 Aug 2013 02:08:20 -0700 (PDT) Received: from [130.129.16.71] by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1V5BLM-0008Sz-Fj; Fri, 02 Aug 2013 05:08:16 -0400 Message-ID: <51FB76F3.1040908@computer.org> Date: Fri, 02 Aug 2013 02:08:03 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: h chan References: <517B198A.6020605@computer.org><6E31144C030982429702B11D6746B98C3709F53B@szxeml557-mbx.china.huawei.com><51FA55F9.1040109@innovationslab.net> <6E31144C030982429702B11D6746B98C3709F609@szxeml557-mbx.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C3709F609@szxeml557-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86a550ffcdfa05b5c891fc9db89f0ef500350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.16.71 Cc: dmm@ietf.org Subject: Re: [DMM] ticket #38 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 09:11:02 -0000 Hello Anthony, I think the revised text looks very good, and resolves the issue. Regards, Charlie P. On 8/2/2013 1:24 AM, h chan wrote: > I am uploading version 07 with the following: > > REQ1: Distributed processing > > IP mobility, network access and routing solutions provided by > DMM MUST enable distributed processing for mobility management > so that traffic does not need to traverse centrally deployed > mobility anchors and thereby avoid non-optimal routes. > > (deleted IP session) > > REQ7: Multicast considerations > > DMM SHOULD consider multicast early so that solutions can be > developed not only to provide IP mobility support when it is > needed, but also to avoid network inefficiency issues in > multicast traffic delivery (such as duplicate multicast > subscriptions towards the downstream tunnel entities). The > multicast solutions should therefore avoid restricting the > management of all IP multicast traffic to a single host > through a dedicated (tunnel) interface on multicast-capable > access routers. > > (deleted IP multicast session) > > H Anthony Chan > > -----Original Message----- > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Brian Haberman > Sent: Thursday, August 01, 2013 2:35 PM > To: dmm@ietf.org > Subject: Re: [DMM] ticket #38 > > I agree with Charlie's request to move away from the term "session". It really does not have much meaning in UDP-based applications. However, the term "flow" does have some issues as well. Are we using the term "flow" the way it is defined in RFC 5101? If not, then it needs to be defined in this draft. > > Regards, > Brian > > On 8/1/13 8:09 AM, h chan wrote: >> Charles, >> Is the following change from "IP multicast sessions" to "multicast flows" okay? >> >> REQ7: Multicast: >> Version 06: DMM SHOULD consider multicast early so that solutions can >> be developed not only to provide IP mobility to keep IP multicast sessions when it is needed, but also to avoid network inefficiency issues in multicast traffic delivery (such as duplicate multicast subscriptions towards the downstream tunnel entities). The multicast solutions should therefore avoid restricting the management of all IP multicast traffic to a single host through a dedicated (tunnel) interface on multicast-capable access routers. >> >> REQ7: Multicast: >> Version 07: DMM SHOULD consider multicast early so that solutions can >> be developed not only to provide IP mobility to keep multicast flows when it is needed, but also to avoid network inefficiency issues in multicast traffic delivery (such as duplicate multicast subscriptions towards the downstream tunnel entities). The multicast solutions should therefore avoid restricting the management of all IP multicast traffic to a single host through a dedicated (tunnel) interface on multicast-capable access routers. >> >> H Anthony Chan >> >> -----Original Message----- >> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of >> Charles E. Perkins >> Sent: Saturday, April 27, 2013 2:19 AM >> To: dmm@ietf.org >> Subject: [DMM] Editorial suggestions for >> draft-ietf-dmm-requirements-03 >> >> Hello folks, >> >> Here are some editorial suggestions for the document. >> >> Check for missing articles. For instance: >> "Gateway selection mechanism" --> "A gateway selection mechanism" >> >> "is also taking the" --> "also takes" >> >> Delete "However" before "assigning". >> >> Delete "Issues such as" >> >> Delete "When demand exceeds capacity," or else explain why the benefits are unavailable otherwise. >> >> "In particular, there is an increase in direct communications among >> peers in the same geographical area." >> --> there has always been such locality... in fact maybe less >> now than previously. Otherwise, please provide a citation. >> >> Delete "While deploying" >> >> "today's mobile networks, service providers face" --> >> "Today's mobile networks present service providers with" >> >> Delete "more often than not," >> >> Delete "Therefore it is not uncommon to observe that" >> >> "ever-increasing" --> "unnecessary" >> >> "provided" --> "managed" >> >> "non-optimal" --> "unnecessary" >> >> Delete "Given this motivational background in this section," >> >> "address these problems": at this point in the document, the >> problems have not been identified. As suggested earlier, >> there should be a section devoted to listing the problems, >> and then a cross reference to that section could go here. >> >> "changing IP address" --> "locator IP address" >> >> Insert "The" before "Gateway GPRS Support Node" >> >> "respectively, act" --> "all act" >> >> "SAE" --> "EPC" >> >> "closeby" --> "nearby" >> >> Center figure 2. (and might as well center figure 1 too) >> >> "future flat IP-based" --> "flat IP-based" >> (unwise to predict the future) >> >> "states the requirements as follows" --> >> "identifies the following requirements" >> >> "Distributed deployment" --> "Distributed processing" >> ... also in "REQ1" >> >> "of IP sessions" --> "of some flows" >> >> "an optimal manner" --> "to avoid known bottlenecks" >> >> "This requirement addresses problems PS1, PS2, PS3, and PS4 in the >> following." >> ... the following ?what? >> >> "each MN therein" .... the MNs are not "in" the tunnel, and they are >> not "in" the mobility anchor. >> >> "Centralized anchoring" --> "Centralized anchoring designs" >> >> "Distributing >> the tunnel maintenance function and the mobility context >> maintenance function among different network entities can >> increase scalability." >> --> only when the signaling protocol is properly designed. >> >> "is to be inline" --> "conforms" >> >> "may need to interoperate with a network or mobile hosts/ >> routers that do not support DMM protocols." >> ... this is technically infeasible. >> Suggested replacement: >> "may need to co-exist with a network or mobile hosts/ >> routers that do not support DMM protocols." >> >> Delete "The motivations of this requirement are" >> >> -- >> Regards, >> Charlie P. >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > -- Regards, Charlie P. From jouni.nospam@gmail.com Fri Aug 2 03:01:11 2013 Return-Path: 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 8807B11E82C9 for ; Fri, 2 Aug 2013 03:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, 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 w-+VEWTvz-Ox for ; Fri, 2 Aug 2013 03:01:10 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE1E21E8269 for ; Fri, 2 Aug 2013 03:00:59 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id z11so493510pdj.3 for ; Fri, 02 Aug 2013 03:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=N4jXG34Slxo1bboOQ4RMa9tz26E+O/jBy9vkRdKR+Q0=; b=cd9nGd8m9hjdLJTW+KZuj3GUx4acskgYBY2Cb/twNQRKZ5GMXVoXOY/z5T4ZW8vusI Yt15vqAoGcxZvf8NmDDooKFhDUWryddQvUfW6C3Q4SRXLh+gyLFeSz/Owi36jfBi+7hL d9+Ggy5r0ahBjqX1DJp5fF/AHey8wSgGn9z3/CGDMwI1zF4YPextM81nvVjQugReKzhS ZuelsXXeVWt717WUXsQEhxyDHtLKyvXxyzg1+Wzx8Ji1DtUcrtOghwupO4uo27IslI2g 1+UjmHUEpXvGvKEdg7lK/WN5YJdEWrfjvN7jc7delSHkWYGCbF7lR13sef7XOwLzme/z LNFA== X-Received: by 10.66.164.71 with SMTP id yo7mr9563417pab.92.1375437658836; Fri, 02 Aug 2013 03:00:58 -0700 (PDT) Received: from ?IPv6:2001:df8::80:ad05:d4a5:119b:b61? ([2001:df8:0:80:ad05:d4a5:119b:b61]) by mx.google.com with ESMTPSA id ht5sm9343507pbb.29.2013.08.02.03.00.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 Aug 2013 03:00:57 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: <51FB76F3.1040908@computer.org> Date: Fri, 2 Aug 2013 13:00:53 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <517B198A.6020605@computer.org><6E31144C030982429702B11D6746B98C3709F53B@szxeml557-mbx.china.huawei.com><51FA55F9.1040109@innovationslab.net> <6E31144C030982429702B11D6746B98C3709F609@szxeml557-mbx.china.huawei.com> <51FB76F3.1040908@computer.org> To: Charles E. Perkins X-Mailer: Apple Mail (2.1508) Cc: dmm@ietf.org Subject: Re: [DMM] ticket #38 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 10:01:11 -0000 And all remember to update the issue tracker. - JOuni On Aug 2, 2013, at 12:08 PM, Charles E. Perkins = wrote: > Hello Anthony, >=20 > I think the revised text looks very good, and resolves the issue. >=20 > Regards, > Charlie P. >=20 >=20 > On 8/2/2013 1:24 AM, h chan wrote: >> I am uploading version 07 with the following: >>=20 >> REQ1: Distributed processing >>=20 >> IP mobility, network access and routing solutions provided = by >> DMM MUST enable distributed processing for mobility = management >> so that traffic does not need to traverse centrally = deployed >> mobility anchors and thereby avoid non-optimal routes. >>=20 >> (deleted IP session) >>=20 >> REQ7: Multicast considerations >>=20 >> DMM SHOULD consider multicast early so that solutions can = be >> developed not only to provide IP mobility support when it = is >> needed, but also to avoid network inefficiency issues in >> multicast traffic delivery (such as duplicate multicast >> subscriptions towards the downstream tunnel entities). The >> multicast solutions should therefore avoid restricting the >> management of all IP multicast traffic to a single host >> through a dedicated (tunnel) interface on multicast-capable >> access routers. >>=20 >> (deleted IP multicast session) >>=20 >> H Anthony Chan >>=20 >> -----Original Message----- >> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of = Brian Haberman >> Sent: Thursday, August 01, 2013 2:35 PM >> To: dmm@ietf.org >> Subject: Re: [DMM] ticket #38 >>=20 >> I agree with Charlie's request to move away from the term "session". = It really does not have much meaning in UDP-based applications. = However, the term "flow" does have some issues as well. Are we using = the term "flow" the way it is defined in RFC 5101? If not, then it = needs to be defined in this draft. >>=20 >> Regards, >> Brian >>=20 >> On 8/1/13 8:09 AM, h chan wrote: >>> Charles, >>> Is the following change from "IP multicast sessions" to "multicast = flows" okay? >>>=20 >>> REQ7: Multicast: >>> Version 06: DMM SHOULD consider multicast early so that solutions = can >>> be developed not only to provide IP mobility to keep IP multicast = sessions when it is needed, but also to avoid network inefficiency = issues in multicast traffic delivery (such as duplicate multicast = subscriptions towards the downstream tunnel entities). The multicast = solutions should therefore avoid restricting the management of all IP = multicast traffic to a single host through a dedicated (tunnel) = interface on multicast-capable access routers. >>>=20 >>> REQ7: Multicast: >>> Version 07: DMM SHOULD consider multicast early so that solutions = can >>> be developed not only to provide IP mobility to keep multicast flows = when it is needed, but also to avoid network inefficiency issues in = multicast traffic delivery (such as duplicate multicast subscriptions = towards the downstream tunnel entities). The multicast solutions should = therefore avoid restricting the management of all IP multicast traffic = to a single host through a dedicated (tunnel) interface on = multicast-capable access routers. >>>=20 >>> H Anthony Chan >>>=20 >>> -----Original Message----- >>> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf = Of >>> Charles E. Perkins >>> Sent: Saturday, April 27, 2013 2:19 AM >>> To: dmm@ietf.org >>> Subject: [DMM] Editorial suggestions for >>> draft-ietf-dmm-requirements-03 >>>=20 >>> Hello folks, >>>=20 >>> Here are some editorial suggestions for the document. >>>=20 >>> Check for missing articles. For instance: >>> "Gateway selection mechanism" --> "A gateway selection mechanism" >>>=20 >>> "is also taking the" --> "also takes" >>>=20 >>> Delete "However" before "assigning". >>>=20 >>> Delete "Issues such as" >>>=20 >>> Delete "When demand exceeds capacity," or else explain why the = benefits are unavailable otherwise. >>>=20 >>> "In particular, there is an increase in direct communications among >>> peers in the same geographical area." >>> --> there has always been such locality... in fact maybe = less >>> now than previously. Otherwise, please provide a = citation. >>>=20 >>> Delete "While deploying" >>>=20 >>> "today's mobile networks, service providers face" --> >>> "Today's mobile networks present service providers = with" >>>=20 >>> Delete "more often than not," >>>=20 >>> Delete "Therefore it is not uncommon to observe that" >>>=20 >>> "ever-increasing" --> "unnecessary" >>>=20 >>> "provided" --> "managed" >>>=20 >>> "non-optimal" --> "unnecessary" >>>=20 >>> Delete "Given this motivational background in this section," >>>=20 >>> "address these problems": at this point in the document, the >>> problems have not been identified. As suggested = earlier, >>> there should be a section devoted to listing the = problems, >>> and then a cross reference to that section could = go here. >>>=20 >>> "changing IP address" --> "locator IP address" >>>=20 >>> Insert "The" before "Gateway GPRS Support Node" >>>=20 >>> "respectively, act" --> "all act" >>>=20 >>> "SAE" --> "EPC" >>>=20 >>> "closeby" --> "nearby" >>>=20 >>> Center figure 2. (and might as well center figure 1 too) >>>=20 >>> "future flat IP-based" --> "flat IP-based" >>> (unwise to predict the future) >>>=20 >>> "states the requirements as follows" --> >>> "identifies the = following requirements" >>>=20 >>> "Distributed deployment" --> "Distributed processing" >>> ... also in "REQ1" >>>=20 >>> "of IP sessions" --> "of some flows" >>>=20 >>> "an optimal manner" --> "to avoid known bottlenecks" >>>=20 >>> "This requirement addresses problems PS1, PS2, PS3, and PS4 in the >>> following." >>> ... the following ?what? >>>=20 >>> "each MN therein" .... the MNs are not "in" the tunnel, and they are >>> not "in" the = mobility anchor. >>>=20 >>> "Centralized anchoring" --> "Centralized anchoring designs" >>>=20 >>> "Distributing >>> the tunnel maintenance function and the mobility context >>> maintenance function among different network entities can >>> increase scalability." >>> --> only when the signaling protocol is properly = designed. >>>=20 >>> "is to be inline" --> "conforms" >>>=20 >>> "may need to interoperate with a network or mobile hosts/ >>> routers that do not support DMM protocols." >>> ... this is technically infeasible. >>> Suggested replacement: >>> "may need to co-exist with a network or mobile hosts/ >>> routers that do not support DMM protocols." >>>=20 >>> Delete "The motivations of this requirement are" >>>=20 >>> -- >>> Regards, >>> Charlie P. >>>=20 >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >>=20 >=20 >=20 > --=20 > Regards, > Charlie P. >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From alexandru.petrescu@gmail.com Fri Aug 2 03:55:36 2013 Return-Path: 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 5B7ED11E8251 for ; Fri, 2 Aug 2013 03:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.156 X-Spam-Level: X-Spam-Status: No, score=-10.156 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, 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 ifwOjSScPkbL for ; Fri, 2 Aug 2013 03:55:26 -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 7004911E8210 for ; Fri, 2 Aug 2013 03:55:26 -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 r72AtOQ5031542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 2 Aug 2013 12:55:24 +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 r72AtOO6018254 for ; Fri, 2 Aug 2013 12:55:24 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.86.16]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id r72AtEbR030135 for ; Fri, 2 Aug 2013 12:55:24 +0200 Message-ID: <51FB9012.9000507@gmail.com> Date: Fri, 02 Aug 2013 12:55:14 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "dmm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [DMM] Draft on PMIP Localized Routing for traffic offloading X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 10:55:38 -0000 Hello, Seeing the presentation of Ryuji in intarea on the use of BGP to realize mobility in the context of a cellular operator, draft-matsushima-stateless-uplane-vepc-01, it makes wonder: - could this be used outside the context of a cellular operator? Or within the cellular operator, but for WiFi offloading? Because we have a draft for WiFi offloading or traffic control for other reasosn, submitted as Localized Routing for PMIPv6: draft-boc-netext-lr-roext-05.txt Alex From sarikaya2012@gmail.com Fri Aug 2 03:59:31 2013 Return-Path: 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 1E54111E8210 for ; Fri, 2 Aug 2013 03:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, 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 Ko2SW0MJktT6 for ; Fri, 2 Aug 2013 03:59:30 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 6F94D11E829B for ; Fri, 2 Aug 2013 03:59:14 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id fp13so329103lab.24 for ; Fri, 02 Aug 2013 03:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=VB+M1Q3Qu1O9EVvItUMBwlA3GSlIqNn6zIp2WjsUABo=; b=TD8YOknsDi8F3rvo9Q9X6OYSvJPkfQsoeV0+6W9VwFaIjFd5+l2gbiYTFafXHTTMhU r1TbN0OfJ5Cvl0bP2VlCOsIFkEKHwb/YWMWFDtu5mgshZZrbdh5YDff5drU1EfBdIFIM YNEMeYcr1O/11ZcnkrBy5UGEtXorH/O9SNlbW/t06m1cDyeE8MJHYgWE4Ui7CZ+MZ/SU wH2oQ/VLqCqUNUTiijGg+8ZgUueXZZPfTG4srtgVmexLL+EpGyuOLdyHxKoNK2u+5MrT jRNCx6IuzlwlpsFT66z8998SZ2DzDtajMgX39Q1hHvqcutNnD3VfxbiX716iMbmrT8J/ cv9w== MIME-Version: 1.0 X-Received: by 10.152.21.131 with SMTP id v3mr2761821lae.50.1375441153070; Fri, 02 Aug 2013 03:59:13 -0700 (PDT) Received: by 10.114.98.227 with HTTP; Fri, 2 Aug 2013 03:59:13 -0700 (PDT) In-Reply-To: <51FB9012.9000507@gmail.com> References: <51FB9012.9000507@gmail.com> Date: Fri, 2 Aug 2013 05:59:13 -0500 Message-ID: From: Behcet Sarikaya To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=089e0158b694569ab004e2f4d907 Cc: "dmm@ietf.org" Subject: Re: [DMM] Draft on PMIP Localized Routing for traffic offloading X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 10:59:31 -0000 --089e0158b694569ab004e2f4d907 Content-Type: text/plain; charset=ISO-8859-1 Hi Alex, On Fri, Aug 2, 2013 at 5:55 AM, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Hello, > > Seeing the presentation of Ryuji in intarea on the use of BGP to realize > mobility in the context of a cellular operator, > draft-matsushima-stateless-**uplane-vepc-01, it makes wonder: > > - could this be used outside the context of a cellular operator? Or > within the cellular operator, but for WiFi offloading? > > I don't think so. You may look into http://tools.ietf.org/html/rfc6909 Regards, Behcet > Because we have a draft for WiFi offloading or traffic control for other > reasosn, submitted as Localized Routing for PMIPv6: > > draft-boc-netext-lr-roext-05.**txt > > Alex > > ______________________________**_________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/**listinfo/dmm > --089e0158b694569ab004e2f4d907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Alex,


On Fri, Aug 2, 2013 at 5:55 AM, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
Hello,

Seeing the presentation of Ryuji in intarea on the use of BGP to realize mobility in the context of a cellular operator,
draft-matsushima-stateless-uplane-vepc-01, it makes wonder:

- could this be used outside the context of a cellular operator? =A0Or
=A0 within the cellular operator, but for WiFi offloading?


I don't think so.

You may look into

h= ttp://tools.ietf.org/html/rfc6909

Regards,

Behcet
Because we have a draft for WiFi offloading or traffic control for other reasosn, submitted as Localized Routing for PMIPv6:

=A0 =A0 =A0 =A0 =A0 =A0draft-boc-netext-lr-roext-05.txt

Alex

_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm

--089e0158b694569ab004e2f4d907-- From Peter.McCann@huawei.com Fri Aug 2 04:29:16 2013 Return-Path: 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 ACA2A21E8364 for ; Fri, 2 Aug 2013 04:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, 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 hywaZspOBuOs for ; Fri, 2 Aug 2013 04:29:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 387FE21E8346 for ; Fri, 2 Aug 2013 04:28:23 -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.5-GA FastPath queued) with ESMTP id AVR13634; Fri, 02 Aug 2013 11:28:15 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 2 Aug 2013 12:27:53 +0100 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 2 Aug 2013 12:28:08 +0100 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.163]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Fri, 2 Aug 2013 04:28:06 -0700 From: Peter McCann To: Alexandru Petrescu , "dmm@ietf.org" Thread-Topic: [DMM] Draft on PMIP Localized Routing for traffic offloading Thread-Index: AQHOj272yKj4UecKRUuTnGxpFpqdXJmBxmaw Date: Fri, 2 Aug 2013 11:28:05 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716F52B15@dfweml512-mbx.china.huawei.com> References: <51FB9012.9000507@gmail.com> In-Reply-To: <51FB9012.9000507@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.216.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] Draft on PMIP Localized Routing for traffic offloading X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 11:29:16 -0000 Hi, Alex, I definitely think this technique could be used within a WiFi access network as the MN changes from one AP/AR to another. However, it is not clear whether the WiFi APs would be attached to the same I-BGP system as the cellular base stations. If they are, then great, I=20 think it would work. However, if there are radically different backhaul topologies for WiFi and cellular it might be necessary to have two different I-BGP domains and use a global mobility protocol for preserving an address between cellular and Wifi (I think client-based MIP is good=20 for this). I personally think the PMIP-based LR solutions are kind of ugly. -Pete Alexandru Petrescu wrote: > Hello, >=20 > Seeing the presentation of Ryuji in intarea on the use of BGP to > realize mobility in the context of a cellular operator, draft- > matsushima-stateless-uplane-vepc-01, it makes wonder: >=20 > - could this be used outside the context of a cellular operator? Or > within the cellular operator, but for WiFi offloading? > Because we have a draft for WiFi offloading or traffic control for > other reasosn, submitted as Localized Routing for PMIPv6: >=20 > draft-boc-netext-lr-roext-05.txt > Alex From maxpassion@gmail.com Sun Aug 4 19:22:20 2013 Return-Path: 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 4646721E80BF for ; Sun, 4 Aug 2013 19:22:20 -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=[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 kI2YG-Aw-r2S for ; Sun, 4 Aug 2013 19:22:19 -0700 (PDT) Received: from mail-vb0-x229.google.com (mail-vb0-x229.google.com [IPv6:2607:f8b0:400c:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id A5CC021E80BE for ; Sun, 4 Aug 2013 19:22:19 -0700 (PDT) Received: by mail-vb0-f41.google.com with SMTP id g17so2292184vbg.14 for ; Sun, 04 Aug 2013 19:22:18 -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=58f/XWFTylao8lgnPMSXLnZm+VvJn7Nt5VBbDgdLIPM=; b=J1NMHXhKsY1VWLsRRg/kZEl9vGz2J/mdEuk15u9GQwpXDwiNjgtx6iP/+7PwoHFeVo dOb0xA4gbiME8sTm871mrQC2jgkZ9D3on3gfSl/fL/P7rTF64v0URS1dQQWRGcjXM8Lb uo/pSdhFwUw7Sui97EicZ0iWKuYUh755CqWx1qSQOBLuSfBrSKxT/zn86qc0nF0Aglo9 4xTg6jGMcMeHGY/UY7xgJNHHtq2xhtZ8u9ZGGthjc2Z38++ANNVTFMsIcSlclA/ZcKJ3 Rt60+ETY43gcTh3xaG2Ju6f+raXJX1q//Pod0JIYnKBqCLHfLQkNquo7VxcoTTrR/1OL UdbA== MIME-Version: 1.0 X-Received: by 10.220.167.2 with SMTP id o2mr5122105vcy.61.1375669337742; Sun, 04 Aug 2013 19:22:17 -0700 (PDT) Received: by 10.220.142.130 with HTTP; Sun, 4 Aug 2013 19:22:17 -0700 (PDT) In-Reply-To: References: <72EF3457-5B8A-4F5C-8BEA-2EDC5DBF850E@gmail.com> Date: Mon, 5 Aug 2013 10:22:17 +0800 Message-ID: From: Liu Dapeng To: "karagian@cs.utwente.nl" Content-Type: multipart/alternative; boundary=089e011618ce34634c04e329fa77 Cc: liudapeng , dmm Subject: Re: [DMM] comment 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 02:22:20 -0000 --089e011618ce34634c04e329fa77 Content-Type: text/plain; charset=ISO-8859-1 Hi Georgios: Thanks for the comment, let us see how we resolve this in the updated version. Dapeng 2013/8/1 > Hi, > > > > In this email I am repeting the comment that I had today on the mike: > > > > The current version of the draft is not using the requirements defined in > the requirements draft to identify the gaps on existing mobility protocols. > > In my opinion it is important to use these requirements in order to > identify the gaps. > > > > Best regards, > > Georgios > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > -- ------ Best Regards, Dapeng Liu --089e011618ce34634c04e329fa77 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Georgios:

Thanks for the comment, le= t us see how we resolve this in the updated version.

Dapeng


2013/8/1 <karagian@cs.utwente.nl>

Hi,

=A0

In this email I am repeting the com= ment that I had today on the mike:

=A0

The current version of the draft is= not using the requirements defined in the requirements draft to identify t= he gaps on existing mobility protocols.

In my opinion it is important to us= e these requirements in order to identify the gaps.

=A0

Best regards,

Georgios


_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm




--

----= --
Best Regards,
Dapeng Liu
--089e011618ce34634c04e329fa77-- From jouni.nospam@gmail.com Tue Aug 6 14:47:01 2013 Return-Path: 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 E2FCD21E80B9 for ; Tue, 6 Aug 2013 14:47:01 -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=[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 qW33oyN3WR-F for ; Tue, 6 Aug 2013 14:47:01 -0700 (PDT) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3F38C21E80B3 for ; Tue, 6 Aug 2013 14:47:01 -0700 (PDT) Received: by mail-ea0-f181.google.com with SMTP id d10so482622eaj.12 for ; Tue, 06 Aug 2013 14:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=yhp9mZMbWaGZZXCQgcJ1PbIqQunSbZVTmUMpS/VEqpY=; b=gpXldrhbdEkNWSKTGFMMmDuuBiePFthcw+69BoclBDoayj+mWD81JjEiFE9rXshJDr eiZ0u5NjFCK7cA2nzWmYWgQaucfz++OaEjG7sgx58XgUrj3eJaYaIikGzFwC5zRAg4ls kDW7Ho08IN4WKGND7jWkShJaTz2pC+9zklRupOigkEJjLMfeCEbIZ5T/hnaFQXih3eHi XquTvkbfdBEEbJU59UFBB6DOWWsGYs6cmGO71OIny57aTsv51aXyRy0iWUzKGgj1Uoyx RZKv6yrgyGAHUWVF+JKGm3Ud27bLQT+NB87Xk1ObtHNwKQK0Co4y2KWnjbNCuFnnKAKY RvjQ== X-Received: by 10.15.63.142 with SMTP id m14mr119031eex.106.1375825620385; Tue, 06 Aug 2013 14:47:00 -0700 (PDT) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id j2sm4986567eep.6.2013.08.06.14.46.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 Aug 2013 14:46:59 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Wed, 7 Aug 2013 00:46:59 +0300 To: "dmm@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [DMM] draft meeting minutes uploaded X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 21:47:02 -0000 Folks, Draft meeting minutes are now available: http://www.ietf.org/proceedings/87/minutes/minutes-87-dmm And again thanks to Pete for _excellent_ detailed minutes. - Jouni From maxpassion@gmail.com Tue Aug 6 20:37:59 2013 Return-Path: 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 ; 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 ; 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 ; Tue, 6 Aug 2013 20:37:54 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id 15so1245527vea.1 for ; 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, 7 Aug 2013 11:37:51 +0800 Message-ID: From: Liu Dapeng To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=047d7b2e75ec185ece04e35344fe Cc: dmm 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 03:37:59 -0000 --047d7b2e75ec185ece04e35344fe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alex, 2013/8/1 Alexandru Petrescu > 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 =E9crit : > > 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 >> >> >> > > ______________________________**_________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/**listinfo/dmm > --=20 ------ Best Regards, Dapeng Liu --047d7b2e75ec185ece04e35344fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Alex,


2013/8/1 Alexandru Petrescu <alexandru.petres= cu@gmail.com>
Hello DMMers,

I follow on the Chair invitation to suggest gaps to the gap analysis
document. =A0I 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
=A0 =A0mobile network prefixes - it only works for a full /128 Home
=A0 =A0Address. =A0There is a security problem in extending the RR tests fo= r
=A0 =A0prefixes. =A0But if done, it will allow direct communications from a= n
=A0 =A0LFN in the moving network to an arbitrary =A0Correspondent Node in t= he
=A0 =A0Internet.

[Dapeng] Mobile IPv6 Route Optimization is analysed i= n section 4.2.1. Do you propose any changes of current text? =A0
= =A0=A0
2. Anchoring a Mobile Node's Home Address at multiple points may be a =A0 =A0very good goal, but one wonders whether it could be achieved within<= br> =A0 =A0useful limits. =A0An IP address is typically valid at a single point=
=A0 =A0in the Internet. =A0Anchoring it at more places involves the use of<= br> =A0 =A0route updates or of tunnelling. =A0It is a question whether this cou= ld
=A0 =A0be achieved within measurable and advantageous limits, compared to =A0 =A0changing the IP address, or prefer still anchor at remote HA.
=A0
[Dapeng] Some current proposal in DMM WG use m= ultiple home addresses for multiple anchors.=A0

3. Simultaneous use of multiple interfaces at a same mobile router is
=A0 =A0something that is not supported by Mobile IPv6 today (although it =A0 =A0does support multiple Care-of Addresses). =A0If done, it allows
=A0 =A0bandwidth augmentation (i.e. add 10 cellular interfaces to a Mobile<= br> =A0 =A0Router deployed in a bus, and thus multiply the bandwidth by ten) =A0 =A0for all kinds of applications.

[Dapeng] I am not sure whether mobile router case sho= uld be in the scope of DMM?
=A0
These are some thoughts about gaps. =A0If necessary I can try to provide text, provided I understand the current context.

<= /div>
[Dapeng] Yes, text will be appreciated.

= Dapeng
=A0
Alex

Le 24/07/2013 14:54, Jouni Korhonen a =E9crit :

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. =A0Since WiFi is the most widely deployed wireless access technology nowadays, we take it
=A0as"

Do you have some data/reference to backup your claim?

In Section 4.2.1. it is stated:

"at different point of attachment. =A0However 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
=A0would 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
=A0no 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&qu= ot; and
how that is used to discover gateways with both topological and
gateway collocation in mind

In Section 5. it is stated:

"o =A0The dynamic anchor relocation needs to ensure that IP address continuity is guaranteed for sessions that need it at the relocated
anchor. =A0This 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
=A0the 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 =A0Dynamic discovery and selection of anchors. =A0There might be mo= re
than one available anchor for a mobile node to use. =A0Currently, 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://ww= w.ietf.org/mailman/listinfo/dmm




_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm



--
=
------
Best Regards,
Dapeng Liu
--047d7b2e75ec185ece04e35344fe-- From pierrick.seite@orange.com Wed Aug 7 03:10:39 2013 Return-Path: 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 C6A6121F9A49 for ; Wed, 7 Aug 2013 03:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=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 tiuzBiTSllhJ for ; Wed, 7 Aug 2013 03:10:34 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 6B77E21F9A4C for ; Wed, 7 Aug 2013 03:10:33 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 26790264BAC; Wed, 7 Aug 2013 12:10:32 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id F19E3238127; Wed, 7 Aug 2013 12:10:31 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Wed, 7 Aug 2013 12:10:31 +0200 From: To: Liu Dapeng , Jouni Korhonen Thread-Topic: [DMM] comments on draft-ietf-dmm-best-practices-gap-analysis-01 Thread-Index: AQHOiGz1rjft+LoVHUOnc8BopLh6JZl8z9yAgAzKu/A= Date: Wed, 7 Aug 2013 10:10:30 +0000 Message-ID: <27456_1375870232_52021D18_27456_1049_1_81C77F07008CA24F9783A98CFD706F71113B74@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <72EF3457-5B8A-4F5C-8BEA-2EDC5DBF850E@gmail.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: multipart/alternative; boundary="_000_81C77F07008CA24F9783A98CFD706F71113B74PEXCVZYM12corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Cc: Dapeng Liu , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 10:10:39 -0000 --_000_81C77F07008CA24F9783A98CFD706F71113B74PEXCVZYM12corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Please let me jump into the discussion. First of all, thanks for having rea= d and comment the draft. Although, I agree with Dapeng's answers, I have c= ouple of comments: 2013/7/24 Jouni Korhonen > Authors, 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'. [Pierrick] Here, the idea is to focus on a specific non-3GPP network as to= give possible DMM practices; basically we have the choice between wimax an= d wifi... so I guess we can reasonably assume that WiFi is the most deploye= d, no? :). Anyway, we can just say : "Since WiFi is widely deployed nowadays, we take it as" Furthermore, around the bulleted list for the MIPv6 RO discussion, I would mention that nothing prevents a MN to use its CoA directly when communicati= ng 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. [pierrick] Well... Clearly, nothing prevent to use the CoA. In this case th= ere is no IP address preservation, but mobility is still possible; for exam= ple, if the application can handle it. Of course, dynamic selection of the = CoA or the HoA, e.g. depending on application characteristic, (what we can= call this feature "dynamic mobility support") is a valid scenario need to = be addressed (it's in the charter if I remember well) . So, when the decisi= on maker (e.g. connection manager, application, ...) decides that IP preser= vation is needed, then this document comes in, focusing on IP address prese= rvation in a DMM style. This is what we stressed in section 4.1/bullet 3. B= ut if current text gives the impression that dynamic mobility support is ou= t of DMM scope, we have to revise this... 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. [Pierrick] Do you have some data/reference to backup your claim? ;-) [Dapeng] We can add MOBIKE there. 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 deployme= nts 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. [Pierrick] originally we had text on wimax but we finally did not include i= n -01 to not burden the initial draft to favor discussion... so, no problem= for adding Wimax :) 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. [Pierrick] I definitely agree with Jouni, of course we do not want to exclu= de the dynamic aspect of the mobility support... This is why we wrote < for= sessions that need [IP address continuity]". If you think it is not explic= it enough we can reword... let us know.. BR, Pierrick ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_81C77F07008CA24F9783A98CFD706F71113B74PEXCVZYM12corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 = ;

Please let= me jump into the discussion. First of all, thanks for having read and comm= ent the draft. Although, I agree with Dapeng’s  answers, I have couple of comments:

 = ;

 = ;

2013/7/24 Jouni Korhonen <jouni.nospam@gmail.com><= /o:p>

Authors,

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 i= t as"

Do you have some data/reference to backup your claim?

 

[Dapeng] Maybe we can change th= e wording a little bit. e.g. remove 'most'.

 = ;

[Pierri= ck]  Here, t= he idea is to focus on a specific non-3GPP network as to give possible DMM = practices; basically we have the choice between wimax and wifi… so I guess we can reasonably assume that WiFi is the= most deployed, no? J. Anyway, we can= just say :

 = ;

“Since WiFi is widely dep= loyed nowadays, we take it as"

 

= Furthermore, around the bulleted list for the MIPv6 RO discussion, I would<= br> mention that nothing prevents a MN to use its CoA directly when communicati= ng
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<= br> part of our charter). I recon the HMIPv6 text mentions at least the use of<= br> RCoA already.

[Dapeng] Agree.

 

[pierrick]= Well… Clearly, nothing prevent to use the CoA. In this case there is= no IP address preservation, but mobility is still possible; for example, if the application can handle it. Of course, dynamic selection of= the CoA or the HoA, e.g. depending on application characteristic,  (w= hat we can call this feature “dynamic mobility support”) is a v= alid scenario need to be addressed (it’s in the charter if I remember well) . So, when the decision maker (e.g. connection manager= , application, …) decides that IP preservation is needed, then this d= ocument comes in, focusing on IP address preservation in a DMM style. This = is what we stressed in section 4.1/bullet 3. But if current text gives the impression that dynamic mobility support = is out of DMM scope, we have to revise this…

 = ;

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.=

&n= bsp;

[Pierrick]= Do you have some data/reference to backup your claim? ;-)

 = ;

[Dapeng] We can add MOBIKE ther= e.

 

 

&= nbsp;


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 deployme= nts
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.<= /p>

 = ;

[Pierrick]= originally we had text on wimax but we finally did not include in -01 to n= ot burden the initial draft to favor discussion… so, no problem for adding Wimax J

 

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 havin= g the knowledge"

Since our charter _allows_ solutions where mobility is used "when need= ed"
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= .

&n= bsp;

 = ;

[Dapeng] We can change the word= ing here.

 = ;

[Pierrick]= I definitely agree with Jouni, of course we do not want to exclude the dyn= amic aspect of the mobility support… This is why we wrote « for sessions that need [IP address continuity]”. If you= think it is not explicit enough we can reword… let us know..

 = ;

BR,

Pierrick

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_81C77F07008CA24F9783A98CFD706F71113B74PEXCVZYM12corpora_-- From pierrick.seite@orange.com Wed Aug 7 03:17:09 2013 Return-Path: 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 2A1DC21E80BE for ; Wed, 7 Aug 2013 03:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 AkD5FEC3PR7k for ; Wed, 7 Aug 2013 03:17:05 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id A4D5821E80C2 for ; Wed, 7 Aug 2013 03:17:04 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 4839122D00E; Wed, 7 Aug 2013 12:16:56 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 2E62735C113; Wed, 7 Aug 2013 12:16:56 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Wed, 7 Aug 2013 12:16:55 +0200 From: To: Jouni Korhonen , "dmm@ietf.org" Thread-Topic: [DMM] draft meeting minutes uploaded Thread-Index: AQHOku6GFKVzB9CRF0ScfXBiX904tpmJh1ZA Date: Wed, 7 Aug 2013 10:16:55 +0000 Message-ID: <3686_1375870616_52021E98_3686_3846_1_81C77F07008CA24F9783A98CFD706F71113B8D@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.7.91342 Subject: Re: [DMM] draft meeting minutes uploaded X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 10:17:09 -0000 Excellent minutes indeed... with fast delivery... I suggest appointing Pet= e as the "official DMM note taker" :-) -----Message d'origine----- De=A0: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] De la part de Jou= ni Korhonen Envoy=E9=A0: mardi 6 ao=FBt 2013 23:47 =C0=A0: dmm@ietf.org Objet=A0: [DMM] draft meeting minutes uploaded Folks, Draft meeting minutes are now available: http://www.ietf.org/proceedings/87/minutes/minutes-87-dmm And again thanks to Pete for _excellent_ detailed minutes. - Jouni _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From Peter.McCann@huawei.com Wed Aug 7 06:47:17 2013 Return-Path: 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 C2C6321E812E for ; Wed, 7 Aug 2013 06:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, 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 kQ64-F3K6cBv for ; Wed, 7 Aug 2013 06:47:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4307321E812A for ; Wed, 7 Aug 2013 06:47:13 -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.5-GA FastPath queued) with ESMTP id AVV00460; Wed, 07 Aug 2013 13:47:11 +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.1.323.7; Wed, 7 Aug 2013 14:46:08 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 7 Aug 2013 14:46:18 +0100 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.39]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Wed, 7 Aug 2013 06:46:16 -0700 From: Peter McCann To: "pierrick.seite@orange.com" , Jouni Korhonen , "dmm@ietf.org" Thread-Topic: [DMM] draft meeting minutes uploaded Thread-Index: AQHOku6GFKVzB9CRF0ScfXBiX904tpmJh1ZAgAA7rqA= Date: Wed, 7 Aug 2013 13:46:16 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716F675A7@dfweml512-mbx.china.huawei.com> References: <3686_1375870616_52021E98_3686_3846_1_81C77F07008CA24F9783A98CFD706F71113B8D@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <3686_1375870616_52021E98_3686_3846_1_81C77F07008CA24F9783A98CFD706F71113B8D@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.151] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] draft meeting minutes uploaded X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 13:47:17 -0000 Arghh.... pierrick.seite@orange.com wrote: > Excellent minutes indeed... with fast delivery... I suggest > appointing Pete as the "official DMM note taker" :-) >=20 > -----Message d'origine----- > De=A0: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] De la part de > Jouni Korhonen Envoy=E9=A0: mardi 6 ao=FBt 2013 23:47 =C0=A0: dmm@ietf.or= g Objet=A0 > : [DMM] draft meeting minutes uploaded >=20 > Folks, >=20 > Draft meeting minutes are now available: > http://www.ietf.org/proceedings/87/minutes/minutes-87-dmm >=20 > And again thanks to Pete for _excellent_ detailed minutes. >=20 > - Jouni > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm >=20 > ______________________________________________________________________ _ > __________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > que les pieces jointes. Les messages electroniques etant susceptibles > d'alteration, Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or > privileged information that may be protected by law; they should not > be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From ryuji.wakikawa@gmail.com Wed Aug 7 14:26:21 2013 Return-Path: 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 7FF1D21F9633 for ; Wed, 7 Aug 2013 14:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 onVaAlr1+pT0 for ; Wed, 7 Aug 2013 14:26:21 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2F621E80B4 for ; Wed, 7 Aug 2013 14:25:51 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id jh10so2616414pab.3 for ; Wed, 07 Aug 2013 14:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3UIQ8DtynGX34ycldlpWgRntVeT3DZ7SQx4Hf2JsRDM=; b=zJXo2wKFuDEzjYOGyJP7tM67QxiVywEV19fBCrcvEx5WZkqbVhsGPAhiO4WRlWqtZa gDYgA1VnwaYMAWPXYw69OnID/Oz9pN2rHuDWmGTcKwRFPX80GHm1z1uO+QZ9Uafe/+MB xn4SloCMpgxnk1Ypi0uMyTeYL1AINatkQOSq63/unOU6688BRUhUkT/e/Gs42uF6y8o0 2Gz+WzwK2kMZtWYHxfLGHgMoxk2NxwQs8sT+j6SpO/EzXXAJasbj5awvHD5RZ2pB6S8J /kxpp0UnjiLFpX+UkdPHZkQG8HQDCTk2h0HkzsZ3VHq5zenkqkICX5cMOukhvG7vgFad 6tVw== X-Received: by 10.68.163.131 with SMTP id yi3mr2718537pbb.55.1375910751355; Wed, 07 Aug 2013 14:25:51 -0700 (PDT) Received: from [10.250.181.4] (i118-21-136-4.s30.a048.ap.plala.or.jp. [118.21.136.4]) by mx.google.com with ESMTPSA id nm10sm10141520pbc.28.2013.08.07.14.25.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Aug 2013 14:25:49 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ryuji Wakikawa In-Reply-To: <3686_1375870616_52021E98_3686_3846_1_81C77F07008CA24F9783A98CFD706F71113B8D@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Thu, 8 Aug 2013 06:25:49 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <402B27C4-1EA1-4865-A2A3-B1BB5DF811C9@gmail.com> References: <3686_1375870616_52021E98_3686_3846_1_81C77F07008CA24F9783A98CFD706F71113B8D@PEXCVZYM12.corporate.adroot.infra.ftgroup> To: pierrick.seite@orange.com X-Mailer: Apple Mail (2.1508) Cc: "dmm@ietf.org" Subject: Re: [DMM] draft meeting minutes uploaded X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 21:26:21 -0000 On Aug 7, 2013, at 7:16 PM, pierrick.seite@orange.com wrote: > Excellent minutes indeed... with fast delivery... I suggest = appointing Pete as the "official DMM note taker" :-) +1.=20 superb job. Thanks pete! ryuji =20 >=20 > -----Message d'origine----- > De : dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] De la part de = Jouni Korhonen > Envoy=E9 : mardi 6 ao=FBt 2013 23:47 > =C0 : dmm@ietf.org > Objet : [DMM] draft meeting minutes uploaded >=20 > Folks, >=20 > Draft meeting minutes are now available: > http://www.ietf.org/proceedings/87/minutes/minutes-87-dmm >=20 > And again thanks to Pete for _excellent_ detailed minutes. >=20 > - Jouni > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From maxpassion@gmail.com Wed Aug 7 18:37:40 2013 Return-Path: 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 935D611E8198 for ; Wed, 7 Aug 2013 18:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=-0.028, 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 byS50mzPfjsv for ; Wed, 7 Aug 2013 18:37:40 -0700 (PDT) Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id AFF9A11E80F6 for ; Wed, 7 Aug 2013 18:37:36 -0700 (PDT) Received: by mail-vb0-f53.google.com with SMTP id i3so2590748vbh.40 for ; Wed, 07 Aug 2013 18:37:36 -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=fRDy4yBkUeQAFqe+D3b+eMOYo6V6XJn/zIAMHlY+0Qg=; b=Tjy3jnrhSMR/uRXBHMLmI+7dQ9qB/beN1tKktw0lvCYkP4NiQNJRByIkZfg0idQaWI PhJP5IxKwJyUZ9EwrzDmuM051wqM3B11UMHMieBQLh8KxXne1Jc38VbUXuTxoaCeVdXN dGsCFnQA+BUblJc5vwxRYcO4oZYnw1n9JKb7S1D1V7LVksyKu0QaIIFWzDA4/nWH4G8F dJCjZYfyfWaa3JiitY06xi/7IDz+40nBPMbQfyH8jb4TtJfNCIDoxZTaIV03f6OXVrRZ RBztXddW/sug0PfXleE06j2vj+4Gem9zlbzEhrrXWJukqh068G/ueG4pFsNgn/3Bi3hs LiDw== MIME-Version: 1.0 X-Received: by 10.220.145.132 with SMTP id d4mr2828235vcv.9.1375925855947; Wed, 07 Aug 2013 18:37:35 -0700 (PDT) Received: by 10.220.142.130 with HTTP; Wed, 7 Aug 2013 18:37:35 -0700 (PDT) In-Reply-To: <3686_1375870616_52021E98_3686_3846_1_81C77F07008CA24F9783A98CFD706F71113B8D@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <3686_1375870616_52021E98_3686_3846_1_81C77F07008CA24F9783A98CFD706F71113B8D@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Thu, 8 Aug 2013 09:37:35 +0800 Message-ID: From: Liu Dapeng To: "pierrick.seite@orange.com" Content-Type: multipart/alternative; boundary=047d7b34347ce1927904e365b354 Cc: "dmm@ietf.org" Subject: Re: [DMM] draft meeting minutes uploaded X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 01:37:40 -0000 --047d7b34347ce1927904e365b354 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, very detail, excellent job 2013/8/7 > Excellent minutes indeed... with fast delivery... I suggest appointing > Pete as the "official DMM note taker" :-) > > -----Message d'origine----- > De : dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] De la part de > Jouni Korhonen > Envoy=E9 : mardi 6 ao=FBt 2013 23:47 > =C0 : dmm@ietf.org > Objet : [DMM] draft meeting minutes uploaded > > Folks, > > Draft meeting minutes are now available: > http://www.ietf.org/proceedings/87/minutes/minutes-87-dmm > > And again thanks to Pete for _excellent_ detailed minutes. > > - Jouni > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > --=20 ------ Best Regards, Dapeng Liu --047d7b34347ce1927904e365b354 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, very detail, excellent job
=
2013/8/7 <pierrick.seite@orange.co= m>
Excellent minutes indeed... with fast delive= ry... =A0I suggest appointing Pete as the "official DMM note taker&quo= t; :-)

-----Message d'origine-----
De=A0: dmm-bounces@ietf.org [ma= ilto:dmm-bounces@ietf.org] De l= a part de Jouni Korhonen
Envoy=E9=A0: mardi 6 ao=FBt 2013 23:47
=C0=A0: dmm@ietf.org
Objet=A0: [DMM] draft meeting minutes uploaded

Folks,

Draft meeting minutes are now available:
http://www.ietf.org/proceedings/87/minutes/minutes-87-dmm<= br>
And again thanks to Pete for _excellent_ detailed minutes.

- Jouni
_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm

_______________________________________________________________= __________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm



--
=
------
Best Regards,
Dapeng Liu
--047d7b34347ce1927904e365b354-- From jouni.nospam@gmail.com Sat Aug 10 04:25:27 2013 Return-Path: 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 4387721E809E for ; Sat, 10 Aug 2013 04:25:27 -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=[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 nBxeC0cGuCBE for ; Sat, 10 Aug 2013 04:25:26 -0700 (PDT) Received: from mail-bk0-x229.google.com (mail-bk0-x229.google.com [IPv6:2a00:1450:4008:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id B5E9B21F85B4 for ; Sat, 10 Aug 2013 04:20:22 -0700 (PDT) Received: by mail-bk0-f41.google.com with SMTP id na10so1375523bkb.28 for ; Sat, 10 Aug 2013 04:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=5HYRPXW4BbRgDjbFBHtSWteBJKpmZ52zF2bcFm31MsA=; b=FbXCUI3ve34ZIMeipbUHSar3j7k0F0xKIYm/jpVH0NJ9eyS5GZUOsiF0klUQexnzYq xoMh8g4wan1BmcDWPKlGjlQ/2V4CpZBP1ulp90YLdVhaZOtq//tinYrg64+R6xu/a7es 9VlSCwWNo6vxtj4xZTxY0xO6viuLkRX7q0Bf0458IVR0KvaiLUReyxbQNIV8ktrXVEps /1gAd1++yvQnNZVSYyYdG0MzVGMIDcAILYpXRFwgOMHWUytcP1ZVGL2/yxa5yuJNpS1w wpmIDkGpZRTfB8poaz1mDF4S3AhJRVwMJ0n03aZtOHrwMF8JbN1xPUxhq8AoPaFx7dbr ZmRg== X-Received: by 10.205.128.203 with SMTP id hf11mr2699635bkc.160.1376133621793; Sat, 10 Aug 2013 04:20:21 -0700 (PDT) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id 14sm2599395bkl.17.2013.08.10.04.20.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 10 Aug 2013 04:20:21 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <6321AEDB-F656-4C0B-9DAC-A711E07B8554@gmail.com> Date: Sat, 10 Aug 2013 14:20:23 +0300 To: "dmm@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [DMM] The requirements draft progress X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 11:25:27 -0000 Folks, Great stuff. We got back to zero tickets in the issue tracker for the = requirements document. I'll soon issue another WGLC for the I-D and I hope people who have = "bigger issues" with the current -07 document would speak up _before_ the WGLC i.e. now. Note that during this WGLC I'll also engage other directorates such as = the sec-dir and ops-dir to provide reviews _before_ the document moves out of the WG. All WGLC = comments and directorate comments will be dealt within the WG before the document moves to IESG = processing. It would be a bit waste of directorate time if we as a WG redo the I-D in great = deal after we solicited reviews from them. - Jouni & Julien= From miya.kohno@gmail.com Sat Aug 10 07:48:07 2013 Return-Path: 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 42A6311E8131 for ; Sat, 10 Aug 2013 07:48:07 -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=[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 888aWBnNd6zm for ; Sat, 10 Aug 2013 07:48:06 -0700 (PDT) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDF521F8607 for ; Sat, 10 Aug 2013 07:42:14 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id gf11so1775125vcb.39 for ; Sat, 10 Aug 2013 07:42:14 -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=hD9xTZ3Wy2/ACfi0/P/OJ9cJ+uASvFvFVF17sS98JOE=; b=OsIgt+lUjnR7H5snvwNEQghujGRIln0AfSqBEPLbemTfjeaxHNmBWMViaVf4hgUfGs po/Ib2ZG3OG3pUPG6CJo9EJhbwW9vk3X59k63GISAxvKRlygGxW+Qv+mYaS7MCyjxPO5 RfCmdcFpiip24IWVflkNkH+ktZLvRH++xxoQLEA1SwJlZLd1W0NaZWnDVj3MvPDuZ7Sh /zRu5lvByxCFb6Rl7Xb7cV9+Z2WxG1l+b9QIPmKN13IntCSaYD7kCH+BvTSp75EacEfW 7+vxW0WZq7MYkEBtXA7VGsaHLh3Zx1kUTPjseLCDYgminjPX9Q9w/Y8Lw99Vm7HxU56Z eliw== MIME-Version: 1.0 X-Received: by 10.58.235.69 with SMTP id uk5mr2815817vec.17.1376145733968; Sat, 10 Aug 2013 07:42:13 -0700 (PDT) Received: by 10.58.120.44 with HTTP; Sat, 10 Aug 2013 07:42:13 -0700 (PDT) In-Reply-To: References: <3686_1375870616_52021E98_3686_3846_1_81C77F07008CA24F9783A98CFD706F71113B8D@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Sat, 10 Aug 2013 23:42:13 +0900 Message-ID: From: Miya Kohno To: Liu Dapeng Content-Type: multipart/alternative; boundary=047d7bd6c2c4a1e9f504e398e5d2 Cc: "dmm@ietf.org" Subject: Re: [DMM] draft meeting minutes uploaded X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 14:48:07 -0000 --047d7bd6c2c4a1e9f504e398e5d2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thank you! Just a very minor correction.. My name is Miya, not Mita.. :) Miya On Thu, Aug 8, 2013 at 10:37 AM, Liu Dapeng wrote: > Yes, very detail, excellent job > > 2013/8/7 > > Excellent minutes indeed... with fast delivery... I suggest appointing >> Pete as the "official DMM note taker" :-) >> >> -----Message d'origine----- >> De : dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] De la part de >> Jouni Korhonen >> Envoy=E9 : mardi 6 ao=FBt 2013 23:47 >> =C0 : dmm@ietf.org >> Objet : [DMM] draft meeting minutes uploaded >> >> Folks, >> >> Draft meeting minutes are now available: >> http://www.ietf.org/proceedings/87/minutes/minutes-87-dmm >> >> And again thanks to Pete for _excellent_ detailed minutes. >> >> - Jouni >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> >> >> ________________________________________________________________________= _________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >> recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme >> ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >> been modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> > > > > -- > > ------ > Best Regards, > Dapeng Liu > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > --047d7bd6c2c4a1e9f504e398e5d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thank you! Just a very minor correction.. My name is Miya,= not Mita.. :)=A0

Miya


On Thu, Aug 8, 2013 at 10:37 AM, Li= u Dapeng <maxpassion@gmail.com> wrote:
Yes, very detail, excellent= job

2013/8/7 <pierrick.seite@orange.com>

Excellent minutes indeed... with fast delive= ry... =A0I suggest appointing Pete as the "official DMM note taker&quo= t; :-)

-----Message d'origine-----
De=A0: dmm-bounce= s@ietf.org [mailto:dmm-bounces@ietf.org] De la part de Jouni Korhonen
Envoy=E9=A0: mardi 6 ao=FBt 2013 23:47
=C0=A0: dmm@ietf.org<= br> Objet=A0: [DMM] draft meeting minutes uploaded

Folks,

Draft meeting minutes are now available:
http://www.ietf.org/proceedings/87/minutes/minutes-87-dmm<= br>
And again thanks to Pete for _excellent_ detailed minutes.

- Jouni
_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm

_______________________________________________________________= __________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm



--

------
Be= st Regards,
Dapeng Liu

_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm


--047d7bd6c2c4a1e9f504e398e5d2-- From jouni.nospam@gmail.com Sun Aug 11 00:35:24 2013 Return-Path: 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 9F25821F9AD1 for ; Sun, 11 Aug 2013 00:35:24 -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] 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 S+MLL8OcdvwP for ; Sun, 11 Aug 2013 00:35:24 -0700 (PDT) Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3D94721F867B for ; Sun, 11 Aug 2013 00:29:42 -0700 (PDT) Received: by mail-bk0-f49.google.com with SMTP id r7so1809098bkg.36 for ; Sun, 11 Aug 2013 00:29:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2PHqhk3EK/OceGJ7OJ0lmlUCG2uZJhk718zdNXMPf8Q=; b=Ds/B32tFkeMIbXZJZQJ8xX/p2o37M+02fIQSry7Fs3wZnQgab49mKOKTb8he2KTC++ Tvgf6DzVxG8U9gWw9ncZH+KWzVcnfmBARslTbXjFBqk4LKm9wquunZprOnPz9hnR723c ngcw2kZ6tZOdw5orzWCcOPGjVl51zogXYjLBSmT0tsobn6/3CXQ6XAy1SzQTW1VbyIx2 yiTQFISKYjnZqGewAun/FeTL07L6e9yUlenWXwypK2G+2uJ4KXqs5Q9wq9fl43zxoVIC gNuAn8vZt8yz9ktHnZ8QU34bOu+QADF1n3VaLq+BBCTeLupbN4lH8cgDubkfRxAWmq52 F2Bg== X-Received: by 10.204.102.71 with SMTP id f7mr279749bko.57.1376206180009; Sun, 11 Aug 2013 00:29:40 -0700 (PDT) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id et15sm4459717bkc.0.2013.08.11.00.29.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 11 Aug 2013 00:29:36 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: Date: Sun, 11 Aug 2013 10:29:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2127D8E3-B8F1-4CD2-BE02-E4D16E24806B@gmail.com> References: <3686_1375870616_52021E98_3686_3846_1_81C77F07008CA24F9783A98CFD706F71113B8D@PEXCVZYM12.corporate.adroot.infra.ftgroup> To: Miya Kohno X-Mailer: Apple Mail (2.1508) Cc: "dmm@ietf.org" Subject: Re: [DMM] draft meeting minutes uploaded X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 07:35:24 -0000 Ok. Thanks ;-) On Aug 10, 2013, at 5:42 PM, Miya Kohno wrote: > Thank you! Just a very minor correction.. My name is Miya, not Mita.. = :)=20 >=20 > Miya >=20 >=20 > On Thu, Aug 8, 2013 at 10:37 AM, Liu Dapeng = wrote: > Yes, very detail, excellent job >=20 > 2013/8/7 >=20 > Excellent minutes indeed... with fast delivery... I suggest = appointing Pete as the "official DMM note taker" :-) >=20 > -----Message d'origine----- > De : dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] De la part de = Jouni Korhonen > Envoy=E9 : mardi 6 ao=FBt 2013 23:47 > =C0 : dmm@ietf.org > Objet : [DMM] draft meeting minutes uploaded >=20 > Folks, >=20 > Draft meeting minutes are now available: > http://www.ietf.org/proceedings/87/minutes/minutes-87-dmm >=20 > And again thanks to Pete for _excellent_ detailed minutes. >=20 > - Jouni > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 >=20 > --=20 >=20 > ------ > Best Regards, > Dapeng Liu >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From julien.ietf@gmail.com Wed Aug 14 13:12:57 2013 Return-Path: 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 92BC021E80D6 for ; Wed, 14 Aug 2013 13:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 MwvWvwHAu4dU for ; Wed, 14 Aug 2013 13:12:56 -0700 (PDT) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id B314821E80DF for ; Wed, 14 Aug 2013 13:12:56 -0700 (PDT) Received: by mail-ve0-f178.google.com with SMTP id ox1so8020817veb.23 for ; Wed, 14 Aug 2013 13:12:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=82XTxksWQwwxy90Lw/ZaD71XlCIJ+0TqUR0ad8j7OhI=; b=fv+FRyQpcXSSsDphb3uT7BZIwQ8Y52RCrfPFMEcXqG0W9HeGkZimMf5jvdbCPWkfFY P9FRBhHudDxAR1enYT6Ja7KuIB9Ap93d6qFvxlRZxQCkb2raGpF2D+74K6h8gYle5wL8 eYIrszwgCvYYe5YRwb2GRuiiDt7+pqiFrT4sxuyIzlyycW/lFvfyHGjFL7qqy1xrzLTS jh6wTW2cPCLFW/ijUugaKCwnXPmJiHAuVwPmLJPp6hBYmRrBJzhk3TdXjDhmkoQJZkHf DuDj4US95mHYSKVkblSuqTUSKmY2E13PkJSh+xqrpaU4uPPNI3R2Z/JB/f9LoKSf4Sbd P9qA== MIME-Version: 1.0 X-Received: by 10.58.207.195 with SMTP id ly3mr852340vec.77.1376511166676; Wed, 14 Aug 2013 13:12:46 -0700 (PDT) Received: by 10.52.72.234 with HTTP; Wed, 14 Aug 2013 13:12:46 -0700 (PDT) Date: Wed, 14 Aug 2013 13:12:46 -0700 Message-ID: From: Julien Laganier To: Alper Yegin Content-Type: text/plain; charset=ISO-8859-1 Cc: dmm Subject: [DMM] Comment/Question on draft-yegin-dmm-ondemand-mobility X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 20:12:57 -0000 Hi Alper, I have one comment/question below. The reason 5014 defines preference rather than requirements is, it was expected that many application only have preferences rather than a hard requirements, thus it makes sense to provide N IPV6_PREFER_SRC_* values for the socket option to allow application to express preferences for the N type of addresses. Doing it in this way wouldn't lead to a communication failure if preference couldn't be fulfilled, e.g., at time of connect() or send(). For those applications that have a hard requirement, they can first express their preference, and once the kernel has selected an address based on the preference at connect() or bind2addrsel() invocation, verify that their preference satisfy the requirement with the is_srcaddr call. See http://tools.ietf.org/html/rfc5014#section-13 for the details. Given the application with hard requirement can be supported as above, there was no need to define another N IPV6_REQUIRE_SRC_* values... This seems to apply to your draft too, doesn't it? If so you would only need to define one new value in addition to the two existing ones that are relevant to your problem statement: - existing IPV6_PREFER_SRC_HOME [RFC5014] for home anchored - existing IPV6_PREFER_SRC_COA [RFC5014] for unanchored - new IPV6_PREFERE_SRC_VISITED [I-D.yegin-dmm-ondemand-mobility] for access anchored what do you think? Regards, --julien On Thu, Jul 18, 2013 at 7:17 AM, Alper Yegin wrote: > Hey Julien, > > How is it going? > > Did you have a chance to read our new I-Ds? > > http://www.ietf.org/id/draft-yegin-dmm-cnet-homing-00.txt > > http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-00.txt > > I'd appreciate if you can take a look at them and share your comments -- > online or offline, either way is fine. > > > Thank you and see you in Berlin. > > Alper From alper.yegin@yegin.org Thu Aug 15 02:39:22 2013 Return-Path: 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 51B5111E8137 for ; Thu, 15 Aug 2013 02:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 DKMEJ36UgKl9 for ; Thu, 15 Aug 2013 02:39:17 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6AC11E8130 for ; Thu, 15 Aug 2013 02:39:17 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0Lb489-1VpoGs1JI9-00kgko; Thu, 15 Aug 2013 05:39:14 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Alper Yegin In-Reply-To: Date: Thu, 15 Aug 2013 12:39:12 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Julien Laganier X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:PpZP9go7C7AEMaPFcU3rZP1Hw1b35Z55JGTXcUGbxql 0ZLF7CmBnNxDfY/FGAMWYVteAglQ4CenhK1l+uT6bUWG1BbhK9 ZdORcjSuenH9D5nBkdxSjhzLSRtKcfzCmzG1emHpGtv8n+viNd 6oA+Lc8BNRiuxUuv3/26sVZ13TBuyvIuPd3IRSx49AGQq+nJKn mKyMvzotO8/kimGI1kcXv7rb8ocsu+zrQUwqfzQcsojereipj9 W/12R9Wjqm9XpL0aWA0a5mOfblLUKdI7flJ+XZ53TKQEUVb0qq lsYbGeDS4/extIonmIEi0w12fRfyEDP9Uix+UA7tCqqP3wIUst 7MR9zYUgQnHY7SM7NmSqH7r5bd5cm3840qEESDrwMhzRKPwVPp ABCAPUsG9ggRg== Cc: dmm Subject: Re: [DMM] Comment/Question on draft-yegin-dmm-ondemand-mobility X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 09:39:22 -0000 Hi Julien, Thank you for the feedback. "Prefer" has the following semantic: Give me one IP address of this = type, if one is available. "Required" has the additional semantic: Try to configure one, is none is = available. So, "prefer" does not cover functionality we are seeking. Alper On Aug 14, 2013, at 11:12 PM, Julien Laganier wrote: > Hi Alper, >=20 > I have one comment/question below. >=20 > The reason 5014 defines preference rather than requirements is, it was > expected that many application only have preferences rather than a > hard requirements, thus it makes sense to provide N IPV6_PREFER_SRC_* > values for the socket option to allow application to express > preferences for the N type of addresses. Doing it in this way wouldn't > lead to a communication failure if preference couldn't be fulfilled, > e.g., at time of connect() or send(). >=20 > For those applications that have a hard requirement, they can first > express their preference, and once the kernel has selected an address > based on the preference at connect() or bind2addrsel() invocation, > verify that their preference satisfy the requirement with the > is_srcaddr call. See http://tools.ietf.org/html/rfc5014#section-13 for > the details. >=20 > Given the application with hard requirement can be supported as above, > there was no need to define another N IPV6_REQUIRE_SRC_* values... >=20 > This seems to apply to your draft too, doesn't it? >=20 > If so you would only need to define one new value in addition to the > two existing ones that are relevant to your problem statement: >=20 > - existing IPV6_PREFER_SRC_HOME [RFC5014] for home anchored >=20 > - existing IPV6_PREFER_SRC_COA [RFC5014] for unanchored >=20 > - new IPV6_PREFERE_SRC_VISITED [I-D.yegin-dmm-ondemand-mobility] for > access anchored >=20 > what do you think? >=20 > Regards, >=20 > --julien >=20 > On Thu, Jul 18, 2013 at 7:17 AM, Alper Yegin = wrote: >> Hey Julien, >>=20 >> How is it going? >>=20 >> Did you have a chance to read our new I-Ds? >>=20 >> http://www.ietf.org/id/draft-yegin-dmm-cnet-homing-00.txt >>=20 >> http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-00.txt >>=20 >> I'd appreciate if you can take a look at them and share your comments = -- >> online or offline, either way is fine. >>=20 >>=20 >> Thank you and see you in Berlin. >>=20 >> Alper From alper.yegin@yegin.org Thu Aug 15 04:07:48 2013 Return-Path: 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 07F6C11E8110 for ; Thu, 15 Aug 2013 04:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 sqPNrMTppUMw for ; Thu, 15 Aug 2013 04:07:24 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id E16DA21F9BF1 for ; Thu, 15 Aug 2013 04:07:23 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MhScU-1VWWSQ1UvK-00MbD3; Thu, 15 Aug 2013 07:07:15 -0400 From: Alper Yegin Content-Type: multipart/alternative; boundary="Apple-Mail=_899A059D-A443-47D3-8600-56E68DCD670E" Date: Thu, 15 Aug 2013 14:07:11 +0300 Message-Id: <6F175D88-1926-40DB-A5FA-6D21DFD156F7@yegin.org> To: dmm Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:peq06wl8zmX2qsZf8WxddhgjyKIoZubjS9aVtcbvaxC 5wZGgyAROA6J4iH2QZfS0YFyitIscmfjnYnx4OOb4o+8vUQ8nQ je6BGr6aYVVFNekmPtPaohULhRimOFoUbIlYFs8M5QGpiW37Lk JCAh4H419a4Q1yrT6FGV0we4jhQ8EIxDE/e8LZk6uV4gOBsAJU lOi21T/CelBvpzKFeK9ioSr8dsa3ylk4fO8UcKJZoCePc3H4rT GdjxYisnOi8UzrCsj/ZndbP/vAFZTlgWvogVzOB4kITq0IZxbL 2irrbIFPzuzoGyjHZ8p+UYpm47uzxepUWTyCkJtPPUlOaU60lm nM2CI9FwClHNicAPjcOq6N9VKPqFeRhLnzAfmwcqfOUXfY1heb kOB7qbqJoabfA== Subject: [DMM] requirements-07 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 11:07:48 -0000 --Apple-Mail=_899A059D-A443-47D3-8600-56E68DCD670E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, Here's my review feedback on draft-ietf-dmm-requirements-07. The distributed mobility management (DMM) charter addresses two complementary aspects of mobility management procedures: the distribution of mobility anchors towards a more flat network and the dynamic activation/deactivation of mobility protocol support as an enabler to distributed mobility management. The former aims at positioning mobility anchors (e.g., HA, LMA) closer to the user; ideally, mobility agents could be collocated with the first-hop router.=20 The last sentence is aiming at one of the approaches (anchoring at the = access network). There's also another approach, anchoring near the corresponding network. The important thing is not to deviate from most direct data-path between = the MN and CN when providing mobility management. This can be done by locating the mobility agent near the MN, and also by = locating it near the CN. In order not to limit the language to one of the approaches only, I'd = recommend the following re-write for the last sentence: The former aims at positioning mobility anchors (e.g., HA, LMA) closer to the direct = data-path between the MN and the CN; (e.g., mobility agents could be collocated with the first-hop router, = or with a router near the CN). At the IP layer, a mobility management protocol supporting session continuity is typically based on the principle of distinguishing between identifier and routing address and maintaining a mapping between the two. In Mobile IP, the home address serves as an identifier of the device whereas the care-of-address (CoA) takes the role of the routing address. The binding between these two is maintained at the home agent (mobility anchor). If packets can be continuously delivered to a mobile node at its home address, then all sessions using that home address are unaffected even though the routing address (CoA) changes. I recommend we refer to both IP session continuity, and also IP address = reachability. In my understanding, we are definitely seeking solutions addressing IP = session continuity. Meanwhile, solutions addressing IP address reachability is welcome too. Mobility management functions may also be distributed to multiple networks as shown in Figure 2, so that a mobile node in any of these networks may be served by a nearby mobility function (MF). I think the original intention was to state "near to MN". But like I = explained above, that's just one approach.=20 We can state "may be served by a mobility function that is located close = to the direct MN-CN data-path". IP mobility, network access and routing solutions provided by DMM MUST enable distributed processing for mobility management so that traffic does not need to traverse centrally deployed mobility anchors and thereby avoid non-optimal routes. Some people may consider an anchor located near CN as centralized, in = some sense.=20 But obviously, this is not the same kind of centralization caused by = using a HA located in core network, and not causing the non-optimal = route. In order to prevent such confusion, I'd recommend the following = text: IP mobility, network access and routing solutions provided by DMM MUST enable distributed processing for mobility management so that traffic does not follow non-optimal routes caused by=20= having to traverse centrally deployed mobility anchors. This requirement addresses the problems PS1, PS2, PS3, and PS4 described in Section 4. (Existing route optimization is only a host- based solution. Now there are also router-based solutions available (cnet-homing, = flows-distribution-and-handoff). So, I recommend we either provide a reference and qualify the term = "existing", or remove this statement. DMM solutions MUST provide transparent mobility support above the IP layer when needed. I'd say "SHOULD". We may consider some solutions that expose the IP = address change to the apps, and expect apps to do something with it. We = haven't discussed them yet, but I don't see a reason why we should shut = the door on them. Also: The present API-based approaches and the following text suggests = some awareness on the app is useful. Infrequent node mobility coupled with application intelligence suggest that mobility support could be provided selectively, thus reducing the amount of context maintained in the network. The motivation text does not seem to match this requirement either: Motivation: The motivation of this requirement is to enable more efficient use of network resources and more efficient routing by not maintaining context at the mobility anchor when there is no such need. I'd recommend we modify the requirement as: DMM solutions SHOULD provide transparent mobility support = above the IP layer when needed. Such transparency is needed, for example, when, upon change of point of attachment to the network, an application flow cannot cope with a change in the IP address. However, it is not always necessary to maintain a stable home IP address or prefix for every application or at all times for a mobile node. Some DMM solutions MAY expose=20 mobility to the layers above IP. DMM solutions SHOULD target IPv6 as the primary deployment environment and SHOULD NOT be tailored specifically to support IPv4, in particular in situations where private IPv4 addresses and/or NATs are used. Is this the commonly-used language regarding the treatment of IPv4 in = IETF, or something we came up with? People may argue what is considered as "tailoring". A DMM solution SHOULD first consider reusing and extending IETF-standardized protocols before specifying new protocols. I'd say "MUST". How can we not ? :-) Thanks! Alper --Apple-Mail=_899A059D-A443-47D3-8600-56E68DCD670E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii draft-ietf-dmm-requirements-07.

   complementary aspects of mobility = management procedures: the
   distribution of = mobility anchors towards a more flat network and the
   enabler to distributed mobility = management.  The former aims at
   positioning mobility = anchors (e.g., HA, LMA) closer to the user;
   ideally, = mobility agents could be collocated with the first-hop

The last sentence is = aiming at one of the approaches (anchoring at the access = network).
There's also another = approach, anchoring near the corresponding = network.
The important thing is = not to deviate from most direct data-path between the MN and CN when = providing mobility management.
This can be done by locating the mobility agent near the MN, and = also by locating it near the CN.

In order not to limit = the language to one of the approaches only, I'd recommend the following = re-write for the last sentence:

   positioning = mobility anchors (e.g., HA, LMA) closer to the direct data-path between = the MN and the CN;
   (e.g., mobility agents could be = collocated with the first-hop router, or with a router near the = CN).
   continuity is typically based on the = principle of distinguishing
   between identifier and = routing address and maintaining a mapping
   between the = two.  In Mobile IP, the home address serves as an
   role of the routing address.  = The binding between these two is
   maintained at the home = agent (mobility anchor).  If packets can be
   sessions using that home address are = unaffected even though the
   routing address (CoA) = changes.
I recommend we refer = to both IP session continuity, and also IP address = reachability.
In my understanding, we are definitely seeking solutions = addressing IP session continuity.
Meanwhile, = solutions addressing IP address reachability is welcome = too.



   networks as shown in Figure 2, so = that a mobile node in any of these
   networks may be served = by a nearby mobility function (MF).

I think the original = intention was to state "near to MN". But like I explained above, that's = just one approach. 
We can state "may be served by a = mobility function that is located close to the direct MN-CN = data-path".


        =   IP mobility, network access and routing solutions provided = by
          = so that traffic does not need to traverse centrally deployed

Some people may consider an anchor = located near CN as centralized, in some sense. 
But = obviously, this is not the same kind of centralization caused by using a = HA located in core network, and not causing the non-optimal route. In = order to prevent such confusion, I'd recommend the following = text:

        =   DMM MUST enable distributed processing for mobility = management
          so that = traffic does not follow non-optimal routes caused = by 


   described in Section 4.  = (Existing route optimization is only a host-
Now there are also router-based solutions = available (cnet-homing, flows-distribution-and-handoff).
So, = I recommend we either provide a reference and qualify the term = "existing", or remove this statement.

          DMM = solutions MUST provide transparent mobility support above

I'd say "SHOULD". We may consider = some solutions that expose the IP address change to the apps, and expect = apps to do something with it. We haven't discussed them yet, but I don't = see a reason why we should shut the door on them.
Also: The present API-based approaches and the = following text suggests some awareness on the app is useful.
   Infrequent node mobility
   could be provided selectively, thus = reducing the amount of context
   maintained in the = network.

The motivation text does not seem = to match this requirement either:

        =   Motivation: The motivation of this requirement is to = enable
          more efficient = use of network resources and more efficient
        =   routing by not maintaining context at the mobility anchor = when
          there is no = such need.


I'd recommend we modify the = requirement as:

          = DMM solutions SHOULD provide transparent mobility support = above
          the IP layer = when needed.  Such transparency is needed, for
          network, an = application flow cannot cope with a change in the
          = stable home IP address or prefix for every application or at
          = mobility to the layers above IP.



          DMM solutions = SHOULD target IPv6 as the primary deployment
          = IPv4, in particular in situations where private IPv4 addresses
Is this the commonly-used language = regarding the treatment of IPv4 in IETF, or something we came up = with?
People may argue what is considered as = "tailoring".


        =   A DMM solution SHOULD first consider reusing and = extending
      =     IETF-standardized protocols before specifying new = protocols.

I'd say "MUST". How can we = not ? = :-)

Thanks!

Alper
<= div>







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 > > > > > > _________________________________________________ dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/__listinfo/dmm > > > > > > -- > > ------ Best Regards, Dapeng Liu From sgundave@cisco.com Sun Aug 25 20:04:07 2013 Return-Path: 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 BEF7D11E8138 for ; Sun, 25 Aug 2013 20:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.211 X-Spam-Level: X-Spam-Status: No, score=-9.211 tagged_above=-999 required=5 tests=[AWL=-1.387, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] 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 Mqhs6jislKu2 for ; Sun, 25 Aug 2013 20:04:02 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA1E11E813A for ; Sun, 25 Aug 2013 20:04:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=98324; q=dns/txt; s=iport; t=1377486240; x=1378695840; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=twTrX737I1uQ21NWWmrQECdgZhVhRjVw2fa2UO5UK/c=; b=GK26oJT70TV0yHAcGQRCkln8KXaaglMnsr84GD35eKuVzZe96W8De0eh Z7cGwnnjj+iTPWdli0wpyn6T2LxOYWO7qkY7/iTudA3nd/jcQuXPBCc3q KYHFe0jncFbtWk8D/ENaN1h4WobYBfxZAohVxyDN5dqNvble6HqwJkSf/ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEHAFDEGlKtJXG+/2dsb2JhbABQCoJDRDVRrgSJTYg/gR4WbQeCJgEEGAIBAkoBBAUBAgIVAQgSEAMICwEGKBEUAw4CBBMIE4dUAw8MlhCWfw2Jao1/gSUBCgYEgQ4sCwEKgxJ9A4dIg3OIWYFxgxaLCIUsgx6BaAkXIg X-IronPort-AV: E=Sophos;i="4.89,955,1367971200"; d="scan'208,217";a="251455219" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 26 Aug 2013 03:03:58 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7Q33wnP018434 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 26 Aug 2013 03:03:58 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.187]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Sun, 25 Aug 2013 22:03:57 -0500 From: "Sri Gundavelli (sgundave)" To: "dmm@ietf.org" Thread-Topic: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt Thread-Index: AQHOogjoa3/L9muNGkS5wozrKtEQEg== Date: Mon, 26 Aug 2013 03:03:38 +0000 Message-ID: <24C0F3E22276D9438D6F366EB89FAEA8116A4D4F@xmb-aln-x03.cisco.com> In-Reply-To: <1377486056.79906.YahooMailNeo@web163805.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.211] Content-Type: multipart/alternative; boundary="_000_24C0F3E22276D9438D6F366EB89FAEA8116A4D4Fxmbalnx03ciscoc_" MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 03:04:07 -0000 --_000_24C0F3E22276D9438D6F366EB89FAEA8116A4D4Fxmbalnx03ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Please see inline for some comments. Regards Sri Abstract This document defines the requirements for Distributed Mobility Management (DMM) in IPv6 deployments. The hierarchical structure in traditional wireless networks has led to deployment models which are in practice centralized. Mobility management with logically centralized mobility anchoring in current mobile networks is prone to suboptimal routing and raises scalability issues. Such centralized functions can lead to single points of failure and inevitably introduce longer delays and higher signaling loads for network operations related to mobility management. The objective is to enhance mobility management in order to meet the primary goals in network evolution, i.e., improve scalability, avoid single points of failure, enable transparent mobility support to upper layers only when needed, and so on. Distributed mobility management must be secure and may co-exist with existing network deployments and end hosts. [Sri] We don=92t need to argue against centralized model to justify distrib= uted model. In the absence of proper data to compare on both the approaches= , we cannot have such text. The pros and cons extend to both the models. P= lease simply state distributed model can be useful in certain deployments a= nd hence there is interest for this work. 1. Introduction In the past decade a fair number of mobility protocols have been standardized [RFC6275] [RFC5944] [RFC5380] [RFC6301] [RFC5213]. Although the protocols differ in terms of functions and associated message formats, we can identify a few key common features: o a centralized mobility anchor providing global reachability and an always-on experience to the user; o extensions to the base protocols to optimize handover performance while users roam across wireless cells; and o extensions to enable the use of heterogeneous wireless interfaces for multi-mode terminals (e.g. smartphones). [Sri] Currently defined mobility protocols support handovers and multiple a= ccess technologies ? Not sure, how these two "common features" make the ca= se for DMM If the point is about centralized anchor's, you don't need the = other two points. The presence of the centralized mobility anchor allows a mobile node to remain reachable after it has moved to a different network. The anchor point, among other tasks, ensures connectivity by forwarding packets destined to, or sent from, the mobile node. In practice, most of the deployed architectures today have a small number of centralized anchors managing the traffic of millions of mobile nodes. Compared with a distributed approach, a centralized approach is likely to have several issues or limitations affecting performance and scalability, which require costly network engineering to resolve. [Sri] All 3G/4G systems are based on this model and they are running fine. = Again, we don=92t need to argue against centralized model to justify distri= buted model. Please simply state distributed model can be useful in certain= deployments and hence the motivation for this work. To optimize handovers from the perspective of mobile nodes, the base protocols have been extended to efficiently handle packet forwarding between the previous and new points of attachment. These extensions are necessary when applications have stringent requirements in terms of delay. Notions of localization and distribution of local agents have been introduced to reduce signaling overhead at the centralized routing anchor point [Paper-Distributed.Centralized.Mobility]. Unfortunately, today we witness difficulties in getting such protocols deployed, resulting in sub-optimal choices for the network Operators. [Sri] I assume this is about hierarchical models / Chaining ? What are thes= e "difficulties in getting such protocols deployed" ? Moreover, the availability of multiple-interface host and the possibility of using several network interfaces simultaneously have motivated the development of even more protocol extensions to add more capabilities to the mobility management protocol. In the end, deployment is further complicated with the multitude of extensions. [Sri] Not sure I follow. Mobile IP protocols are in general access agnostic= . Not sure, what are the extensions that we have added on access-basis. As an effective transport method for multimedia data delivery, IP multicast support, including optimizations, have been introduced but by "patching-up" procedure after completing the design of reference mobility protocol, leading to network inefficiency and non-optimal routing. [Sri] Multicast related extensions have nothing to do with multi-access sup= port/host's capability to support multiple interfaces. Can you clarify ? Th= is text is not clear. Chan (Ed.), et al. Expires February 3, 2014 [Page 4] Internet-Draft DMM-Reqs August 2013 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 traffic offload (e.g. 3GPP work items LIPA/SIPTO [TS.23.401]) through alternative access networks (e.g. WLAN) [Paper- Mobile.Data.Offloading]. [Sri] Please add reference to IETF SIPTO doc, RFC6909, before 23.401 :) A gateway selection mechanism also takes the user proximity into account within EPC [TS.29303]. These mechanisms were not pursued in the past owing to charging and billing reasons. Assigning a gateway anchor node from a visited network in roaming scenario has until recently been done and are limited to voice services only. Charging and billing require solutions beyond the mobility protocol. Both traffic offloading and CDN mechanisms could benefit from the development of mobile architectures with fewer levels of routing hierarchy introduced into the data path by the mobility management system. This trend towards so-called "flat networks" works best for direct communications among peers in the same geographical area. Distributed mobility management in a truly flat mobile architecture would anchor the traffic closer to the point of attachment of the user. 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. [Sri] Is the intent of this is text is about routing based approaches ? If a mobile is attached to the network, it does have some state at the anch= or. Also, if we consider the home link in mobility models, there is no stat= e for the mobile node when it is at home. In case of DMM, or with the curre= nt models, if the gateway selection is based on the MN's location and when = there is no node mobility, there should not be any state at the anchor. CDM= A Infrequent node mobility coupled with application intelligence suggest that mobility support could be provided selectively, thus reducing the amount of context maintained in the network. The distributed mobility management (DMM) charter addresses two complementary aspects of mobility management procedures: the distribution of mobility anchors towards a more flat network and the dynamic activation/deactivation of mobility protocol support as an enabler to distributed mobility management. [Sri] Not sure, I follow this point on Dynamic activation/de-activation. Ca= n you clarify. The former aims at positioning mobility anchors (e.g., HA, LMA) closer to the user; ideally, mobility agents could be collocated with the first-hop Chan (Ed.), et al. Expires February 3, 2014 [Page 5] Internet-Draft DMM-Reqs August 2013 router. The latter, facilitated by the distribution of mobility anchors, aims at identifying when mobility support must be activated and identifying sessions that do not require mobility management support -- thus reducing the amount of state information that must be maintained in various mobility agents of the mobile network. The key idea is that dynamic mobility management relaxes some of the constraints of previously-standardized mobility management solutions and, by doing so, it can avoid the unnecessary establishment of mechanisms to forward traffic from an old to a new mobility anchor. [Sri] The DMM model should not exclude the case of centralized anchor and d= istributed data plane. This is sub-case of DMM. This document compares distributed mobility management with centralized mobility management in Section 3. The problems that can be addressed with DMM are summarized in Section 4. The mandatory requirements as well as the optional requirements are given in Section 5. Finally, security considerations are discussed in Section 6. The problem statement and the use cases [I-D.yokota-dmm-scenario] can be found in [Paper-Distributed.Mobility.Review]. 2. Conventions used in this document 2.1. Terminology All the general mobility-related terms and their acronyms used in this document are to be interpreted as defined in the Mobile IPv6 base specification [RFC6275], in the Proxy mobile IPv6 specification [RFC5213], and in Mobility Related Terminology [RFC3753]. These terms include the following: mobile node (MN), correspondent node (CN), and home agent (HA) as per [RFC6275]; local mobility anchor (LMA) and mobile access gateway (MAG) as per [RFC5213], and context as per [RFC3753]. In addition, this draft introduces the following term. Mobility context is the collection of information required to provide mobility management support for a given mobile node. [Sri] There needs to be some definition of "centrally deployed mobility anc= hor". This term is used through-out the document. What is central, what is = local ? Even in the so called, "centralized anchor models", a gateway can b= e enabled locally. Ex: LMA/MAG, PGW/SGW functions can exist on the same nod= e. 3. Centralized versus distributed mobility management Mobility management functions may be implemented at different layers of the protocol stack. At the IP (network) layer, they may reside in the network or in the mobile node. In particular, a network-based solution resides in the network only. It therefore enables mobility Chan (Ed.), et al. Expires February 3, 2014 [Page 6] Internet-Draft DMM-Reqs August 2013 for existing hosts and network applications which are already in deployment but lack mobility support. [Sri] Above text is bit confusing to me, specially the last sentence. Mobil= ity management can be based on client-based, or network-based. At the IP layer, a mobility management protocol supporting session continuity is typically based on the principle of distinguishing between identifier and routing address and maintaining a mapping between the two. [Sri] Replace, "Session continuity" with "IP mobility" or "IP address conti= nuity". In Mobile IP, the home address serves as an identifier of the device whereas the care-of-address (CoA) takes the role of the routing address. The binding between these two is maintained at the home agent (mobility anchor). If packets can be continuously delivered to a mobile node at its home address, then all sessions using that home address are unaffected even though the routing address (CoA) changes. [Sri] We should leave it at, "IP address mobility". The next two subsections explain centralized and distributed mobility management functions in the network. 3.1. Centralized mobility management In centralized mobility management, the mapping information between the persistent node identifier and the locator IP address of a mobile node (MN) is kept at a single mobility anchor. At the same time, packets destined to the MN are routed via this anchor. [Sri] Can we use the MIP terminology, home address/Care-of address terminol= ogy, as supposed to LISP terminology ? In other words, such mobility management systems are centralized in both the control plane and the data plane (mobile node IP traffic). Many existing mobility management deployments make use of centralized mobility anchoring in a hierarchical network architecture, as shown in Figure 1. Examples of such centralized mobility anchors are the home agent (HA) and local mobility anchor (LMA) in Mobile IPv6 [RFC6275] and Proxy Mobile IPv6 [RFC5213], respectively. Current cellular networks such as the Third Generation Partnership Project (3GPP) GPRS networks, CDMA networks, and 3GPP Evolved Packet System (EPS) networks employ centralized mobility management too. In particular, the Gateway GPRS Support Node (GGSN), Serving GPRS Support Node (SGSN) and Radio Network Controller (RNC) in the 3GPP GPRS hierarchical network, and the Packet Data Network Gateway (P-GW) and Serving Gateway (S-GW) in the 3GPP EPS network all act as anchors in a hierarchy. Chan (Ed.), et al. Expires February 3, 2014 [Page 7] Internet-Draft DMM-Reqs August 2013 3G GPRS 3GPP EPS MIP/PMIP +------+ +------+ +------+ | GGSN | | P-GW | |HA/LMA| +------+ +------+ +------+ /\ /\ /\ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ +------+ +------+ +------+ +------+ +------+ +------+ | SGSN | | SGSN | | S-GW | | S-GW | |MN/MAG| |MN/MAG| +------+ +------+ +------+ +------+ +------+ +------+ /\ /\ / \ / \ / \ / \ +---+ +---+ +---+ +---+ |RNC| |RNC| |RNC| |RNC| +---+ +---+ +---+ +---+ Figure 1. Centralized mobility management. 3.2. Distributed mobility management Mobility management functions may also be distributed to multiple networks as shown in Figure 2, so that a mobile node in any of these networks may be served by a nearby mobility function (MF). +------+ +------+ +------+ +------+ | MF | | MF | | MF | | MF | +------+ +------+ +------+ +------+ | +----+ | MN | +----+ Figure 2. Distributed mobility management. Mobility management may be partially or fully distributed. In the former case only the data plane is distributed. Fully distributed mobility management implies that both the data plane and the control plane are distributed. Such concepts of data and control plane separation are not yet described in the IETF developed mobility protocols so far but are described in detail in [I-D.yokota-dmm- scenario]. While mobility management can be distributed, it is not necessary for other functions such as subscription management, Chan (Ed.), et al. Expires February 3, 2014 [Page 8] Internet-Draft DMM-Reqs August 2013 subscription database, and network access authentication to be similarly distributed. [Sri] The case of centralized CP and distributed DP is covered in IETF docs= , http://datatracker.ietf.org/doc/draft-wakikawa-netext-pmip-cp-up-separation= / This is a variant of the DMM models. A distributed mobility management scheme for flat IP-based mobile network architecture consisting of access nodes is proposed in [Paper-Distributed.Dynamic.Mobility]. Its benefits over centralized mobility management are shown through simulations in [Paper- Distributed.Centralized.Mobility]. Moreover, the (re)use and extension of existing protocols in the design of both fully distributed mobility management [Paper-Migrating.Home.Agents] [Paper- Distributed.Mobility.SAE] and partially distributed mobility management [Paper-Distributed.Mobility.PMIP] [Paper- Distributed.Mobility.MIP] have been reported in the literature. Therefore, before designing new mobility management protocols for a future flat IP architecture, it is recommended to first consider whether existing mobility management protocols can be extended to serve a flat IP architecture. [Sri] Lot of unnecessary text in this document. Not sure, we need all of th= is text. 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. 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 C= DN example is incorrect. 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 addre= sses and have the content locally accessed. There are simply two many consi= derations 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. 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. Chan (Ed.), et al. Expires February 3, 2014 [Page 9] Internet-Draft DMM-Reqs August 2013 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 subs= criber, as "Simple IP", or "Mobile IP". A PDSN can assign a local IP addres= s and it does not have to be the home address. Network does have this intel= ligence, but what is missing is the client's ability to pick the correct ty= pe of IP address, among different IP addresses. The network is also the mis= sing the aspect of marking those addresses with proper properties. The curr= ently active drafts in IETF are to address this issue. We should talk about= these missing semantics. draft-bhandari-dhc-class-based-prefix-05 draft-korhonen-6man-prefix-properties-02 PS6: (Related problem) Mobility signaling overhead with peer-to-peer communication Wasting resources when mobility signaling (e.g., maintenance of the tunnel, keep alive signaling, etc.) is not turned off for peer-to-peer communication. Peer-to-peer communications have particular traffic patterns that often do not benefit from mobility support from the network. Thus, the associated mobility support signaling (e.g., maintenance of the tunnel, keep alive signaling, etc.) wastes network resources for no application gain. In such a case, it is better to enable mobility support selectively. [Sri] How is PS6 different from PS5 ? We talk about application's ability t= o pick the address with or without mobility properties in PS5. So, the traf= fic patterns can be localized based on the application requirements. But, e= ven if we take the argument that mobility is not required, operator needs v= isibility into these flows and so they can charge. Again, we have 6705 and= 6909 for adjusting to those traffic patterns. So, this P without those con= siderations is incomplete. PS7: (Related problem) Deployment with multiple mobility solutions There are already many variants and extensions of MIP. Deployment of new mobility management solutions can be challenging, and debugging difficult, when they must co-exist with solutions already in the field. PS8: Duplicate multicast traffic IP multicast distribution over architectures using IP mobility solutions (e.g. RFC6224) may lead to convergence of duplicated multicast subscriptions towards the downstream tunnel entity (e.g. MAG in PMIPv6). Concretely, when multicast subscription for individual mobile nodes is coupled with mobility tunnels (e.g. PMIPv6 tunnel), duplicate multicast subscription(s) is Chan (Ed.), et al. Expires February 3, 2014 [Page 10] Internet-Draft DMM-Reqs August 2013 prone to be received through different upstream paths. This problem may also exist or be more severe in a distributed mobility environment. [Sri] Is this for MN's from different LMA's attached to the same MAG ? 5. Requirements After comparing distributed mobility management against centralized deployment in Section 3, this section identifies the following requirements: 5.1. Distributed processing REQ1: Distributed processing IP mobility, network access and routing solutions provided by DMM MUST enable distributed processing for mobility management so that traffic does not need to traverse centrally deployed mobility anchors and thereby avoid non-optimal routes. Motivation: This requirement is motivated by current trends in network evolution: (a) it is cost- and resource-effective to cache and distribute content by combining distributed mobility anchors with caching systems (e.g., CDN); (b) the significantly larger number of mobile nodes and flows call for improved scalability; (c) single points of failure are avoided in a distributed system; (d) threats against centrally deployed anchors, e.g., home agent and local mobility anchor, are mitigated in a distributed system. This requirement addresses the problems PS1, PS2, PS3, and PS4 described in Section 4. (Existing route optimization is only a host- based solution. On the other hand, localized routing with PMIPv6 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.) [Sri] I'm still stuck on the CDN example driving this requirement. 5.2. Transparency to Upper Layers when needed REQ2: Transparency to Upper Layers when needed DMM solutions MUST provide transparent mobility support above the IP layer when needed. Such transparency is needed, for example, when, upon change of point of attachment to the network, an application flow cannot cope with a change in the IP address. However, it is not always necessary to maintain a stable home IP address or prefix for every application or at all times for a mobile node. [Sri] Please reflect the two key aspects of this requirement: * Network can assign IP addresses with different properties; It carries those= properties * Applications have different requirements and will pick the address with the= correct property. Chan (Ed.), et al. Expires February 3, 2014 [Page 11] Internet-Draft DMM-Reqs August 2013 Motivation: The motivation of this requirement is to enable more efficient use of network resources and more efficient routing by not maintaining context at the mobility anchor when there is no such need. This requirement addresses the problem PS5 as well as the related problem PS6 stated in Section 4. 5.3. IPv6 deployment REQ3: IPv6 deployment DMM solutions SHOULD target IPv6 as the primary deployment environment and SHOULD NOT be tailored specifically to support IPv4, in particular in situations where private IPv4 addresses and/or NATs are used. Motivation: This requirement conforms to the general orientation of IETF work. DMM deployment is foreseen in mid- to long-term horizon, when IPv6 is expected to be far more common than today. This requirement avoids the unnecessarily complexity in solving the problems in Section 4 for IPv4, which will not be able to use some of the IPv6-specific features. 5.4. Existing mobility protocols REQ4: Existing mobility protocols A DMM solution SHOULD first consider reusing and extending IETF-standardized protocols before specifying new protocols. Motivation: Reuse of existing IETF work is more efficient and less error-prone. This requirement attempts to avoid the need of new protocols development and therefore their potential problems of being time- consuming and error-prone. 5.5. Co-existence REQ5: Co-existence with deployed networks and hosts The DMM solution MUST be able to co-exist with existing network deployments and end hosts. For example, depending on the environment in which DMM is deployed, DMM solutions may need to be compatible with other deployed mobility protocols Chan (Ed.), et al. Expires February 3, 2014 [Page 12] Internet-Draft DMM-Reqs August 2013 or may need to co-exist with a network or mobile hosts/routers that do not support DMM protocols. The mobile node may also move between different access networks, where some of them may support neither DMM nor another mobility protocol. Furthermore, a DMM solution SHOULD work across different networks, possibly operated as separate administrative domains, when allowed by the trust relationship between them. Motivation: (a) to preserve backwards compatibility so that existing networks and hosts are not affected and continue to function as usual, and (b) enable inter-domain operation if desired. This requirement addresses the related problem PS7 described in Section 4. 5.6. Security considerations REQ6: Security considerations A DMM solution MUST not introduce new security risks or amplify existing security risks against which the existing security mechanisms/protocols cannot offer sufficient protection. Motivation: Various attacks such as impersonation, denial of service, man-in-the-middle attacks, and so on, may be launched in a DMM deployment. For instance, an illegitimate node may attempt to access a network providing DMM. Another example is that a malicious node can forge a number of signaling messages thus redirecting traffic from its legitimate path. Consequently, the specific node is under a denial of service attack, whereas other nodes do not receive their traffic. Accordingly, security mechanisms/protocols providing access control, integrity, authentication, authorization, confidentiality, etc. can be used to protect the DMM entities as they are already used to protect against existing networks and existing mobility protocols defined in IETF. In addition, end-to-end security measures between communicating nodes may already be used when deploying existing mobility protocols where the signaling messages travel over the Internet. For instance, EAP-based authentication can be used for network access security, while IPsec can be used for end-to-end security. When the existing security mechanisms/protocols are applied to protect the DMM entities, the security risks that may be introduced by DMM MUST be considered to be eliminated. Else the security protection would be degraded in the DMM solution versus in existing mobility protocols. Chan (Ed.), et al. Expires February 3, 2014 [Page 13] Internet-Draft DMM-Reqs August 2013 This requirement prevents a DMM solution from introducing uncontrollable problems of potentially insecure mobility management protocols which make deployment infeasible because platforms conforming to the protocols are at risk for data loss and numerous other dangers, including financial harm to the users. 5.7. Multicast REQ7: Multicast considerations DMM SHOULD consider multicast early so that solutions can be developed not only to provide IP mobility support when it is needed, but also to avoid network inefficiency issues in multicast traffic delivery (such as duplicate multicast subscriptions towards the downstream tunnel entities). The multicast solutions should therefore avoid restricting the management of all IP multicast traffic to a single host through a dedicated (tunnel) interface on multicast-capable access routers. Motivation: Existing multicast deployment have been introduced after completing the design of the reference mobility protocol, then optimization and extensions have been followed by "patching-up" procedure, thus leading to network inefficiency and non-optimal routing. The multicast solutions should therefore be required to consider efficiency nature in multicast traffic delivery. This requirement addresses the problems PS1 and PS8 described in Section 4. 6. Security Considerations Please refer to the discussion under Security requirement in Section 5.6. 7. IANA Considerations None 8. Co-authors and Contributors This problem statement document is a joint effort among the numerous participants. Each individual has made significant contributions to this work and have been listed as co-authors. Chan (Ed.), et al. Expires February 3, 2014 [Page 14] Internet-Draft DMM-Reqs August 2013 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [I-D.yokota-dmm-scenario] Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case scenarios for Distributed Mobility Management", draft-yokota-dmm-scenario-00 (work in progress), October 2010. [Paper-Distributed.Centralized.Mobility] Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed or Centralized Mobility", Proceedings of Global Communications Conference (GlobeCom), December 2009. [Paper-Distributed.Dynamic.Mobility] Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed Dynamic Mobility Management Scheme Designed for Flat IP Architectures", Proceedings of 3rd International Conference on New Technologies, Mobility and Security (NTMS), 2008. [Paper-Distributed.Mobility.MIP] Chan, H., "Distributed Mobility Management with Mobile IP", Proceedings of IEEE International Communication Conference (ICC) Workshop on Telecommunications: from Research to Standards, June 2012. [Paper-Distributed.Mobility.PMIP] Chan, H., "Proxy Mobile IP with Distributed Mobility Anchors", Proceedings of GlobeCom Workshop on Seamless Wireless Mobility, December 2010. [Paper-Distributed.Mobility.Review] Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu, "Distributed and Dynamic Mobility Management in Mobile Internet: Current Approaches and Issues, Journal of Communications, vol. 6, no. 1, pp. 4-15, Feb 2011.", Proceedings of GlobeCom Workshop on Seamless Wireless Mobility, February 2011. [Paper-Distributed.Mobility.SAE] Fisher, M., Anderson, F., Kopsel, A., Schafer, G., and M. Chan (Ed.), et al. Expires February 3, 2014 [Page 15] Internet-Draft DMM-Reqs August 2013 Schlager, "A Distributed IP Mobility Approach for 3G SAE", Proceedings of the 19th International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC), 2008. [Paper-Locating.User] Kirby, G., "Locating the User", Communication International, 1995. [Paper-Migrating.Home.Agents] Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home Agents Towards Internet-scale Mobility Deployments", Proceedings of the ACM 2nd CoNEXT Conference on Future Networking Technologies, December 2006. [Paper-Mobile.Data.Offloading] Lee, K., Lee, J., Yi, Y., Rhee, I., and S. Chong, "Mobile Data Offloading: How Much Can WiFi Deliver?", SIGCOMM 2010, 2010. [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008. [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010. [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. [RFC6301] Zhu, Z., Wakikawa, R., and L. Zhang, "A Survey of Mobility Support in the Internet", RFC 6301, July 2011. [TS.23.401] 3GPP, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", 3GPP TR 23.401 10.10.0, March 2013. [TS.29303] 3GPP, "Domain Name System Procedures; Stage 3", 3GPP TR 23.303 11.2.0, September 2012. Chan (Ed.), et al. Expires February 3, 2014 [Page 16] Internet-Draft DMM-Reqs August 2013 Authors' Addresses H Anthony Chan (editor) Huawei Technologies (more co-authors on P. 17) 5340 Legacy Dr. Building 3, Plano, TX 75024, USA Email: h.a.chan@ieee.org Dapeng Liu China Mobile Unit2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China Email: liudapeng@chinamobile.com Pierrick Seite Orange 4, rue du Clos Courtel, BP 91226, Cesson-Sevigne 35512, France Email: pierrick.seite@orange.com Hidetoshi Yokota KDDI Lab 2-1-15 Ohara, Fujimino, Saitama, 356-8502 Japan Email: yokota@kddilabs.jp Jouni Korhonen Nokia Siemens Networks Email: jouni.korhonen@nsn.com - Charles E. Perkins Huawei Technologies Email: charliep@computer.org - Melia Telemaco Alcatel-Lucent Bell Labs Email: telemaco.melia@alcatel-lucent.com - Elena Demaria Telecom Italia via G. Reiss Romoli, 274, TORINO, 10148, Italy Email: elena.demaria@telecomitalia.it - Jong-Hyouk Lee RSM Department, Telecom Bretagne Cesson-Sevigne, 35512, France Email: jh.lee@telecom-bretagne.eu - Chan (Ed.), et al. Expires February 3, 2014 [Page 17] Internet-Draft DMM-Reqs August 2013 Kostas Pentikousis Huawei Technologies Carnotstr. 4 10587 Berlin, Germany Email: k.pentikousis@huawei.com - Tricci So ZTE Email: tso@zteusa.com - Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30, Leganes, Madrid 28911, Spain Email: cjbc@it.uc3m.es - Peter McCann Huawei Technologies Email: PeterMcCann@huawei.com - Seok Joo Koh Kyungpook National University, Korea Email: sjkoh@knu.ac.kr - Wen Luo ZTE No.68, Zijinhua RD,Yuhuatai District, Nanjing, Jiangsu 210012, China Email: luo.wen@zte.com.cn - Sri Gundavelli sgundave@cisco.com - Marco Liebsch NEC Laboratories Europe Email: liebsch@neclab.eu - Carl Williams MCSR Labs Email: carlw@mcsr-labs.org - Seil Jeon Instituto de Telecomunicacoes, Aveiro Email: seiljeon@av.it.pt - Sergio Figueiredo Universidade de Aveiro Email: sfigueiredo@av.it.pt - Stig Venaas Email: stig@venaas.com Chan (Ed.), et al. Expires February 3, 2014 [Page 18] Internet-Draft DMM-Reqs August 2013 - Luis Miguel Contreras Murillo Email: lmcm@tid.es - Juan Carlos Zuniga Email: JuanCarlos.Zuniga@InterDigital.com - Alexandru Petrescu Email: alexandru.petrescu@gmail.com - Georgios Karagiannis Email: g.karagiannis@utwente.nl - Julien Laganier jlaganier@juniper.net - Wassim Michel Haddad Wassam.Haddad@ericsson.com - Dirk von Hugo Dirk.von-Hugo@telekom.de - Ahmad Muhanna amuhanna@awardsolutions.com - Byoung-Jo Kim ATT Labs macsbug@research.att.com - Hassan Aliahmad Orange hassan.aliahmad@orange.com - Chan (Ed.), et al. Expires February 3, 2014 [Page 19] --_000_24C0F3E22276D9438D6F366EB89FAEA8116A4D4Fxmbalnx03ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Please s= ee inline for some comments.

Regards<= /span>
Sri


Abstract

   This document defines the requirements for Distributed Mobility
   Management (DMM) in IPv6 deployments.  The hierarchical structure in
   traditional wireless networks has led to deployment models which are
   in practice centralized.  Mobility management with logically
   centralized mobility anchoring in current mobile networks is prone to
   suboptimal routing and raises scalability issues.  Such centralized
   functions can lead to single points of failure and inevitably
   introduce longer delays and higher signaling loads for network
   operations related to mobility management.  The objective is to
   enhance mobility management in order to meet the primary goals in
   network evolution, i.e., improve scalability, avoid single points of
   failure, enable transparent mobility support to upper layers only
   when needed, and so on.  Distributed mobility management must be
   secure and may co-exist with existing network deployments and end
   hosts.

[Sri] We don=92t need to argue against centralized model=
 to justify distributed model. In the absence of proper data to compare on =
both the approaches, we cannot have such text.  The pros and cons extend to=
 both the models. Please simp=
ly state distributed model can be useful in certain deployments and hence t=
here is interest for this work.




1.  Introduction

   In the past decade a fair number of mobility protocols have been
   standardized [RFC6275] [RFC5944] [RFC5380] [RFC6301] [RFC5213].
   Although the protocols differ in terms of functions and associated
   message formats, we can identify a few key common features:

   o  a centralized mobility anchor providing global reachability and an
      always-on experience to the user;

   o  extensions to the base protocols to optimize handover performance
      while users roam across wireless cells; and

   o  extensions to enable the use of heterogeneous wireless interfaces
      for multi-mode terminals (e.g. smartphones).



[Sri] Currently defined mo=
bility protocols support handovers and multiple access technologies  ? Not =
sure, how these two "common features" make the case for DMM  =
If the point is about centralized anchor's, you don't need the othe=
r two points. 





   The p=
resence of the centralized mobility anchor allows a mobile node
   to remain reachable after it has moved to a different network.  The
   anchor point, among other tasks, ensures connectivity by forwarding
   packets destined to, or sent from, the mobile node.  In practice,
   most of the deployed architectures today have a small number of
   centralized anchors managing the traffic of millions of mobile nodes.
   Compared with a distributed approach, a centralized approach is
   likely to have several issues or limitations affecting performance
   and scalability, which require costly network engineering to resolve.



=
[Sri] All 3G/4G systems are based on this model and they are running fine. =
Again=
, we don=92t need to argue against centralized model to justify distributed=
 model. Please simply state distributed model can be useful in certain depl=
oyments and hence the motivation for this work.







   To op=
timize handovers from the perspective of mobile nodes, the base
   protocols have been extended to efficiently handle packet forwarding
   between the previous and new points of attachment.  These extensions
   are necessary when applications have stringent requirements in terms
   of delay.  Notions of localization and distribution of local agents
   have been introduced to reduce signaling overhead at the centralized
   routing anchor point [Paper-Distributed.Centralized.Mobility].
   Unfortunately, today we witness difficulties in getting such
   protocols deployed, resulting in sub-optimal choices for the network
   Operators.


[Sri] I assume this is about hierarchical models / Chain=
ing ? What are these "difficulties in getting such protocols deployed&=
quot; ?   


   Moreo=
ver, the availability of multiple-interface host and the
   possibility of using several network interfaces simultaneously have
   motivated the development of even more protocol extensions to add
   more capabilities to the mobility management protocol.  In the end,
   deployment is further complicated with the multitude of extensions.

<=
b>[Sri] Not sure I follow. Mobile IP protocols are in general access agnost=
ic. Not sure, what are the extensions that we have added on access-basis.

=






  =
 As an effective transport method for multimedia data delivery, IP
   multicast support, including optimizations, have been introduced but
   by "patching-up" procedure after completing the design of refe=
rence
   mobility protocol, leading to network inefficiency and non-optimal
   routing.

[Sri] Multicast related extensions have nothing to=
 do with multi-access support/host's capability to support multiple interfa=
ces. Can you clarify ? This text is not clear.

Chan (Ed=
.), et al.      Expires February 3, 2014                [Page 4]

Internet-Draft                  DMM-Reqs                     August 2013


   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 traffic offload (e.g. 3GPP work items LIPA/SIPTO
   [TS.23.401]) through alternative access networks (e.g.  WLAN) [Paper-
   Mobile.Data.Offloading].  


[Sri] Please add reference to IETF SIPTO doc, RFC6909, b=
efore 23.401 :)





A gatewa=
y selection mechanism also takes
   the user proximity into account within EPC [TS.29303].  These
   mechanisms were not pursued in the past owing to charging and billing
   reasons.   Assigning a gateway anchor node from a visited network i=
n


   roami=
ng scenario has until recently been done and are limited to
   voice services only.  Charging and billing require solutions beyond
   the mobility protocol.



   Both =
traffic offloading and CDN mechanisms could benefit from the
   development of mobile architectures with fewer levels of routing
   hierarchy introduced into the data path by the mobility management
   system.  This trend towards so-called "flat networks" works be=
st for
   direct communications among peers in the same geographical area.
   Distributed mobility management in a truly flat mobile architecture
   would anchor the traffic closer to the point of attachment of the
   user.

   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 u=
nnecessary costs for the service provider. 


[Sri]  Is the intent of this is text is about routing based approaches ?=

If a mobile is attached to t=
he network, it does have some state at the anchor. Also, if we consider the=
 home link in mobility models, there is no state for the mobile node when i=
t is at home. In case of DMM, or with the current models, if the gateway se=
lection is based on the MN's location and when there is no node mobility, t=
here should not be any state at the anchor. CDMA




 Infrequ=
ent node mobility
   coupled with application intelligence suggest that mobility support
   could be provided selectively, thus reducing the amount of context
   maintained in the network.

   The distributed mobility management (DMM) charter addresses two
   complementary aspects of mobility management procedures: the
   distribution of mobility anchors towards a more flat network and the
   dynamic activation/deactivation of mobility protocol support as an
   enabler to distributed mobility management.  


[Sri] Not sure, I follow this point on Dynamic activatio=
n/de-activation. Can you clarify.





The form=
er aims at
   positioning mobility anchors (e.g., HA, LMA) closer to the user;
   ideally, mobility agents could be collocated with the first-hop



Chan (Ed.), et al.      Expires February 3, 2014                [Page 5]

Internet-Draft                  DMM-Reqs                     August 2013


   router.  The latter, facilitated by the distribution of mobility
   anchors, aims at identifying when mobility support must be activated
   and identifying sessions that do not require mobility management
   support -- thus reducing the amount of state information that must be
   maintained in various mobility agents of the mobile network.  The key
   idea is that dynamic mobility management relaxes some of the
   constraints of previously-standardized mobility management solutions
   and, by doing so, it can avoid the unnecessary establishment of
   mechanisms to forward traffic from an old to a new mobility anchor.



[Sri] The DMM model should not exclude the case of centr=
alized anchor and distributed data plane. This is sub-case of DMM. 





   This =
document compares distributed mobility management with
   centralized mobility management in Section 3.  The problems that can
   be addressed with DMM are summarized in Section 4.  The mandatory
   requirements as well as the optional requirements are given in
   Section 5.  Finally, security considerations are discussed in Section
   6.

   The problem statement and the use cases [I-D.yokota-dmm-scenario] can
   be found in [Paper-Distributed.Mobility.Review].


2.  Conventions used in this document

2.1.  Terminology

   All the general mobility-related terms and their acronyms used in
   this document are to be interpreted as defined in the Mobile IPv6
   base specification [RFC6275], in the Proxy mobile IPv6 specification
   [RFC5213], and in Mobility Related Terminology [RFC3753].  These
   terms include the following: mobile node (MN), correspondent node
   (CN), and home agent (HA) as per [RFC6275]; local mobility anchor
   (LMA) and mobile access gateway (MAG) as per [RFC5213], and context
   as per [RFC3753].

   In addition, this draft introduces the following term.

   Mobility context

      is the collection of information required to provide mobility
      management support for a given mobile node.




[Sri] There needs to be some definition of "central=
ly deployed mobility anchor". This term is used through-out the docume=
nt. What is central, what is local ? Even in the so called, "centraliz=
ed anchor models", a gateway can be enabled locally. Ex: LMA/MAG, PGW/=
SGW functions can exist on the same node. 





3.  Cent=
ralized versus distributed mobility management

   Mobility management functions may be implemented at different layers
   of the protocol stack.  At the IP (network) layer, they may reside in
   the network or in the mobile node.  In particular, a network-based
   solution resides in the network only.  It therefore enables mobility



Chan (Ed.), et al.      Expires February 3, 2014                [Page 6]

Internet-Draft                  DMM-Reqs                     August 2013


   for existing hosts and network applications which are already in
   deployment but lack mobility support.





[Sri] Above text is bit confusing to me, specially the l=
ast sentence. Mobility management can be based on client-based, or network-=
based.=20

   At the IP layer, a mobility management protocol supporting session
   continuity is typically based on the principle of distinguishing
   between identifier and routing address and maintaining a mapping
   between the two.  


[Sri] Replace, "Session continuity" with "I=
P mobility" or "IP address continuity". 

In Mobil=
e IP, the home address serves as an
   identifier of the device whereas the care-of-address (CoA) takes the
   role of the routing address.  The binding between these two is
   maintained at the home agent (mobility anchor).  If packets can be
   continuously delivered to a mobile node at its home address, then all
   sessions using that home address are unaffected even though the
   routing address (CoA) changes.



[Sri] We should leave it at, "IP address mobility&q=
uot;.


   The n=
ext two subsections explain centralized and distributed mobility
   management functions in the network.

3.1.  Centralized mobility management

   In centralized mobility management, the mapping information between
   the persistent node identifier and the locator IP address of a mobile
   node (MN) is kept at a single mobility anchor.  At the same time,
   packets destined to the MN are routed via this anchor.


[Sri] Can we use the MIP terminology, home address/Care-of=
 address terminology, as supposed to LISP terminology ? <=
/pre>




  In oth=
er
   words, such mobility management systems are centralized in both the
   control plane and the data plane (mobile node IP traffic).

   Many existing mobility management deployments make use of centralized
   mobility anchoring in a hierarchical network architecture, as shown
   in Figure 1.  Examples of such centralized mobility anchors are the
   home agent (HA) and local mobility anchor (LMA) in Mobile IPv6
   [RFC6275] and Proxy Mobile IPv6 [RFC5213], respectively.  Current
   cellular networks such as the Third Generation Partnership Project
   (3GPP) GPRS networks, CDMA networks, and 3GPP Evolved Packet System
   (EPS) networks employ centralized mobility management too.  In
   particular, the Gateway GPRS Support Node (GGSN), Serving GPRS
   Support Node (SGSN) and Radio Network Controller (RNC) in the 3GPP
   GPRS hierarchical network, and the Packet Data Network Gateway (P-GW)
   and Serving Gateway (S-GW) in the 3GPP EPS network all act as anchors
   in a hierarchy.














Chan (Ed.), et al.      Expires February 3, 2014                [Page 7]

Internet-Draft                  DMM-Reqs                     August 2013


         3G GPRS                 3GPP EPS                MIP/PMIP
         +------+                +------+                &#=
43;------+
         | GGSN |                | P-GW |                |HA/LMA|
         +------+                +------+                &#=
43;------+
            /\                      /\                      /\
           /  \                    /  \                    /  \
          /    \                  /    \                  /    \
         /      \                /      \                /      \
        /        \              /        \              /        \
       /          \            /          \            /          \
      /            \          /            \          /            \
  +------+      +------+  +------+      +------=
+  +------+      +------+
  | SGSN |      | SGSN |  | S-GW |      | S-GW |  |MN/MAG|      |MN/MAG|
  +------+      +------+  +------+      +------=
+  +------+      +------+
     /\            /\
    /  \          /  \
   /    \        /    \
+---+  +---+  +---+  +---+
|RNC|  |RNC|  |RNC|  |RNC|
+---+  +---+  +---+  +---+

   Figure 1.  Centralized mobility management.

3.2.  Distributed mobility management

   Mobility management functions may also be distributed to multiple
   networks as shown in Figure 2, so that a mobile node in any of these
   networks may be served by a nearby mobility function (MF).


                    +------+  +------+  +------+  &=
#43;------+
                    |  MF  |  |  MF  |  |  MF  |  |  MF  |
                    +------+  +------+  +------+  &=
#43;------+
                                           |
                                         +----+
                                         | MN |
                                         +----+

   Figure 2.  Distributed mobility management.






   M=
obility management may be partially or fully distributed.  In the
   former case only the data plane is distributed.  Fully distributed
   mobility management implies that both the data plane and the control
   plane are distributed.  Such concepts of data and control plane
   separation are not yet described in the IETF developed mobility
   protocols so far but are described in detail in [I-D.yokota-dmm-
   scenario].  While mobility management can be distributed, it is not
   necessary for other functions such as subscription management,



Chan (Ed.), et al.      Expires February 3, 2014                [Page 8]

Internet-Draft                  DMM-Reqs                     August 2013


   subscription database, and network access authentication to be
   similarly distributed.



[Sri] The case =
of centralized CP and distributed DP is covered in IETF docs, 

http://datatracker.ietf.org/doc/=
draft-wakikawa-netext-pmip-cp-up-separation/


This is a variant of the DMM models. 


   A distributed mobility management scheme for flat IP-based mobile
   network architecture consisting of access nodes is proposed in
   [Paper-Distributed.Dynamic.Mobility].  Its benefits over centralized
   mobility management are shown through simulations in [Paper-
   Distributed.Centralized.Mobility].  Moreover, the (re)use and
   extension of existing protocols in the design of both fully
   distributed mobility management [Paper-Migrating.Home.Agents] [Paper-
   Distributed.Mobility.SAE] and partially distributed mobility
   management [Paper-Distributed.Mobility.PMIP] [Paper-
   Distributed.Mobility.MIP] have been reported in the literature.
   Therefore, before designing new mobility management protocols for a
   future flat IP architecture, it is recommended to first consider
   whether existing mobility management protocols can be extended to
   serve a flat IP architecture.



[Sri] Lot of unnecessary text in this =
document. Not sure, we need all of this text.




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] "lon=
ger route" ?  I assume this is about routing/tx delay. Please re-word.=






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 iss=
ue ? May be the CDN example is incorrect. 






   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 routi=
ng. We have that in the form of 6705 and 6909. The other approach is give l=
ocalized IP addresses and have the content locally accessed. There are simp=
ly two many considerations and points may be valid, but when we bring all t=
hose assumptions. We are bringing these points in a less logical manner wit=
hout stating the assumptions.



   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.




Chan (Ed.), et al.      Expires February 3, 2014                [Page 9]

Internet-Draft                  DMM-Reqs                     August 2013


   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]  Mo=
bility systems today do support the aspect of service for the subscriber, a=
s "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 mi=
ssing 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 mark=
ing those addresses with proper properties. The currently active drafts in =
IETF are to address this issue. We should talk about these missing semantic=
s.


draft-bhandari-dhc-class-based-prefix-05  


=
draft-korhonen-6man-prefix-properties-02






   PS6:  (Related problem) Mobility signaling overhead with peer-to-peer
         communication

         Wasting resources when mobility signaling (e.g., maintenance of
         the tunnel, keep alive signaling, etc.) is not turned off for
         peer-to-peer communication.  Peer-to-peer communications have
         particular traffic patterns that often do not benefit from
         mobility support from the network.  Thus, the associated
         mobility support signaling (e.g., maintenance of the tunnel,
         keep alive signaling, etc.) wastes network resources for no
         application gain.  In such a case, it is better to enable
         mobility support selectively.



[Sri] How is PS=
6 different from PS5 ? We talk about application's ability to pick the addr=
ess with or without mobility properties in PS5. So, the traffic patterns ca=
n be localized based on the application requirements. But, even if we take =
the argument that mobility is not required, operator needs visibility into =
these flows and so they can charge.  Again, we have 6705 and 6909 for =
adjusting to those traffic patterns. So, this P without those consid=
erations is incomplete.



=




   PS7:  (Related problem) Deployment with multiple mobility solutions

         There are already many variants and extensions of MIP.
         Deployment of new mobility management solutions can be
         challenging, and debugging difficult, when they must co-exist
         with solutions already in the field.







   PS8:  Duplicate multicast traffic

         IP multicast distribution over architectures using IP mobility
         solutions (e.g.  RFC6224) may lead to convergence of duplicated
         multicast subscriptions towards the downstream tunnel entity
         (e.g.  MAG in PMIPv6).  Concretely, when multicast subscription
         for individual mobile nodes is coupled with mobility tunnels
         (e.g.  PMIPv6 tunnel), duplicate multicast subscription(s) is



Chan (Ed.), et al.      Expires February 3, 2014               [Page 10]

Internet-Draft                  DMM-Reqs                     August 2013


         prone to be received through different upstream paths.  This
         problem may also exist or be more severe in a distributed
         mobility environment.

[Sri] Is this for MN's from different LMA's atta=
ched to the same MAG ?



5.  Requirements

   After comparing distributed mobility management against centralized
   deployment in Section 3, this section identifies the following
   requirements:

5.1.  Distributed processing

   REQ1:  Distributed processing

          IP mobility, network access and routing solutions provided by
          DMM MUST enable distributed processing for mobility management
          so that traffic does not need to traverse centrally deployed
          mobility anchors and thereby avoid non-optimal routes.

          Motivation: This requirement is motivated by current trends in
          network evolution: (a) it is cost- and resource-effective to
          cache and distribute content by combining distributed mobility
          anchors with caching systems (e.g., CDN); (b) the
          significantly larger number of mobile nodes and flows call for
          improved scalability; (c) single points of failure are avoided
          in a distributed system; (d) threats against centrally
          deployed anchors, e.g., home agent and local mobility anchor,
          are mitigated in a distributed system.

   This requirement addresses the problems PS1, PS2, PS3, and PS4
   described in Section 4.  (Existing route optimization is only a host-
   based solution.  On the other hand, localized routing with PMIPv6
   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.)



=



[Sri] I'm still=
 stuck on the CDN example driving this requirement.




5.2.  Transparency to Upper Layers when needed

   REQ2:  Transparency to Upper Layers when needed

          DMM solutions MUST provide transparent mobility support above
          the IP layer when needed.  Such transparency is needed, for
          example, when, upon change of point of attachment to the
          network, an application flow cannot cope with a change in the
          IP address.  However, it is not always necessary to maintain a
          stable home IP address or prefix for every application or at
          all times for a mobile node.




[Sri] Please reflect the two key aspects of this requireme=
nt:


    

  • 

    Network can assign IP addresses with different properties;=
 It carries those properties
    

  • 

    Applications have different requirements and will pick the=
 address with the correct property.
    





Chan (Ed.), et al.      Expires February 3, 2014               [Page 11]

Internet-Draft                  DMM-Reqs                     August 2013


          Motivation: The motivation of this requirement is to enable
          more efficient use of network resources and more efficient
          routing by not maintaining context at the mobility anchor when
          there is no such need.



   T=
his requirement addresses the problem PS5 as well as the related
   problem PS6 stated in Section 4.

5.3.  IPv6 deployment

   REQ3:  IPv6 deployment

          DMM solutions SHOULD target IPv6 as the primary deployment
          environment and SHOULD NOT be tailored specifically to support
          IPv4, in particular in situations where private IPv4 addresses
          and/or NATs are used.

          Motivation: This requirement conforms to the general
          orientation of IETF work.  DMM deployment is foreseen in mid-
          to long-term horizon, when IPv6 is expected to be far more
          common than today.

   This requirement avoids the unnecessarily complexity in solving the
   problems in Section 4 for IPv4, which will not be able to use some of
   the IPv6-specific features.

5.4.  Existing mobility protocols

   REQ4:  Existing mobility protocols

          A DMM solution SHOULD first consider reusing and extending
          IETF-standardized protocols before specifying new protocols.

          Motivation: Reuse of existing IETF work is more efficient and
          less error-prone.

   This requirement attempts to avoid the need of new protocols
   development and therefore their potential problems of being time-
   consuming and error-prone.

5.5.  Co-existence

   REQ5:  Co-existence with deployed networks and hosts

          The DMM solution MUST be able to co-exist with existing
          network deployments and end hosts.  For example, depending on
          the environment in which DMM is deployed, DMM solutions may
          need to be compatible with other deployed mobility protocols



Chan (Ed.), et al.      Expires February 3, 2014               [Page 12]

Internet-Draft                  DMM-Reqs                     August 2013


          or may need to co-exist with a network or mobile hosts/routers
          that do not support DMM protocols.  The mobile node may also
          move between different access networks, where some of them may
          support neither DMM nor another mobility protocol.
          Furthermore, a DMM solution SHOULD work across different
          networks, possibly operated as separate administrative
          domains, when allowed by the trust relationship between them.

          Motivation: (a) to preserve backwards compatibility so that
          existing networks and hosts are not affected and continue to
          function as usual, and (b) enable inter-domain operation if
          desired.

   This requirement addresses the related problem PS7 described in
   Section 4.

5.6.  Security considerations

   REQ6:  Security considerations

          A DMM solution MUST not introduce new security risks or
          amplify existing security risks against which the existing
          security mechanisms/protocols cannot offer sufficient
          protection.

          Motivation: Various attacks such as impersonation, denial of
          service, man-in-the-middle attacks, and so on, may be launched
          in a DMM deployment.  For instance, an illegitimate node may
          attempt to access a network providing DMM.  Another example is
          that a malicious node can forge a number of signaling messages
          thus redirecting traffic from its legitimate path.
          Consequently, the specific node is under a denial of service
          attack, whereas other nodes do not receive their traffic.
          Accordingly, security mechanisms/protocols providing access
          control, integrity, authentication, authorization,
          confidentiality, etc. can be used to protect the DMM entities
          as they are already used to protect against existing networks
          and existing mobility protocols defined in IETF.  In addition,
          end-to-end security measures between communicating nodes may
          already be used when deploying existing mobility protocols
          where the signaling messages travel over the Internet.  For
          instance, EAP-based authentication can be used for network
          access security, while IPsec can be used for end-to-end
          security.  When the existing security mechanisms/protocols are
          applied to protect the DMM entities, the security risks that
          may be introduced by DMM MUST be considered to be eliminated.
          Else the security protection would be degraded in the DMM
          solution versus in existing mobility protocols.



Chan (Ed.), et al.      Expires February 3, 2014               [Page 13]

Internet-Draft                  DMM-Reqs                     August 2013


   This requirement prevents a DMM solution from introducing
   uncontrollable problems of potentially insecure mobility management
   protocols which make deployment infeasible because platforms
   conforming to the protocols are at risk for data loss and numerous
   other dangers, including financial harm to the users.

5.7.  Multicast

   REQ7:  Multicast considerations

          DMM SHOULD consider multicast early so that solutions can be
          developed not only to provide IP mobility support when it is
          needed, but also to avoid network inefficiency issues in
          multicast traffic delivery (such as duplicate multicast
          subscriptions towards the downstream tunnel entities).  The
          multicast solutions should therefore avoid restricting the
          management of all IP multicast traffic to a single host
          through a dedicated (tunnel) interface on multicast-capable
          access routers.

          Motivation: Existing multicast deployment have been introduced
          after completing the design of the reference mobility
          protocol, then optimization and extensions have been followed
          by "patching-up" procedure, thus leading to network
          inefficiency and non-optimal routing.  The multicast solutions
          should therefore be required to consider efficiency nature in
          multicast traffic delivery.

   This requirement addresses the problems PS1 and PS8 described in
   Section 4.


6.  Security Considerations

   Please refer to the discussion under Security requirement in Section
   5.6.


7.  IANA Considerations

   None


8.  Co-authors and Contributors

   This problem statement document is a joint effort among the numerous
   participants.  Each individual has made significant contributions to
   this work and have been listed as co-authors.



Chan (Ed.), et al.      Expires February 3, 2014               [Page 14]

Internet-Draft                  DMM-Reqs                     August 2013


9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

9.2.  Informative References

   [I-D.yokota-dmm-scenario]
              Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use cas=
e
              scenarios  for Distributed Mobility Management",
              draft-yokota-dmm-scenario-00 (work in progress),
              October 2010.

   [Paper-Distributed.Centralized.Mobility]
              Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed
              or Centralized Mobility",  Proceedings of Global
              Communications Conference  (GlobeCom), December 2009.

   [Paper-Distributed.Dynamic.Mobility]
              Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed
              Dynamic Mobility Management Scheme  Designed for Flat IP
              Architectures",  Proceedings of 3rd International
              Conference  on New Technologies, Mobility and Security
              (NTMS), 2008.

   [Paper-Distributed.Mobility.MIP]
              Chan, H., "Distributed Mobility Management with Mobile
              IP",  Proceedings of  IEEE International Communication
              Conference (ICC)  Workshop on Telecommunications:  from
              Research to Standards, June 2012.

   [Paper-Distributed.Mobility.PMIP]
              Chan, H., "Proxy Mobile IP  with Distributed Mobility
              Anchors",  Proceedings of GlobeCom Workshop  on Seamless
              Wireless Mobility, December 2010.

   [Paper-Distributed.Mobility.Review]
              Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu,
              "Distributed and Dynamic Mobility Management  in Mobile
              Internet: Current Approaches and Issues, Journal of
              Communications, vol. 6, no. 1, pp. 4-15, Feb 2011.",
               Proceedings of GlobeCom Workshop  on Seamless Wireless
              Mobility, February 2011.

   [Paper-Distributed.Mobility.SAE]
              Fisher, M., Anderson, F., Kopsel, A., Schafer, G., and M.



Chan (Ed.), et al.      Expires February 3, 2014               [Page 15]

Internet-Draft                  DMM-Reqs                     August 2013


              Schlager, "A Distributed IP Mobility Approach for 3G SAE=
",
               Proceedings of the 19th International Symposium  on
              Personal, Indoor and Mobile Radio Communications (PIMRC),
              2008.

   [Paper-Locating.User]
              Kirby, G., "Locating the User",  Communication
              International, 1995.

   [Paper-Migrating.Home.Agents]
              Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home
              Agents  Towards Internet-scale Mobility Deployments",
               Proceedings of the ACM 2nd CoNEXT Conference  on Future
              Networking Technologies, December 2006.

   [Paper-Mobile.Data.Offloading]
              Lee, K., Lee, J., Yi, Y., Rhee, I., and S. Chong, "Mobil=
e
              Data Offloading: How Much Can WiFi Deliver?",  SIGCOMM
              2010, 2010.

   [RFC3753]  Manner, J. and M. Kojo, "Mobility Related Terminology&qu=
ot;,
              RFC 3753, June 2004.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August=
 2008.

   [RFC5380]  Soliman, H., Castelluccia, C., ElMalki, K., and L.
              Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
              Management", RFC 5380, October 2008.

   [RFC5944]  Perkins, C., "IP Mobility Support for IPv4, Revised"=
;,
              RFC 5944, November 2010.

   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Suppor=
t
              in IPv6", RFC 6275, July 2011.

   [RFC6301]  Zhu, Z., Wakikawa, R., and L. Zhang, "A Survey of Mobili=
ty
              Support in the Internet", RFC 6301, July 2011.

   [TS.23.401]
              3GPP, "General Packet Radio Service (GPRS) enhancements
              for Evolved Universal Terrestrial Radio Access Network
              (E-UTRAN) access", 3GPP TR 23.401 10.10.0, March 2013.

   [TS.29303]
              3GPP, "Domain Name System Procedures; Stage 3", 3GP=
P
              TR 23.303 11.2.0, September 2012.




Chan (Ed.), et al.      Expires February 3, 2014               [Page 16]

Internet-Draft                  DMM-Reqs                     August 2013


Authors' Addresses

   H Anthony Chan (editor)
   Huawei Technologies (more co-authors on P. 17)
   5340 Legacy Dr. Building 3, Plano, TX 75024, USA
   Email: h.a.chan@ieee.org


   Dapeng Liu
   China Mobile
   Unit2, 28 Xuanwumenxi Ave, Xuanwu District,  Beijing 100053, China
   Email: liudapeng@chinamobil=
e.com


   Pierrick Seite
   Orange
   4, rue du Clos Courtel, BP 91226,  Cesson-Sevigne 35512, France
   Email: pierrick.seite@orang=
e.com


   Hidetoshi Yokota
   KDDI Lab
   2-1-15 Ohara, Fujimino, Saitama, 356-8502 Japan
   Email: yokota@kddilabs.jp


   Jouni Korhonen
   Nokia Siemens Networks
   Email: jouni.korhonen@nsn.com<=
/a>
   -
   Charles E. Perkins
   Huawei Technologies
   Email: charliep@computer.org
   -
   Melia Telemaco
   Alcatel-Lucent Bell Labs
   Email: telemaco.mel=
ia@alcatel-lucent.com
   -
   Elena Demaria
   Telecom Italia
   via G. Reiss Romoli, 274, TORINO, 10148, Italy
   Email: elena.demaria@t=
elecomitalia.it
   -
   Jong-Hyouk Lee
   RSM Department, Telecom Bretagne
   Cesson-Sevigne, 35512, France
   Email: jh.lee@telecom-bret=
agne.eu
   -



Chan (Ed.), et al.      Expires February 3, 2014               [Page 17]

Internet-Draft                  DMM-Reqs                     August 2013


   Kostas Pentikousis
   Huawei Technologies
   Carnotstr. 4 10587 Berlin, Germany
   Email: k.pentikousis@huawei.=
com
   -
   Tricci So
   ZTE
   Email: tso@zteusa.com
   -
   Carlos J. Bernardos
   Universidad Carlos III de Madrid
   Av. Universidad, 30, Leganes, Madrid 28911, Spain
   Email: cjbc@it.uc3m.es
   -
   Peter McCann
   Huawei Technologies
   Email: PeterMcCann@huawei.com<=
/a>
   -
   Seok Joo Koh
   Kyungpook National University, Korea
   Email: sjkoh@knu.ac.kr
   -
   Wen Luo
   ZTE
   No.68, Zijinhua RD,Yuhuatai District, Nanjing, Jiangsu 210012, China
   Email: luo.wen@zte.com.cn
   -
   Sri Gundavelli
   sgundave@cisco.com
   -
   Marco Liebsch
   NEC Laboratories Europe
   Email: liebsch@neclab.eu
   -
   Carl Williams
   MCSR Labs
   Email: carlw@mcsr-labs.org
   -
   Seil Jeon
   Instituto de Telecomunicacoes, Aveiro
   Email: seiljeon@av.it.pt
   -
   Sergio Figueiredo
   Universidade de Aveiro
   Email: sfigueiredo@av.it.pt
   -
   Stig Venaas
   Email: stig@venaas.com



Chan (Ed.), et al.      Expires February 3, 2014               [Page 18]

Internet-Draft                  DMM-Reqs                     August 2013


   -
   Luis Miguel Contreras Murillo
   Email: lmcm@tid.es
   -
   Juan Carlos Zuniga
   Email: JuanCarlos.=
Zuniga@InterDigital.com
   -
   Alexandru Petrescu
   Email: alexandru.petresc=
u@gmail.com
   -
   Georgios Karagiannis
   Email: g.karagiannis@utwente=
.nl
   -
   Julien Laganier
   jlaganier@juniper.net
   -
   Wassim Michel Haddad
   Wassam.Haddad@ericsson.com=

   -
   Dirk von Hugo
   Dirk.von-Hugo@telekom.de
   -
   Ahmad Muhanna
   amuhanna@awardsolutions.c=
om
   -
   Byoung-Jo Kim
   ATT Labs
   macsbug@research.att.com
   -
   Hassan Aliahmad
   Orange
   hassan.aliahmad@orange.com=

   -


















Chan (Ed.), et al.      Expires February 3, 2014               [Page 19]


--_000_24C0F3E22276D9438D6F366EB89FAEA8116A4D4Fxmbalnx03ciscoc_-- From jouni.nospam@gmail.com Mon Aug 26 12:31:37 2013 Return-Path: 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 2153D11E81FB for ; Mon, 26 Aug 2013 12:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=-0.401, BAYES_00=-2.599, J_CHICKENPOX_28=0.6, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315] 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 aUZDNcHNjEZ7 for ; Mon, 26 Aug 2013 12:31:34 -0700 (PDT) Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id DDA8811E820C for ; Mon, 26 Aug 2013 12:31:33 -0700 (PDT) Received: by mail-ea0-f178.google.com with SMTP id a15so1797193eae.23 for ; Mon, 26 Aug 2013 12:31:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rZvhLedVwCalr/0xpHbxuLyd/N4OBIm1dd3e+x+ObtY=; b=XZaRz2qVkgqGaWKWP2tR3/pydwYyh7vmHHIsaQZNYqraMYsciGmHc0ALgykHVZNDe0 oynsB9vrko/to9HK4RgfzHLBwatuJgDwf5j3gAooIoxHNATawDFAyeqSZ+A7GnAtvazW 38cNrQstk3QhnY/Neg+C2frT7XoTw0yV+MQczooOnFucfbBrXBzBycoNkKI2trFvtvlC CnlJI4txm60eRueupUhCttB8OeOmq83SNYrdi+cKwXwUOn/BMjaPTJ0Lo+568hRnqYIw QGNAVl2JuVALKjzT2Cmv8FS8JEQ0n0VxkdJLvMY7Zy+hbw44qUZXSl9ZFHXgCSzHLmP+ m5lA== X-Received: by 10.15.43.13 with SMTP id w13mr28005285eev.37.1377545491777; Mon, 26 Aug 2013 12:31:31 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:ec6b:8418:d867:4f25? ([2001:1bc8:101:f101:ec6b:8418:d867:4f25]) by mx.google.com with ESMTPSA id a43sm23526604eep.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 Aug 2013 12:31:31 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: <24C0F3E22276D9438D6F366EB89FAEA8116A4D4F@xmb-aln-x03.cisco.com> Date: Mon, 26 Aug 2013 22:31:26 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24C0F3E22276D9438D6F366EB89FAEA8116A4D4F@xmb-aln-x03.cisco.com> To: Sri Gundavelli (sgundave) X-Mailer: Apple Mail (2.1508) Cc: "dmm@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 19:31:37 -0000 Thanks Sri for detailed comments. We definitely need to hash these out and address them. - Jouni On Aug 26, 2013, at 6:03 AM, Sri Gundavelli (sgundave) = wrote: > Please see inline for some comments. >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 > Abstract >=20 > This document defines the requirements for Distributed Mobility > Management (DMM) in IPv6 deployments. The hierarchical structure = in > traditional wireless networks has led to deployment models which = are > in practice centralized. Mobility management with logically > centralized mobility anchoring in current mobile networks is prone = to > suboptimal routing and raises scalability issues. Such centralized > functions can lead to single points of failure and inevitably > introduce longer delays and higher signaling loads for network > operations related to mobility management. The objective is to > enhance mobility management in order to meet the primary goals in > network evolution, i.e., improve scalability, avoid single points = of > failure, enable transparent mobility support to upper layers only > when needed, and so on. Distributed mobility management must be > secure and may co-exist with existing network deployments and end > hosts. >=20 > [Sri] We don=92t need to argue against centralized model to justify = distributed model. In the absence of proper data to compare on both the = approaches, we cannot have such text. The pros and cons extend to both = the models. Please simply state distributed model can be useful in = certain deployments and hence there is interest for this work. >=20 >=20 > 1. Introduction >=20 > In the past decade a fair number of mobility protocols have been > standardized [RFC6275] [RFC5944] [RFC5380] [RFC6301] [RFC5213]. > Although the protocols differ in terms of functions and associated > message formats, we can identify a few key common features: >=20 > o a centralized mobility anchor providing global reachability and = an > always-on experience to the user; >=20 > o extensions to the base protocols to optimize handover = performance > while users roam across wireless cells; and >=20 > o extensions to enable the use of heterogeneous wireless = interfaces > for multi-mode terminals (e.g. smartphones). >=20 >=20 > [Sri] Currently defined mobility protocols support handovers and = multiple access technologies ? Not sure, how these two "common = features" make the case for DMM If the point is about centralized = anchor's, you don't need the other two points.=20 >=20 > The presence of the centralized mobility anchor allows a mobile = node > to remain reachable after it has moved to a different network. The > anchor point, among other tasks, ensures connectivity by forwarding > packets destined to, or sent from, the mobile node. In practice, > most of the deployed architectures today have a small number of > centralized anchors managing the traffic of millions of mobile = nodes. > Compared with a distributed approach, a centralized approach is > likely to have several issues or limitations affecting performance > and scalability, which require costly network engineering to = resolve. >=20 >=20 > [Sri] All 3G/4G systems are based on this model and they are running = fine. Again, we don=92t need to argue against centralized model to = justify distributed model. Please simply state distributed model can be = useful in certain deployments and hence the motivation for this work. >=20 > To optimize handovers from the perspective of mobile nodes, the = base > protocols have been extended to efficiently handle packet = forwarding > between the previous and new points of attachment. These = extensions > are necessary when applications have stringent requirements in = terms > of delay. Notions of localization and distribution of local agents > have been introduced to reduce signaling overhead at the = centralized > routing anchor point [Paper-Distributed.Centralized.Mobility]. > Unfortunately, today we witness difficulties in getting such > protocols deployed, resulting in sub-optimal choices for the = network > Operators. >=20 > [Sri] I assume this is about hierarchical models / Chaining ? What are = these "difficulties in getting such protocols deployed" ? =20 > Moreover, the availability of multiple-interface host and the > possibility of using several network interfaces simultaneously have > motivated the development of even more protocol extensions to add > more capabilities to the mobility management protocol. In the end, > deployment is further complicated with the multitude of extensions. >=20 > [Sri] Not sure I follow. Mobile IP protocols are in general access = agnostic. Not sure, what are the extensions that we have added on = access-basis. >=20 >=20 > As an effective transport method for multimedia data delivery, IP > multicast support, including optimizations, have been introduced = but > by "patching-up" procedure after completing the design of reference > mobility protocol, leading to network inefficiency and non-optimal > routing. >=20 >=20 > [Sri] Multicast related extensions have nothing to do with = multi-access support/host's capability to support multiple interfaces. = Can you clarify ? This text is not clear. > Chan (Ed.), et al. Expires February 3, 2014 [Page = 4] >=20 > Internet-Draft DMM-Reqs August = 2013 >=20 >=20 > 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 traffic offload (e.g. 3GPP work items LIPA/SIPTO > [TS.23.401]) through alternative access networks (e.g. WLAN) = [Paper- > Mobile.Data.Offloading]. =20 >=20 > [Sri] Please add reference to IETF SIPTO doc, RFC6909, before 23.401 = :) >=20 > A gateway selection mechanism also takes > the user proximity into account within EPC [TS.29303]. These > mechanisms were not pursued in the past owing to charging and = billing > reasons. Assigning a gateway anchor node from a visited network = in >=20 > roaming scenario has until recently been done and are limited to > voice services only. Charging and billing require solutions beyond > the mobility protocol. >=20 >=20 > Both traffic offloading and CDN mechanisms could benefit from the > development of mobile architectures with fewer levels of routing > hierarchy introduced into the data path by the mobility management > system. This trend towards so-called "flat networks" works best = for > direct communications among peers in the same geographical area. > Distributed mobility management in a truly flat mobile architecture > would anchor the traffic closer to the point of attachment of the > user. >=20 > 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.=20 >=20 > 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.=20 >=20 > [Sri] Is the intent of this is text is about routing based approaches = ? > If a mobile is attached to the network, it does have some state at the = anchor. Also, if we consider the home link in mobility models, there is = no state for the mobile node when it is at home. In case of DMM, or with = the current models, if the gateway selection is based on the MN's = location and when there is no node mobility, there should not be any = state at the anchor. CDMA >=20 >=20 > Infrequent node mobility > coupled with application intelligence suggest that mobility support > could be provided selectively, thus reducing the amount of context > maintained in the network. >=20 > The distributed mobility management (DMM) charter addresses two > complementary aspects of mobility management procedures: the > distribution of mobility anchors towards a more flat network and = the > dynamic activation/deactivation of mobility protocol support as an > enabler to distributed mobility management. =20 >=20 > [Sri] Not sure, I follow this point on Dynamic = activation/de-activation. Can you clarify. >=20 > The former aims at > positioning mobility anchors (e.g., HA, LMA) closer to the user; > ideally, mobility agents could be collocated with the first-hop >=20 >=20 >=20 > Chan (Ed.), et al. Expires February 3, 2014 [Page = 5] >=20 > Internet-Draft DMM-Reqs August = 2013 >=20 >=20 > router. The latter, facilitated by the distribution of mobility > anchors, aims at identifying when mobility support must be = activated > and identifying sessions that do not require mobility management > support -- thus reducing the amount of state information that must = be > maintained in various mobility agents of the mobile network. The = key > idea is that dynamic mobility management relaxes some of the > constraints of previously-standardized mobility management = solutions > and, by doing so, it can avoid the unnecessary establishment of > mechanisms to forward traffic from an old to a new mobility anchor. >=20 >=20 > [Sri] The DMM model should not exclude the case of centralized anchor = and distributed data plane. This is sub-case of DMM.=20 >=20 > This document compares distributed mobility management with > centralized mobility management in Section 3. The problems that = can > be addressed with DMM are summarized in Section 4. The mandatory > requirements as well as the optional requirements are given in > Section 5. Finally, security considerations are discussed in = Section > 6. >=20 > The problem statement and the use cases [I-D.yokota-dmm-scenario] = can > be found in [Paper-Distributed.Mobility.Review]. >=20 >=20 > 2. Conventions used in this document >=20 > 2.1. Terminology >=20 > All the general mobility-related terms and their acronyms used in > this document are to be interpreted as defined in the Mobile IPv6 > base specification [RFC6275], in the Proxy mobile IPv6 = specification > [RFC5213], and in Mobility Related Terminology [RFC3753]. These > terms include the following: mobile node (MN), correspondent node > (CN), and home agent (HA) as per [RFC6275]; local mobility anchor > (LMA) and mobile access gateway (MAG) as per [RFC5213], and context > as per [RFC3753]. >=20 > In addition, this draft introduces the following term. >=20 > Mobility context >=20 > is the collection of information required to provide mobility > management support for a given mobile node. >=20 >=20 >=20 > [Sri] There needs to be some definition of "centrally deployed = mobility anchor". This term is used through-out the document. What is = central, what is local ? Even in the so called, "centralized anchor = models", a gateway can be enabled locally. Ex: LMA/MAG, PGW/SGW = functions can exist on the same node.=20 >=20 > 3. Centralized versus distributed mobility management >=20 > Mobility management functions may be implemented at different = layers > of the protocol stack. At the IP (network) layer, they may reside = in > the network or in the mobile node. In particular, a network-based > solution resides in the network only. It therefore enables = mobility >=20 >=20 >=20 > Chan (Ed.), et al. Expires February 3, 2014 [Page = 6] >=20 > Internet-Draft DMM-Reqs August = 2013 >=20 >=20 > for existing hosts and network applications which are already in > deployment but lack mobility support. >=20 >=20 > [Sri] Above text is bit confusing to me, specially the last sentence. = Mobility management can be based on client-based, or network-based.=20 >=20 >=20 > At the IP layer, a mobility management protocol supporting=20 > session > continuity > is typically based on the principle of distinguishing > between identifier and routing address and maintaining a mapping > between the two. =20 >=20 > [Sri] Replace, "Session continuity" with "IP mobility" or "IP address = continuity".=20 > In Mobile IP, the home address serves as an > identifier of the device whereas the care-of-address (CoA) takes = the > role of the routing address. The binding between these two is > maintained at the home agent (mobility anchor). If packets can be > continuously delivered to a mobile node at its home address, then = all > sessions using that home address are unaffected even though the > routing address (CoA) changes. >=20 >=20 > [Sri] We should leave it at, "IP address mobility". > The next two subsections explain centralized and distributed = mobility > management functions in the network. >=20 > 3.1. Centralized mobility management >=20 > In centralized mobility management, the mapping information between > the persistent node identifier and the locator IP address of a = mobile > node (MN) is kept at a single mobility anchor. At the same time, > packets destined to the MN are routed via this anchor. >=20 > [Sri] Can we use the MIP terminology, home address/Care-of address = terminology, as supposed to LISP terminology ?=20 >=20 > In other > words, such mobility management systems are centralized in both the > control plane and the data plane (mobile node IP traffic). >=20 > Many existing mobility management deployments make use of = centralized > mobility anchoring in a hierarchical network architecture, as shown > in Figure 1. Examples of such centralized mobility anchors are the > home agent (HA) and local mobility anchor (LMA) in Mobile IPv6 > [RFC6275] and Proxy Mobile IPv6 [RFC5213], respectively. Current > cellular networks such as the Third Generation Partnership Project > (3GPP) GPRS networks, CDMA networks, and 3GPP Evolved Packet System > (EPS) networks employ centralized mobility management too. In > particular, the Gateway GPRS Support Node (GGSN), Serving GPRS > Support Node (SGSN) and Radio Network Controller (RNC) in the 3GPP > GPRS hierarchical network, and the Packet Data Network Gateway = (P-GW) > and Serving Gateway (S-GW) in the 3GPP EPS network all act as = anchors > in a hierarchy. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Chan (Ed.), et al. Expires February 3, 2014 [Page = 7] >=20 > Internet-Draft DMM-Reqs August = 2013 >=20 >=20 > 3G GPRS 3GPP EPS MIP/PMIP > +------+ +------+ +------+ > | GGSN | | P-GW | |HA/LMA| > +------+ +------+ +------+ > /\ /\ /\ > / \ / \ / \ > / \ / \ / \ > / \ / \ / \ > / \ / \ / \ > / \ / \ / \ > / \ / \ / \ > +------+ +------+ +------+ +------+ +------+ = +------+ > | SGSN | | SGSN | | S-GW | | S-GW | |MN/MAG| = |MN/MAG| > +------+ +------+ +------+ +------+ +------+ = +------+ > /\ /\ > / \ / \ > / \ / \ > +---+ +---+ +---+ +---+ > |RNC| |RNC| |RNC| |RNC| > +---+ +---+ +---+ +---+ >=20 > Figure 1. Centralized mobility management. >=20 > 3.2. Distributed mobility management >=20 > Mobility management functions may also be distributed to multiple > networks as shown in Figure 2, so that a mobile node in any of = these > networks may be served by a nearby mobility function (MF). >=20 >=20 > +------+ +------+ +------+ +------+ > | MF | | MF | | MF | | MF | > +------+ +------+ +------+ +------+ > | > +----+ > | MN | > +----+ >=20 > Figure 2. Distributed mobility management. >=20 >=20 >=20 > Mobility management may be partially or fully distributed. In the > former case only the data plane is distributed. Fully distributed > mobility management implies that both the data plane and the = control > plane are distributed. Such concepts of data and control plane > separation are not yet described in the IETF developed mobility > protocols so far but are described in detail in [I-D.yokota-dmm- > scenario]. While mobility management can be distributed, it is not > necessary for other functions such as subscription management, >=20 >=20 >=20 > Chan (Ed.), et al. Expires February 3, 2014 [Page = 8] >=20 > Internet-Draft DMM-Reqs August = 2013 >=20 >=20 > subscription database, and network access authentication to be > similarly distributed. >=20 >=20 > [Sri] The case of centralized CP and distributed DP is covered in IETF = docs,=20 > = http://datatracker.ietf.org/doc/draft-wakikawa-netext-pmip-cp-up-separatio= n/ > This is a variant of the DMM models.=20 >=20 > A distributed mobility management scheme for flat IP-based mobile > network architecture consisting of access nodes is proposed in > [Paper-Distributed.Dynamic.Mobility]. Its benefits over = centralized > mobility management are shown through simulations in [Paper- > Distributed.Centralized.Mobility]. Moreover, the (re)use and > extension of existing protocols in the design of both fully > distributed mobility management [Paper-Migrating.Home.Agents] = [Paper- > Distributed.Mobility.SAE] and partially distributed mobility > management [Paper-Distributed.Mobility.PMIP] [Paper- > Distributed.Mobility.MIP] have been reported in the literature. > Therefore, before designing new mobility management protocols for a > future flat IP architecture, it is recommended to first consider > whether existing mobility management protocols can be extended to > serve a flat IP architecture. >=20 >=20 > [Sri] Lot of unnecessary text in this document. Not sure, we need all = of this text. >=20 >=20 > 4. Problem Statement >=20 > The problems that can be addressed with DMM are summarized in the > following: >=20 > PS1: Non-optimal routes >=20 > Routing via a centralized anchor often results in a longer > route. =20 >=20 > [Sri] "longer route" ? I assume this is about routing/tx delay. = Please re-word. >=20 > 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. >=20 >=20 > [Sri] Does RFC 6705, or RFC 6909 does not address this issue ? May be = the CDN example is incorrect.=20 >=20 >=20 > PS2: Divergence from other evolutionary trends in network > architectures such as distribution of content delivery. >=20 > Centralized mobility management can become non-optimal with a > flat network architecture. >=20 >=20 > [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. >=20 > PS3: Low scalability of centralized tunnel management and mobility > context maintenance >=20 > 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. >=20 >=20 >=20 >=20 > Chan (Ed.), et al. Expires February 3, 2014 [Page = 9] >=20 > Internet-Draft DMM-Reqs August = 2013 >=20 >=20 > PS4: Single point of failure and attack >=20 > 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. >=20 > PS5: Unnecessarily reserving resources to provide mobility support > to nodes that do not need such support >=20 > 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. >=20 >=20 > [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 =20 > draft-korhonen-6man-prefix-properties-02 >=20 >=20 > PS6: (Related problem) Mobility signaling overhead with = peer-to-peer > communication >=20 > Wasting resources when mobility signaling (e.g., maintenance = of > the tunnel, keep alive signaling, etc.) is not turned off for > peer-to-peer communication. Peer-to-peer communications have > particular traffic patterns that often do not benefit from > mobility support from the network. Thus, the associated > mobility support signaling (e.g., maintenance of the tunnel, > keep alive signaling, etc.) wastes network resources for no > application gain. In such a case, it is better to enable > mobility support selectively. >=20 >=20 > [Sri] How is PS6 different from PS5 ? We talk about application's = ability to pick the address with or without mobility properties in PS5. = So, the traffic patterns can be localized based on the application = requirements. But, even if we take the argument that mobility is not = required, operator needs visibility into these flows and so they can = charge. Again, we have 6705 and 6909 for adjusting to those traffic = patterns. So, this P without those considerations is incomplete. >=20 >=20 > PS7: (Related problem) Deployment with multiple mobility solutions >=20 > There are already many variants and extensions of MIP. > Deployment of new mobility management solutions can be > challenging, and debugging difficult, when they must co-exist > with solutions already in the field. >=20 >=20 >=20 >=20 > PS8: Duplicate multicast traffic >=20 > IP multicast distribution over architectures using IP = mobility > solutions (e.g. RFC6224) may lead to convergence of = duplicated > multicast subscriptions towards the downstream tunnel entity > (e.g. MAG in PMIPv6). Concretely, when multicast = subscription > for individual mobile nodes is coupled with mobility tunnels > (e.g. PMIPv6 tunnel), duplicate multicast subscription(s) is >=20 >=20 >=20 > Chan (Ed.), et al. Expires February 3, 2014 [Page = 10] >=20 > Internet-Draft DMM-Reqs August = 2013 >=20 >=20 > prone to be received through different upstream paths. This > problem may also exist or be more severe in a distributed > mobility environment. >=20 >=20 > [Sri] Is this for MN's from different LMA's attached to the same MAG ? >=20 > 5. Requirements >=20 > After comparing distributed mobility management against centralized > deployment in Section 3, this section identifies the following > requirements: >=20 > 5.1. Distributed processing >=20 > REQ1: Distributed processing >=20 > IP mobility, network access and routing solutions provided = by > DMM MUST enable distributed processing for mobility = management > so that traffic does not need to traverse centrally deployed > mobility anchors and thereby avoid non-optimal routes. >=20 > Motivation: This requirement is motivated by current trends = in > network evolution: (a) it is cost- and resource-effective to > cache and distribute content by combining distributed = mobility > anchors with caching systems (e.g., CDN); (b) the > significantly larger number of mobile nodes and flows call = for > improved scalability; (c) single points of failure are = avoided > in a distributed system; (d) threats against centrally > deployed anchors, e.g., home agent and local mobility = anchor, > are mitigated in a distributed system. >=20 > This requirement addresses the problems PS1, PS2, PS3, and PS4 > described in Section 4. (Existing route optimization is only a = host- > based solution. On the other hand, localized routing with PMIPv6 > 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.) >=20 >=20 > [Sri] I'm still stuck on the CDN example driving this requirement. >=20 >=20 > 5.2. Transparency to Upper Layers when needed >=20 > REQ2: Transparency to Upper Layers when needed >=20 > DMM solutions MUST provide transparent mobility support = above > the IP layer when needed. Such transparency is needed, for > example, when, upon change of point of attachment to the > network, an application flow cannot cope with a change in = the > IP address. However, it is not always necessary to maintain = a > stable home IP address or prefix for every application or at > all times for a mobile node. >=20 >=20 >=20 > [Sri] Please reflect the two key aspects of this requirement: > =95 Network can assign IP addresses with different properties; = It carries those properties > =95 Applications have different requirements and will pick the = address with the correct property. >=20 >=20 > Chan (Ed.), et al. Expires February 3, 2014 [Page = 11] >=20 > Internet-Draft DMM-Reqs August = 2013 >=20 >=20 > Motivation: The motivation of this requirement is to enable > more efficient use of network resources and more efficient > routing by not maintaining context at the mobility anchor = when > there is no such need. >=20 > This requirement addresses the problem PS5 as well as the related > problem PS6 stated in Section 4. >=20 > 5.3. IPv6 deployment >=20 > REQ3: IPv6 deployment >=20 > DMM solutions SHOULD target IPv6 as the primary deployment > environment and SHOULD NOT be tailored specifically to = support > IPv4, in particular in situations where private IPv4 = addresses > and/or NATs are used. >=20 > Motivation: This requirement conforms to the general > orientation of IETF work. DMM deployment is foreseen in = mid- > to long-term horizon, when IPv6 is expected to be far more > common than today. >=20 > This requirement avoids the unnecessarily complexity in solving the > problems in Section 4 for IPv4, which will not be able to use some = of > the IPv6-specific features. >=20 > 5.4. Existing mobility protocols >=20 > REQ4: Existing mobility protocols >=20 > A DMM solution SHOULD first consider reusing and extending > IETF-standardized protocols before specifying new protocols. >=20 > Motivation: Reuse of existing IETF work is more efficient = and > less error-prone. >=20 > This requirement attempts to avoid the need of new protocols > development and therefore their potential problems of being time- > consuming and error-prone. >=20 > 5.5. Co-existence >=20 > REQ5: Co-existence with deployed networks and hosts >=20 > The DMM solution MUST be able to co-exist with existing > network deployments and end hosts. For example, depending = on > the environment in which DMM is deployed, DMM solutions may > need to be compatible with other deployed mobility protocols >=20 >=20 >=20 > Chan (Ed.), et al. Expires February 3, 2014 [Page = 12] >=20 > Internet-Draft DMM-Reqs August = 2013 >=20 >=20 > or may need to co-exist with a network or mobile = hosts/routers > that do not support DMM protocols. The mobile node may also > move between different access networks, where some of them = may > support neither DMM nor another mobility protocol. > Furthermore, a DMM solution SHOULD work across different > networks, possibly operated as separate administrative > domains, when allowed by the trust relationship between = them. >=20 > Motivation: (a) to preserve backwards compatibility so that > existing networks and hosts are not affected and continue to > function as usual, and (b) enable inter-domain operation if > desired. >=20 > This requirement addresses the related problem PS7 described in > Section 4. >=20 > 5.6. Security considerations >=20 > REQ6: Security considerations >=20 > A DMM solution MUST not introduce new security risks or > amplify existing security risks against which the existing > security mechanisms/protocols cannot offer sufficient > protection. >=20 > Motivation: Various attacks such as impersonation, denial of > service, man-in-the-middle attacks, and so on, may be = launched > in a DMM deployment. For instance, an illegitimate node may > attempt to access a network providing DMM. Another example = is > that a malicious node can forge a number of signaling = messages > thus redirecting traffic from its legitimate path. > Consequently, the specific node is under a denial of service > attack, whereas other nodes do not receive their traffic. > Accordingly, security mechanisms/protocols providing access > control, integrity, authentication, authorization, > confidentiality, etc. can be used to protect the DMM = entities > as they are already used to protect against existing = networks > and existing mobility protocols defined in IETF. In = addition, > end-to-end security measures between communicating nodes may > already be used when deploying existing mobility protocols > where the signaling messages travel over the Internet. For > instance, EAP-based authentication can be used for network > access security, while IPsec can be used for end-to-end > security. When the existing security mechanisms/protocols = are > applied to protect the DMM entities, the security risks that > may be introduced by DMM MUST be considered to be = eliminated. > Else the security protection would be degraded in the DMM > solution versus in existing mobility protocols. >=20 >=20 >=20 > Chan (Ed.), et al. Expires February 3, 2014 [Page = 13] >=20 > Internet-Draft DMM-Reqs August = 2013 >=20 >=20 > This requirement prevents a DMM solution from introducing > uncontrollable problems of potentially insecure mobility management > protocols which make deployment infeasible because platforms > conforming to the protocols are at risk for data loss and numerous > other dangers, including financial harm to the users. >=20 > 5.7. Multicast >=20 > REQ7: Multicast considerations >=20 > DMM SHOULD consider multicast early so that solutions can be > developed not only to provide IP mobility support when it is > needed, but also to avoid network inefficiency issues in > multicast traffic delivery (such as duplicate multicast > subscriptions towards the downstream tunnel entities). The > multicast solutions should therefore avoid restricting the > management of all IP multicast traffic to a single host > through a dedicated (tunnel) interface on multicast-capable > access routers. >=20 > Motivation: Existing multicast deployment have been = introduced > after completing the design of the reference mobility > protocol, then optimization and extensions have been = followed > by "patching-up" procedure, thus leading to network > inefficiency and non-optimal routing. The multicast = solutions > should therefore be required to consider efficiency nature = in > multicast traffic delivery. >=20 > This requirement addresses the problems PS1 and PS8 described in > Section 4. >=20 >=20 > 6. Security Considerations >=20 > Please refer to the discussion under Security requirement in = Section > 5.6. >=20 >=20 > 7. IANA Considerations >=20 > None >=20 >=20 > 8. Co-authors and Contributors >=20 > This problem statement document is a joint effort among the = numerous > participants. Each individual has made significant contributions = to > this work and have been listed as co-authors. >=20 >=20 >=20 > Chan (Ed.), et al. Expires February 3, 2014 [Page = 14] >=20 > Internet-Draft DMM-Reqs August = 2013 >=20 >=20 > 9. References >=20 > 9.1. Normative References >=20 > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. >=20 > 9.2. Informative References >=20 > [I-D.yokota-dmm-scenario] > Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use = case > scenarios for Distributed Mobility Management", > draft-yokota-dmm-scenario-00 (work in progress), > October 2010. >=20 > [Paper-Distributed.Centralized.Mobility] > Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed > or Centralized Mobility", Proceedings of Global > Communications Conference (GlobeCom), December 2009. >=20 > [Paper-Distributed.Dynamic.Mobility] > Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed > Dynamic Mobility Management Scheme Designed for Flat IP > Architectures", Proceedings of 3rd International > Conference on New Technologies, Mobility and Security > (NTMS), 2008. >=20 > [Paper-Distributed.Mobility.MIP] > Chan, H., "Distributed Mobility Management with Mobile > IP", Proceedings of IEEE International Communication > Conference (ICC) Workshop on Telecommunications: from > Research to Standards, June 2012. >=20 > [Paper-Distributed.Mobility.PMIP] > Chan, H., "Proxy Mobile IP with Distributed Mobility > Anchors", Proceedings of GlobeCom Workshop on Seamless > Wireless Mobility, December 2010. >=20 > [Paper-Distributed.Mobility.Review] > Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu, > "Distributed and Dynamic Mobility Management in Mobile > Internet: Current Approaches and Issues, Journal of > Communications, vol. 6, no. 1, pp. 4-15, Feb 2011.", > Proceedings of GlobeCom Workshop on Seamless Wireless > Mobility, February 2011. >=20 > [Paper-Distributed.Mobility.SAE] > Fisher, M., Anderson, F., Kopsel, A., Schafer, G., and = M. >=20 >=20 >=20 > Chan (Ed.), et al. Expires February 3, 2014 [Page = 15] >=20 > Internet-Draft DMM-Reqs August = 2013 >=20 >=20 > Schlager, "A Distributed IP Mobility Approach for 3G = SAE", > Proceedings of the 19th International Symposium on > Personal, Indoor and Mobile Radio Communications = (PIMRC), > 2008. >=20 > [Paper-Locating.User] > Kirby, G., "Locating the User", Communication > International, 1995. >=20 > [Paper-Migrating.Home.Agents] > Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home > Agents Towards Internet-scale Mobility Deployments", > Proceedings of the ACM 2nd CoNEXT Conference on Future > Networking Technologies, December 2006. >=20 > [Paper-Mobile.Data.Offloading] > Lee, K., Lee, J., Yi, Y., Rhee, I., and S. Chong, = "Mobile > Data Offloading: How Much Can WiFi Deliver?", SIGCOMM > 2010, 2010. >=20 > [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", > RFC 3753, June 2004. >=20 > [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, = K., > and B. Patil, "Proxy Mobile IPv6", RFC 5213, August = 2008. >=20 > [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. > Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility > Management", RFC 5380, October 2008. >=20 > [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", > RFC 5944, November 2010. >=20 > [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility = Support > in IPv6", RFC 6275, July 2011. >=20 > [RFC6301] Zhu, Z., Wakikawa, R., and L. Zhang, "A Survey of = Mobility > Support in the Internet", RFC 6301, July 2011. >=20 > [TS.23.401] > 3GPP, "General Packet Radio Service (GPRS) enhancements > for Evolved Universal Terrestrial Radio Access Network > (E-UTRAN) access", 3GPP TR 23.401 10.10.0, March 2013. >=20 > [TS.29303] > 3GPP, "Domain Name System Procedures; Stage 3", 3GPP > TR 23.303 11.2.0, September 2012. >=20 >=20 >=20 >=20 > Chan (Ed.), et al. Expires February 3, 2014 [Page = 16] >=20 > Internet-Draft DMM-Reqs August = 2013 >=20 >=20 > Authors' Addresses >=20 > H Anthony Chan (editor) > Huawei Technologies (more co-authors on P. 17) > 5340 Legacy Dr. Building 3, Plano, TX 75024, USA > Email:=20 > h.a.chan@ieee.org >=20 >=20 >=20 > Dapeng Liu > China Mobile > Unit2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China > Email:=20 > liudapeng@chinamobile.com >=20 >=20 >=20 > Pierrick Seite > Orange > 4, rue du Clos Courtel, BP 91226, Cesson-Sevigne 35512, France > Email:=20 > pierrick.seite@orange.com >=20 >=20 >=20 > Hidetoshi Yokota > KDDI Lab > 2-1-15 Ohara, Fujimino, Saitama, 356-8502 Japan > Email:=20 > yokota@kddilabs.jp >=20 >=20 >=20 > Jouni Korhonen > Nokia Siemens Networks > Email:=20 > jouni.korhonen@nsn.com >=20 > - > Charles E. Perkins > Huawei Technologies > Email:=20 > charliep@computer.org >=20 > - > Melia Telemaco > Alcatel-Lucent Bell Labs > Email:=20 > telemaco.melia@alcatel-lucent.com >=20 > - > Elena Demaria > Telecom Italia > via G. Reiss Romoli, 274, TORINO, 10148, Italy > Email:=20 > elena.demaria@telecomitalia.it >=20 > - > Jong-Hyouk Lee > RSM Department, Telecom Bretagne > Cesson-Sevigne, 35512, France > Email:=20 > jh.lee@telecom-bretagne.eu >=20 > - >=20 >=20 >=20 > Chan (Ed.), et al. Expires February 3, 2014 [Page = 17] >=20 > Internet-Draft DMM-Reqs August = 2013 >=20 >=20 > Kostas Pentikousis > Huawei Technologies > Carnotstr. 4 10587 Berlin, Germany > Email:=20 > k.pentikousis@huawei.com >=20 > - > Tricci So > ZTE > Email:=20 > tso@zteusa.com >=20 > - > Carlos J. Bernardos > Universidad Carlos III de Madrid > Av. Universidad, 30, Leganes, Madrid 28911, Spain > Email:=20 > cjbc@it.uc3m.es >=20 > - > Peter McCann > Huawei Technologies > Email:=20 > PeterMcCann@huawei.com >=20 > - > Seok Joo Koh > Kyungpook National University, Korea > Email:=20 > sjkoh@knu.ac.kr >=20 > - > Wen Luo > ZTE > No.68, Zijinhua RD,Yuhuatai District, Nanjing, Jiangsu 210012, = China > Email:=20 > luo.wen@zte.com.cn >=20 > - > Sri Gundavelli > =20 > sgundave@cisco.com >=20 > - > Marco Liebsch > NEC Laboratories Europe > Email:=20 > liebsch@neclab.eu >=20 > - > Carl Williams > MCSR Labs > Email:=20 > carlw@mcsr-labs.org >=20 > - > Seil Jeon > Instituto de Telecomunicacoes, Aveiro > Email:=20 > seiljeon@av.it.pt >=20 > - > Sergio Figueiredo > Universidade de Aveiro > Email:=20 > sfigueiredo@av.it.pt >=20 > - > Stig Venaas > Email:=20 > stig@venaas.com >=20 >=20 >=20 >=20 > Chan (Ed.), et al. Expires February 3, 2014 [Page = 18] >=20 > Internet-Draft DMM-Reqs August = 2013 >=20 >=20 > - > Luis Miguel Contreras Murillo > Email:=20 > lmcm@tid.es >=20 > - > Juan Carlos Zuniga > Email:=20 > JuanCarlos.Zuniga@InterDigital.com >=20 > - > Alexandru Petrescu > Email:=20 > alexandru.petrescu@gmail.com >=20 > - > Georgios Karagiannis > Email:=20 > g.karagiannis@utwente.nl >=20 > - > Julien Laganier > =20 > jlaganier@juniper.net >=20 > - > Wassim Michel Haddad > =20 > Wassam.Haddad@ericsson.com >=20 > - > Dirk von Hugo > =20 > Dirk.von-Hugo@telekom.de >=20 > - > Ahmad Muhanna > =20 > amuhanna@awardsolutions.com >=20 > - > Byoung-Jo Kim > ATT Labs > =20 > macsbug@research.att.com >=20 > - > Hassan Aliahmad > Orange > =20 > hassan.aliahmad@orange.com >=20 > - >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Chan (Ed.), et al. Expires February 3, 2014 [Page = 19] >=20 >=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm