From jong-hyouk.lee@inria.fr Tue Nov 1 07:03:22 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1556A1F0CA0 for ; Tue, 1 Nov 2011 07:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[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 lJCqBE9BT53B for ; Tue, 1 Nov 2011 07:03:21 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id 736271F0C72 for ; Tue, 1 Nov 2011 07:03:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.69,438,1315173600"; d="scan'208";a="127399418" Received: from ver78-4-82-244-181-122.fbx.proxad.net (HELO [192.168.0.13]) ([82.244.181.122]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 01 Nov 2011 15:03:18 +0100 Message-ID: <4EAFFC25.8070706@inria.fr> Date: Tue, 01 Nov 2011 15:03:17 +0100 From: Jong-Hyouk Lee Organization: INRIA User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111008 Thunderbird/8.0 MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: h.anthony.chan@huawei.com Subject: [MEXT] Comments on "PS for distributed and dynamic mobility management" (draft-chan-distributed-mobility-ps-05). X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 14:03:22 -0000 Dear H. Chan and all. I read the latest Internet-draft, draft-chan-distributed-mobility-ps-05. It is generally well written and contains educational and introductory text for distributed mobility management. The followings are some comments: 1. As you know, we will not have "the distributed mobility management working group" at the IETF, but it is being considered at the MeXT working group. 2. In Section 1.2, the problems or limitations of centralized mobility anchoring (i.e., most of existing mobility protocols) are presented. However, you should give some descriptions what distributed and dynamic mobility management is before. Otherwise, it would be better not to compare with (or not to mention) distributed and dynamic mobility management because you have not given detailed operations, characteristics, and benefits of distributed and dynamic mobility management before Section 1.2. Note that we all know about the history of it, but others? ;) 3. As one of the problems or limitations of centralized mobility anchoring (i.e., most of existing mobility protocols), you have identified a complicated deployment due to many variants and extensions. I do not see if it is surely the problems or limitations. Could you give specific examples for this? Existing extensions to mobility protocols have been well selected and developed for enhancing deployment ease, performance, security, etc...those are not the specific problems or limitations a centralized mobility anchoring approach has...I suppose. 4. "Mobility management functions may be implemented at different layers of the network protocol stack." should be rephrased as "... at different layers of the communication stack" or "... at different layers of the protocol stack". 5. "... between identifier and routing address ..." should be "... between identifier and routing addresses ..." 6. In Section 3.1, "Packets destined to an MN are ..." should be "Packets destined to the MN are ..." 7. RFC 3775 should be replaced with RFC 6275. 8. It is always better to explicitly distinguish IP protocol version numbers, e.g., Mobile IPv4 or Mobile IPv6, at the document. As an example, In Section 3.1, "... Mobile IP [RFC3775] and Proxy Mobile IP [RFC5213], respectively." should be "Mobile IPv6 [RFC6275] and Proxy Mobile IPv6 [RFC5213], respectively." 9. For Figures 1 and 2, it is good if the figure titles are "Architectural view of centralized mobility management" and "Architectural view of distributed mobility management". 10. In Section 3.2, two terms, i.e., distributed mobility management and flat IP architecture, are used, but (from my point of view) a relation between them is not well described at Section 3.1 or even before at the document. Readers might be confused when the terms, i.e., distributed mobility management, dynamic mobility management, and flat IP architecture, are used together without explicit descriptions of them, e.g., centralized vs. distributed mobility managements, fixed anchor vs. dynamic mobility managements, and hierarchical vs. flat architecture. Note that for cellular network guys it must be wonderful if this document also provides some differences between dynamic mobility management (i.e., selectively providing mobility support) and paging (or anchor point management schemes) being used in cellular networks. 11. In Section 3.2, you wrote as "It has therefore been proposed to adapt MIP or PMIPv6 to achieve distributed mobility management by using a distributed mobility anchor architecture." Could you kindly provide any reference for this? No offense, I'm also looking for references of it. ;) 12. In Section 4.1, you have mentioned about location privacy: when a mobile node directly communicates its correspondent node, its location is open to the correspondent node. Yes, that's true, but the disclosure of address to a communication node, i.e., the correspondent node, is natural. In other words, thanks to the use of home address, the hiding of the real address, i.e., care-of address, is just an advantage of having the mobility anchor. So, the disclosure of care-of address when route optimization in MIPv6 is not subject to blame for location privacy...it is an prerequisite essential. 13. Any references for "These network functions can be the content servers in a CDN, and also the data anchor point." or "Mobile networks have been evolving from a hierarchical architecture to a more flattened architecture." in Section 4.2. 14. In Section 4.3, the following sentence "... a novel mobility management approach should be designed for such networks ..." is enough with a "new" word, instead of "novel". I'm sure that it is the distributed mobility management with a flatten network architecture, which as you mentioned is being required or introduced in existing networks to overcome limitations of the centralized mobility management. Note that it is better not to use "color words" in standardization documents and scientific papers. 15. Section 4.4 describes a tunnel management between mobility entities. However, I do not see your justification for low scalability of centralized route and mobility context maintenance. 16. In Section 4.5, I suppose the following sentences "In addition, it is possible to have the intelligence for applications to manage mobility without needing help from the network. Network resources are therefore wasted to provide mobility support for the devices that do not really need it at the moment." do not quite related to the proposal of Section 4.5. If an intelligence functionality could help to handle such a case, it is also applied to a centralized mobility management, not only to a distributed one, isn't it? In addition, as I mentioned before, it would be great if you provide some text to describe what the differences between the dynamic mobility management mechanism and paging (or anchor point management schemes) are. 17. The title of Figure 5 should be changed; it is not only showing the bidirectional tunneling case, but also showing the route optimization case. ;) Hope this would help. Cheers. -- IMARA Team, INRIA, France Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random #email: jong-hyouk.lee (at) inria.fr || hurryon (at) gmail.com #webpage: http://sites.google.com/site/hurryon/ From rkuntz@us.toyota-itc.com Tue Nov 1 11:19:59 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2C311E80E6 for ; Tue, 1 Nov 2011 11:19:59 -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=[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 6G39vDbmGFJ5 for ; Tue, 1 Nov 2011 11:19:58 -0700 (PDT) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by ietfa.amsl.com (Postfix) with SMTP id F1AD511E80C9 for ; Tue, 1 Nov 2011 11:19:57 -0700 (PDT) Received: from mail-gx0-f172.google.com ([209.85.161.172]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP; Tue, 01 Nov 2011 11:19:58 PDT Received: by mail-gx0-f172.google.com with SMTP id v1so8700812ggn.31 for ; Tue, 01 Nov 2011 11:19:20 -0700 (PDT) Received: by 10.150.143.18 with SMTP id q18mr1738833ybd.81.1320171560352; Tue, 01 Nov 2011 11:19:20 -0700 (PDT) Received: from dmohan.paloalto.toyota-itc.com ([206.132.173.18]) by mx.google.com with ESMTPS id p5sm63944111anl.18.2011.11.01.11.19.16 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Nov 2011 11:19:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Romain KUNTZ In-Reply-To: <4EAF1E39.3020209@earthlink.net> Date: Tue, 1 Nov 2011 11:19:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7793C4DA-B675-4730-8079-AE4FE08A3501@us.toyota-itc.com> References: <20110803185832.21283.61262.idtracker@ietfa.amsl.com><4E399F6E.8090508@computer.org><75B8624B-6C94-4B7F-9487-DCF0E06B5256@us.toyota-itc.com> <4EAB1A93.8050605@computer.org> <4EAF1E39.3020209@earthlink.net> To: Charles E. Perkins X-Mailer: Apple Mail (2.1251.1) Cc: charliep@computer.org, mext Subject: Re: [MEXT] New Version Notification fordraft-perkins-mext-hatunaddr-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 18:19:59 -0000 Hello Charlie, That's right, I believe the signaling still goes to the primary HA and = thus can be secured as usual, and as mandated by the MIPv6 spec.=20 Beside, the mobile node can choose to send the IPsec'd traffic through = its primary HA if needed. Thank you, Romain On Oct 31, 2011, at 15:16, Charles E. Perkins wrote: > Hello again Romain, >=20 > I didn't have time to do the specification for any > new extension for the suggested options revised from > RFC 3957. I'll try to do it later this week, but the > result can't be officially submitted until I get to > the IETF. >=20 > Anyway, traffic to/from the mobile node <--> home agent > doesn't always have to be protected, especially looking > at the relative proportion of data traffic today that > is sent via IPsec. It seems to me that the problem is > important, and must be solved, but not a showstopper. >=20 > Regards, > Charlie P. >=20 >=20 >=20 > On 10/28/2011 2:11 PM, Charles E. Perkins wrote: >> Hello Romain, >>=20 >> Thank you for reminding me about this point. It had been >> raised previously during some related discussions for DMM >> late last year, and I plainly forgot to fill in any details >> about the problem. >>=20 >> After looking over RFC 3957, I think the most efficient way >> towards solution will be to define a new extension similar >> to the Generalized MN-HA Key Generation Nonce Request and >> Generalized MN-HA Key Generation Nonce Reply extensions. >> It's not a perfect fit, but it's pretty close. If there is >> any interest for an IPv4-based solution, I could easily >> write up a new subtype for the RFC 3957 (IPv4) extensions. >>=20 >> The formula for calculating the key in Section 5 needs to be >> updated, perhaps to the following: >> key =3D HMAC-SHA1 (HA-key, >> {Key Generation Nonce || >> mobile node identifier || >> HA-D IPv6_address}) >>=20 >> A similar formula would apply for any specification >> in which the key nonce was generated by AAA instead of >> the [control-plane] Home Agent [HA-C]. >>=20 >> The manner in which the HA-D get the corresponding >> configuration information doesn't have to be specified >> in the ...mext-hatunaddr... draft. >>=20 >> I'll try to get an updated draft out before the draft >> deadline on Monday. Thanks for your comment. While >> mostly straightforward, the update will take a pretty >> good bit of carefully written text. >>=20 >> Regards, >> Charlie P. >>=20 >>=20 >> On 8/4/2011 11:39 AM, Romain KUNTZ wrote: >>> Hello Charlie, >>>=20 >>> If the MN has to tunnel data to a different HA than the one to which >>> it sends the BU, then it also needs an IPsec SA with that HA. How >>> would the MN create such SA as it does not know in advance what HA = it >>> may use for tunneling? My guess is that the MN is supposed to trust >>> the address received in the option and create the SA upon reception = of >>> the option. Similarly, all of the HA tunneling box would also need = to >>> be configured with the corresponding SA. Some considerations about >>> that may be needed in the draft. >>>=20 >>> Regards, >>> romain >>>=20 >>>=20 >>> On Aug 3, 2011, at 12:20, Charles E. Perkins wrote: >>>=20 >>>>=20 >>>> Hello folks, >>>>=20 >>>> My draft has now made it through the submission process. >>>> Please excuse the repeat notification... >>>>=20 >>>> Comments will be appreciated. >>>>=20 >>>> Regards, >>>> Charlie P. >>>>=20 >>>>=20 >>>> -------- Original Message -------- >>>> Subject: New Version Notification for >>>> draft-perkins-mext-hatunaddr-01.txt >>>> Date: Wed, 03 Aug 2011 11:58:32 -0700 >>>> From: >>>> To: >>>> CC: >>>>=20 >>>> A new version of I-D, draft-perkins-mext-hatunaddr-01.txt has been >>>> successfully submitted by Charles Perkins and posted to the IETF >>>> repository. >>>>=20 >>>> Filename: draft-perkins-mext-hatunaddr >>>> Revision: 01 >>>> Title: Alternate Tunnel Source Address for Home Agent >>>> Creation date: 2011-08-03 >>>> WG ID: Individual Submission >>>> Number of pages: 10 >>>>=20 >>>> Abstract: >>>> Widely deployed mobility management systems for wireless >>>> communications have isolated the path for forwarding data from the >>>> control plane signaling for mobility management. To realize this >>>> requirement with Mobile IP requires that the control functions of = the >>>> home agent be addressable at a different IP address than the source >>>> IP address of the tunnel between the home agent and mobile node. >>>> Similar considerations hold for mobility anchors implementing >>>> Hierarchical Mobile IP or PMIP. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> The IETF Secretariat >>>>=20 >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>=20 >>>=20 >>=20 >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >>=20 >=20 From sarikaya2012@gmail.com Tue Nov 1 11:55:25 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C425A11E811F for ; Tue, 1 Nov 2011 11:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 PZDnfkTxIXi8 for ; Tue, 1 Nov 2011 11:55:24 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 80BC111E814E for ; Tue, 1 Nov 2011 11:55:24 -0700 (PDT) Received: by ywt2 with SMTP id 2so8755673ywt.31 for ; Tue, 01 Nov 2011 11:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=TEBE8r148ubK3WgYoWUEUtxl47rQhmmou7oYSoFnwv8=; b=nRV5Cj0teXt0e6M4H07ye6RMAkMKkxXR5/RQZI19rHSbTIXDq+iFlRRUVJFs8Rq0d0 ORBY+FnswOXqE7GobZjKXAbOPBFw7xPnfDblhfE+/U/yNmsPAwl074bLm5zx6K0Uk32R y45F2T5sbsoDA9V/tVfUoUWUZUQrmGQ6Npfbo= MIME-Version: 1.0 Received: by 10.236.115.129 with SMTP id e1mr1337125yhh.77.1320173524813; Tue, 01 Nov 2011 11:52:04 -0700 (PDT) Received: by 10.236.108.135 with HTTP; Tue, 1 Nov 2011 11:52:04 -0700 (PDT) In-Reply-To: <7793C4DA-B675-4730-8079-AE4FE08A3501@us.toyota-itc.com> References: <20110803185832.21283.61262.idtracker@ietfa.amsl.com> <4E399F6E.8090508@computer.org> <75B8624B-6C94-4B7F-9487-DCF0E06B5256@us.toyota-itc.com> <4EAB1A93.8050605@computer.org> <4EAF1E39.3020209@earthlink.net> <7793C4DA-B675-4730-8079-AE4FE08A3501@us.toyota-itc.com> Date: Tue, 1 Nov 2011 13:52:04 -0500 Message-ID: From: Behcet Sarikaya To: Romain KUNTZ Content-Type: multipart/alternative; boundary=20cf303a2bb5fd05ec04b0b0d973 Cc: charliep@computer.org, mext Subject: Re: [MEXT] New Version Notification fordraft-perkins-mext-hatunaddr-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 18:55:25 -0000 --20cf303a2bb5fd05ec04b0b0d973 Content-Type: text/plain; charset=ISO-8859-1 Hi Romain, Charlie, I added a new section in draft-sarikaya-mext-multicastdmm-04.txt on this. I don't think we need new types, more extensions. Please check. Regards, Behcet On Tue, Nov 1, 2011 at 1:19 PM, Romain KUNTZ wrote: > Hello Charlie, > > That's right, I believe the signaling still goes to the primary HA and > thus can be secured as usual, and as mandated by the MIPv6 spec. > Beside, the mobile node can choose to send the IPsec'd traffic through its > primary HA if needed. > > Thank you, > Romain > > On Oct 31, 2011, at 15:16, Charles E. Perkins wrote: > > > Hello again Romain, > > > > I didn't have time to do the specification for any > > new extension for the suggested options revised from > > RFC 3957. I'll try to do it later this week, but the > > result can't be officially submitted until I get to > > the IETF. > > > > Anyway, traffic to/from the mobile node <--> home agent > > doesn't always have to be protected, especially looking > > at the relative proportion of data traffic today that > > is sent via IPsec. It seems to me that the problem is > > important, and must be solved, but not a showstopper. > > > > Regards, > > Charlie P. > > > > > > > > On 10/28/2011 2:11 PM, Charles E. Perkins wrote: > >> Hello Romain, > >> > >> Thank you for reminding me about this point. It had been > >> raised previously during some related discussions for DMM > >> late last year, and I plainly forgot to fill in any details > >> about the problem. > >> > >> After looking over RFC 3957, I think the most efficient way > >> towards solution will be to define a new extension similar > >> to the Generalized MN-HA Key Generation Nonce Request and > >> Generalized MN-HA Key Generation Nonce Reply extensions. > >> It's not a perfect fit, but it's pretty close. If there is > >> any interest for an IPv4-based solution, I could easily > >> write up a new subtype for the RFC 3957 (IPv4) extensions. > >> > >> The formula for calculating the key in Section 5 needs to be > >> updated, perhaps to the following: > >> key = HMAC-SHA1 (HA-key, > >> {Key Generation Nonce || > >> mobile node identifier || > >> HA-D IPv6_address}) > >> > >> A similar formula would apply for any specification > >> in which the key nonce was generated by AAA instead of > >> the [control-plane] Home Agent [HA-C]. > >> > >> The manner in which the HA-D get the corresponding > >> configuration information doesn't have to be specified > >> in the ...mext-hatunaddr... draft. > >> > >> I'll try to get an updated draft out before the draft > >> deadline on Monday. Thanks for your comment. While > >> mostly straightforward, the update will take a pretty > >> good bit of carefully written text. > >> > >> Regards, > >> Charlie P. > >> > >> > >> On 8/4/2011 11:39 AM, Romain KUNTZ wrote: > >>> Hello Charlie, > >>> > >>> If the MN has to tunnel data to a different HA than the one to which > >>> it sends the BU, then it also needs an IPsec SA with that HA. How > >>> would the MN create such SA as it does not know in advance what HA it > >>> may use for tunneling? My guess is that the MN is supposed to trust > >>> the address received in the option and create the SA upon reception of > >>> the option. Similarly, all of the HA tunneling box would also need to > >>> be configured with the corresponding SA. Some considerations about > >>> that may be needed in the draft. > >>> > >>> Regards, > >>> romain > >>> > >>> > >>> On Aug 3, 2011, at 12:20, Charles E. Perkins wrote: > >>> > >>>> > >>>> Hello folks, > >>>> > >>>> My draft has now made it through the submission process. > >>>> Please excuse the repeat notification... > >>>> > >>>> Comments will be appreciated. > >>>> > >>>> Regards, > >>>> Charlie P. > >>>> > >>>> > >>>> -------- Original Message -------- > >>>> Subject: New Version Notification for > >>>> draft-perkins-mext-hatunaddr-01.txt > >>>> Date: Wed, 03 Aug 2011 11:58:32 -0700 > >>>> From: > >>>> To: > >>>> CC: > >>>> > >>>> A new version of I-D, draft-perkins-mext-hatunaddr-01.txt has been > >>>> successfully submitted by Charles Perkins and posted to the IETF > >>>> repository. > >>>> > >>>> Filename: draft-perkins-mext-hatunaddr > >>>> Revision: 01 > >>>> Title: Alternate Tunnel Source Address for Home Agent > >>>> Creation date: 2011-08-03 > >>>> WG ID: Individual Submission > >>>> Number of pages: 10 > >>>> > >>>> Abstract: > >>>> Widely deployed mobility management systems for wireless > >>>> communications have isolated the path for forwarding data from the > >>>> control plane signaling for mobility management. To realize this > >>>> requirement with Mobile IP requires that the control functions of the > >>>> home agent be addressable at a different IP address than the source > >>>> IP address of the tunnel between the home agent and mobile node. > >>>> Similar considerations hold for mobility anchors implementing > >>>> Hierarchical Mobile IP or PMIP. > >>>> > >>>> > >>>> > >>>> > >>>> The IETF Secretariat > >>>> > >>>> _______________________________________________ > >>>> MEXT mailing list > >>>> MEXT@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mext > >>> > >>> > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > >> > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > --20cf303a2bb5fd05ec04b0b0d973 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Romain, Charlie,
=A0 I added a new section in

draft-sarikaya-= mext-multicastdmm-04.txt

on this. I don= 9;t think we need new types, more extensions.

Please check.

R= egards,

Behcet
On Tue, Nov 1, 2011 at 1:19 PM, Ro= main KUNTZ <rkuntz@us.toyota-itc.com> wrote:
Hello Charlie,

That's right, I believe the signaling still goes to the primary HA and = thus can be secured as usual, and as mandated by the MIPv6 spec.
Beside, the mobile node can choose to send the IPsec'd traffic through = its primary HA if needed.

Thank you,
Romain

On Oct 31, 2011, at 15:16, Charles E. Perkins wrote:

> Hello again Romain,
>
> I didn't have time to do the specification for any
> new extension for the suggested options revised from
> RFC 3957. =A0I'll try to do it later this week, but the
> result can't be officially submitted until I get to
> the IETF.
>
> Anyway, traffic to/from the mobile node <--> home agent
> doesn't always have to be protected, especially looking
> at the relative proportion of data traffic today that
> is sent via IPsec. =A0It seems to me that the problem is
> important, and must be solved, but not a showstopper.
>
> Regards,
> Charlie P.
>
>
>
> On 10/28/2011 2:11 PM, Charles E. Perkins wrote:
>> Hello Romain,
>>
>> Thank you for reminding me about this point. It had been
>> raised previously during some related discussions for DMM
>> late last year, and I plainly forgot to fill in any details
>> about the problem.
>>
>> After looking over RFC 3957, I think the most efficient way
>> towards solution will be to define a new extension similar
>> to the Generalized MN-HA Key Generation Nonce Request and
>> Generalized MN-HA Key Generation Nonce Reply extensions.
>> It's not a perfect fit, but it's pretty close. If there is=
>> any interest for an IPv4-based solution, I could easily
>> write up a new subtype for the RFC 3957 (IPv4) extensions.
>>
>> The formula for calculating the key in Section 5 needs to be
>> updated, perhaps to the following:
>> key =3D HMAC-SHA1 (HA-key,
>> {Key Generation Nonce ||
>> mobile node identifier ||
>> HA-D IPv6_address})
>>
>> A similar formula would apply for any specification
>> in which the key nonce was generated by AAA instead of
>> the [control-plane] Home Agent [HA-C].
>>
>> The manner in which the HA-D get the corresponding
>> configuration information doesn't have to be specified
>> in the ...mext-hatunaddr... draft.
>>
>> I'll try to get an updated draft out before the draft
>> deadline on Monday. Thanks for your comment. While
>> mostly straightforward, the update will take a pretty
>> good bit of carefully written text.
>>
>> Regards,
>> Charlie P.
>>
>>
>> On 8/4/2011 11:39 AM, Romain KUNTZ wrote:
>>> Hello Charlie,
>>>
>>> If the MN has to tunnel data to a different HA than the one to= which
>>> it sends the BU, then it also needs an IPsec SA with that HA. = How
>>> would the MN create such SA as it does not know in advance wha= t HA it
>>> may use for tunneling? My guess is that the MN is supposed to = trust
>>> the address received in the option and create the SA upon rece= ption of
>>> the option. Similarly, all of the HA tunneling box would also = need to
>>> be configured with the corresponding SA. Some considerations a= bout
>>> that may be needed in the draft.
>>>
>>> Regards,
>>> romain
>>>
>>>
>>> On Aug 3, 2011, at 12:20, Charles E. Perkins wrote:
>>>
>>>>
>>>> Hello folks,
>>>>
>>>> My draft has now made it through the submission process. >>>> Please excuse the repeat notification...
>>>>
>>>> Comments will be appreciated.
>>>>
>>>> Regards,
>>>> Charlie P.
>>>>
>>>>
>>>> -------- Original Message --------
>>>> Subject: New Version Notification for
>>>> draft-perkins-mext-hatunaddr-01.txt
>>>> Date: Wed, 03 Aug 2011 11:58:32 -0700
>>>> From:<inter= net-drafts@ietf.org>
>>>> To:<charliep@c= omputer.org>
>>>> CC:<charliep@c= omputer.org>
>>>>
>>>> A new version of I-D, draft-perkins-mext-hatunaddr-01.txt = has been
>>>> successfully submitted by Charles Perkins and posted to th= e IETF
>>>> repository.
>>>>
>>>> Filename: draft-perkins-mext-hatunaddr
>>>> Revision: 01
>>>> Title: Alternate Tunnel Source Address for Home Agent
>>>> Creation date: 2011-08-03
>>>> WG ID: Individual Submission
>>>> Number of pages: 10
>>>>
>>>> Abstract:
>>>> Widely deployed mobility management systems for wireless >>>> communications have isolated the path for forwarding data = from the
>>>> control plane signaling for mobility management. To realiz= e this
>>>> requirement with Mobile IP requires that the control funct= ions of the
>>>> home agent be addressable at a different IP address than t= he source
>>>> IP address of the tunnel between the home agent and mobile= node.
>>>> Similar considerations hold for mobility anchors implement= ing
>>>> Hierarchical Mobile IP or PMIP.
>>>>
>>>>
>>>>
>>>>
>>>> The IETF Secretariat
>>>>
>>>> _______________________________________________
>>>> MEXT mailing list
>>>> MEXT@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mext
>>>
>>>
>>
>> _______________________________________________
>> MEXT mailing list
>> MEXT@ietf.org
>> https://www.ietf.org/mailman/listinfo/mext
>>
>

_______________________________________________
MEXT mailing list
MEXT@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mext

--20cf303a2bb5fd05ec04b0b0d973-- From sarikaya2012@gmail.com Tue Nov 1 12:58:25 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617EC11E815E for ; Tue, 1 Nov 2011 12:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 bgudOZCFSMqg for ; Tue, 1 Nov 2011 12:58:24 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C937711E812D for ; Tue, 1 Nov 2011 12:58:24 -0700 (PDT) Received: by ywt2 with SMTP id 2so8817048ywt.31 for ; Tue, 01 Nov 2011 12:57:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=CRSommayZYFRqQmaxfG6i2b+rap0ezsKMH6m2iVTAWM=; b=g9GEHtnDK88tjD9gABeX+je5T6TvFqGmb8sq2eF1UY373NZS9kGCfQUV2zE+ZUh/La m0Lu8hCaBY0oyXAmmlPixVvCSjq3TIBgA+ZYTvHF/tGF0/RLEinrqlYX7p/Hf/bJDBdY Fw0Hhb4OcK0ClYiKxVlHk0Is4caPS+lIyGft0= MIME-Version: 1.0 Received: by 10.236.124.103 with SMTP id w67mr1369569yhh.94.1320177424437; Tue, 01 Nov 2011 12:57:04 -0700 (PDT) Received: by 10.236.108.135 with HTTP; Tue, 1 Nov 2011 12:57:04 -0700 (PDT) In-Reply-To: <4EB04C8B.6090607@computer.org> References: <20110803185832.21283.61262.idtracker@ietfa.amsl.com> <4E399F6E.8090508@computer.org> <75B8624B-6C94-4B7F-9487-DCF0E06B5256@us.toyota-itc.com> <4EAB1A93.8050605@computer.org> <4EAF1E39.3020209@earthlink.net> <7793C4DA-B675-4730-8079-AE4FE08A3501@us.toyota-itc.com> <4EB04C8B.6090607@computer.org> Date: Tue, 1 Nov 2011 14:57:04 -0500 Message-ID: From: Behcet Sarikaya To: charliep@computer.org Content-Type: multipart/alternative; boundary=20cf3010ed576c925804b0b1c28d Cc: mext Subject: Re: [MEXT] New Version Notification fordraft-perkins-mext-hatunaddr-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 19:58:25 -0000 --20cf3010ed576c925804b0b1c28d Content-Type: text/plain; charset=ISO-8859-1 Hi Charlie, On Tue, Nov 1, 2011 at 2:46 PM, Charles E. Perkins wrote: > Hello Behcet, > > > > On 11/1/2011 11:52 AM, Behcet Sarikaya wrote: > >> Hi Romain, Charlie, >> I added a new section in >> >> draft-sarikaya-mext-**multicastdmm-04.txt >> >> on this. I don't think we need new types, more extensions. >> >> Please check. >> > > I don't think that the Alternate Care-of Address > can be used, since Alt_CoA has to do with the > addressability of the mobile node, not anything > about the Home Agent [or HA-D]. > > I understand your point. In the interest of minimizing extensions needed for DMM, I had kept the option of using AltCoA which was already suggested earlier by some people. If we have to use extensions we have to use extensions, no escape. Regards, Behcet --20cf3010ed576c925804b0b1c28d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Charlie,



On Tue, Nov 1, 2011 a= t 2:46 PM, Charles E. Perkins <charliep@computer.org> wrote:
Hello Behcet,



On 11/1/2011 11:52 AM, Behcet Sarikaya wrote:
Hi Romain, Charlie,
=A0 I added a new section in

draft-sarikaya-mext-multicastdmm-04.txt

on this. I don't think we need new types, more extensions.

Please check.

I don't think that the Alternate Care-of Address
can be used, since Alt_CoA has to do with the
addressability of the mobile node, not anything
about the Home Agent [or HA-D].

I understand your point. In the interest of minimizin= g extensions needed for DMM, I had kept the option of using AltCoA which wa= s already suggested earlier by some people.
If we have to use extensions= we have to use extensions, no escape.

Regards,

Behcet
--20cf3010ed576c925804b0b1c28d-- From charliep@computer.org Tue Nov 1 13:21:47 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A892A11E80B7 for ; Tue, 1 Nov 2011 13:21:47 -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 qWxrkFPxx2xp for ; Tue, 1 Nov 2011 13:21:47 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2F07911E808C for ; Tue, 1 Nov 2011 13:21:47 -0700 (PDT) Received: from [138.111.58.2] (helo=[172.17.96.136]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1RLKHu-0003Hu-7Y; Tue, 01 Nov 2011 15:46:22 -0400 Message-ID: <4EB04C8B.6090607@computer.org> Date: Tue, 01 Nov 2011 12:46:19 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: sarikaya@ieee.org, Behcet Sarikaya References: <20110803185832.21283.61262.idtracker@ietfa.amsl.com><4E399F6E.8090508@computer.org><75B8624B-6C94-4B7F-9487-DCF0E06B5256@us.toyota-itc.com><4EAB1A93.8050605@computer.org><4EAF1E39.3020209@earthlink.net><7793C4DA-B675-4730-8079-AE4FE08A3501@us.toyota-itc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad869414f512dd60b0f57c29c9b6280b19fa350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Cc: mext Subject: Re: [MEXT] New Version Notification fordraft-perkins-mext-hatunaddr-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: charliep@computer.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 20:21:47 -0000 Hello Behcet, On 11/1/2011 11:52 AM, Behcet Sarikaya wrote: > Hi Romain, Charlie, > I added a new section in > > draft-sarikaya-mext-multicastdmm-04.txt > > on this. I don't think we need new types, more extensions. > > Please check. I don't think that the Alternate Care-of Address can be used, since Alt_CoA has to do with the addressability of the mobile node, not anything about the Home Agent [or HA-D]. Regards, Charlie P. PS. Thanks for citing my draft! From ryuji.wakikawa@gmail.com Tue Nov 1 15:31:26 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED00211E8127 for ; Tue, 1 Nov 2011 15:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 J2l-NTA6kOk1 for ; Tue, 1 Nov 2011 15:31:26 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4F50C11E8124 for ; Tue, 1 Nov 2011 15:31:26 -0700 (PDT) Received: by gye5 with SMTP id 5so231122gye.31 for ; Tue, 01 Nov 2011 15:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=5F0boYMwyIkTy34BXzE8iWfhh+jssCCxjv7z+ao6Yyk=; b=HsCe/6Tcq2wgNBZ17NRUT1OPnWNImafNAd3JPXY6hhYLl7w00uc4Vbwig+suCIAgvF WkNARhCjVZCQI9fINqFn2DB+nbAKX51C3EWOE8NbIVtMyfkIw+yDo0xQwU+SMJHhe2yn 3p6ouvP0+gkCUUjpjgNSaUcZu7peqsrOVfNLw= Received: by 10.100.216.3 with SMTP id o3mr424631ang.88.1320186685900; Tue, 01 Nov 2011 15:31:25 -0700 (PDT) Received: from [192.168.110.139] ([206.132.173.18]) by mx.google.com with ESMTPS id 22sm1069607anp.12.2011.11.01.15.31.23 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Nov 2011 15:31:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ryuji Wakikawa In-Reply-To: <4EAEFE03.3010900@piuha.net> Date: Tue, 1 Nov 2011 15:31:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <915178E8-4E48-4501-A433-E277564673BC@gmail.com> References: <4EAA9B4A.3020208@piuha.net> <4EAEFE03.3010900@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1084) Cc: "jouni.korhonen@nsn.com" , "mext@ietf.org" Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 22:31:27 -0000 Jari, I don't see any objection during WGLC. In fact, we had thoughtful = reviews and improved the document.=20 I am fine either AD-sponsor or regular WG procedure, but I need to see = progress. WGLC was ended at Aug 1. thanks ryuji On 2011/10/31, at 12:58, Jari Arkko wrote: > Did it successfully complete WGLC? With sufficient support for taking = the document forward? If yes, the chairs can either send it immediately = to me as a WG output. >=20 > Or I can AD sponsor it later. The offer to AD sponsor is also valid = for other documents. They need to be in reasonable shape, naturally. >=20 > Jari >=20 > On 31.10.2011 19:08, Ryuji Wakikawa wrote: >> Jari >>=20 >> Thanks for this update. I want to clarify plan of the existing = activity, HA reliability doc, in MEXT. >> This document completed WGLC and went nowhere after all. >> It supposes to be proposed standard RFC. >> Do you want to finish this work with AD sponsor? or just trash it? >>=20 >> thanks >> ryuji >>=20 >> On 2011/10/28, at 5:08, Jari Arkko wrote: >>=20 >>> All, >>>=20 >>> We are making some changes to the working group. While we have = successfully published a large number of specifications in recent years, = recently it has been difficult to make progress in the group. The chairs = and ADs have looked at the situation and we believe we need a new focus = and a bit of new organization as well. We are terminating the working = group and moving the one remaining active work item to a new working = group, the "DMM" working group. Here's what is going to happen: >>>=20 >>> o Jouni Korhonen and Julien Laganier will become the chairs of the = group. >>>=20 >>> o The group will meet in Taipei (there is a MEXT slot in the = agenda). >>>=20 >>> o The charter of the group will be changed to focus only on the = distributed mobility effort. We should discuss the details of this = charter change both on the list and in the meeting. The meeting agenda = should reserve some time both for technical discussions as well as the = charter discussion. >>>=20 >>> o Once the discussion on the list and in the meeting has finished, = we will rename the group to "DMM" and put the new charter in effect. >>>=20 >>> o If there are any other specifications that people would like to = publish beyond the distributed mobility work, we can offer to AD sponsor = them to RFCs outside the new working group. If there is some significant = new activity, we can create new working groups for that. >>>=20 >>> Comments and feedback and/or alternate suggestions on this plan are = welcome. >>>=20 >>> We would like to thank Marcelo for your many years of service in = MEXT. We could not have completed all the work we did without your = energy and push for high quality results. We would also like to thank = Jouni for taking on this new challenge, and Julien for continuing the = work in this space. >>>=20 >>> Jari and Ralph >>>=20 >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>=20 >=20 From julien.ietf@gmail.com Tue Nov 1 16:08:33 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB6911E80ED for ; Tue, 1 Nov 2011 16:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.237 X-Spam-Level: X-Spam-Status: No, score=-3.237 tagged_above=-999 required=5 tests=[AWL=0.362, 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 62tYFxW7t30G for ; Tue, 1 Nov 2011 16:08:33 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id B320F21F9E36 for ; Tue, 1 Nov 2011 16:08:32 -0700 (PDT) Received: by faas12 with SMTP id s12so8287076faa.31 for ; Tue, 01 Nov 2011 16:08:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6GbPsTMFzIiWZsdF1WPMrkUP9lJefAoUWLHkebePtb4=; b=mBe/hK15AHnm43OCl5nHS/gvSEzSbo9gaqRzAAL3UqHq9+T2Wtl7z4Wf7q/2iWWvNj nLYL9LyUwQaLnWUYwvJd+0djVzyyR9kGxvCRDYsgrF//ZbuGeef0tR+SWjGu6fkWemat 0oOPn5cFjWXkMGPfWu5OFLB1hT8heqQemXw20= MIME-Version: 1.0 Received: by 10.223.5.66 with SMTP id 2mr3819500fau.26.1320188910066; Tue, 01 Nov 2011 16:08:30 -0700 (PDT) Received: by 10.223.155.65 with HTTP; Tue, 1 Nov 2011 16:08:30 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Nov 2011 16:08:30 -0700 Message-ID: From: Julien Laganier To: luo.wen@zte.com.cn Content-Type: text/plain; charset=ISO-8859-1 Cc: Dapeng Liu , Jouni , "mext@ietf.org" Subject: Re: [MEXT] A request to present a draft in MEXT, IETF82 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 23:08:33 -0000 Dear Luo Wen, The chairs are working on the agenda. We only have a one hour slot thus we might not be able to accomodate all requests but we will let you know ASAP. Best, --julien On Tue, Oct 18, 2011 at 2:15 AM, wrote: > > Dear Chair: > > I request a slot (about 15min) to present a draft which is related to > DMMduring the meeting. > > For your reference, the draft 00-version can be reviewed in > http://tools.ietf.org/html/draft-liu-dmm-pmip-based-approach-00. > > Please consider my request. > > BR > LUOWEN From jouni.nospam@gmail.com Wed Nov 2 02:09:27 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B94721F9EAC for ; Wed, 2 Nov 2011 02:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 lOLgBy-h2FkM for ; Wed, 2 Nov 2011 02:09:27 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id BEAEC21F9EAE for ; Wed, 2 Nov 2011 02:09:26 -0700 (PDT) Received: by eyg24 with SMTP id 24so7498338eyg.31 for ; Wed, 02 Nov 2011 02:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=z+Ar3fjNqTkX0yJyZcdD/B/vmpb6Z8Es2cQixUW4tCI=; b=ZHJrno8HARgZMncgfGSvyG2qXs7WC4wVCt3Ff+49lo70QqJmjs4oeFvlvoFLR3nUYe OoGAoHamrYrtNUNO0byoPVFxlNv3+sBfPE6ysrqVBUJguQ6PutWD/1NafQBrnngmT1Ff xqPZlx0Qx1ezhqpiWstGKJb5mQ3+akewDESfE= Received: by 10.213.27.131 with SMTP id i3mr1628031ebc.85.1320224965851; Wed, 02 Nov 2011 02:09:25 -0700 (PDT) Received: from dhcp-27-53.ripemtg.ripe.net (dhcp-27-53.ripemtg.ripe.net. [193.0.27.53]) by mx.google.com with ESMTPS id t6sm4638614eeb.11.2011.11.02.02.09.23 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Nov 2011 02:09:24 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Nov 2011 11:09:18 +0200 Message-Id: <08376A56-ACA7-4653-A4F8-EEDCE55B45F4@gmail.com> To: mext Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Julien Laganier , jouni korhonen Subject: [MEXT] draft agenda uploaded X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 09:09:27 -0000 Folks, The draft agenda can be found here: http://www.ietf.org/proceedings/82/agenda/mext.txt Note that we only have 1h slot, so squeezing I-D presentations into the = agenda was a bit challenging assuming we also want to have some = meaningful discussion on the charter and related concerns. So as a = guideline for presenters. Prepare one slide that states what is the = *beef* of your proposal and then have the discussion. Chairs will show = the slide, so no swapping of laptops etc. - Julien & Jouni= From pierrick.seite@orange.com Wed Nov 2 08:10:47 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190A811E80B6 for ; Wed, 2 Nov 2011 08:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=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 Ej9FqviYs7MK for ; Wed, 2 Nov 2011 08:10:41 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0F711E8099 for ; Wed, 2 Nov 2011 08:10:41 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8AA0FFDC001; Wed, 2 Nov 2011 16:10:30 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 77830FCC001; Wed, 2 Nov 2011 16:10:30 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Nov 2011 16:10:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC9971.8EA9CC70" Date: Wed, 2 Nov 2011 16:10:28 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201FE517F@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4EAA9E34.2080903@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] the future of the MEXT working group Thread-Index: AcyVbCvQALsN14gCTsSiK+VHvMlYoAEBUf5g References: <4EAA9B4A.3020208@piuha.net> <4EAA9E34.2080903@piuha.net> From: To: , X-OriginalArrivalTime: 02 Nov 2011 15:10:29.0957 (UTC) FILETIME=[8F306750:01CC9971] Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 15:10:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC9971.8EA9CC70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jari, =20 Just a minor comment: =20 This charter addresses both the distribution of mobility functions and = the dynamic mobility management. Even if dynamic activation/deactivation = of mobility support can be seen as an enabler to distributed mobility = management, I think the work item acronym should refer to both features. = So, to avoid any ambiguity, I'd suggest to use the acronym DDMM = (Distributed and Dynamic Mobility Management) for the work item. =20 Regards, Pierrick =20 =20 ________________________________ De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part de = Jari Arkko Envoy=E9 : vendredi 28 octobre 2011 14:21 =C0 : mext@ietf.org Objet : Re: [MEXT] the future of the MEXT working group =20 And a follow-up on the charter. I'm describing a couple of different = takes on what the new charter could be. Comments and alternative = proposals are welcome. This is what the current charter says about DMM: The working group will also work on operational considerations on setting up Mobile IPv6 networks so that traffic is distributed in an optimal way, for instance by using existing protocol mechanisms to select the closest home agents for new clients. Oct 2011 - Submit I-D 'Operational considerations for distributed use = of Mobile IPv6' for publication as Informational. Which is admittedly a bit short, but is also very concrete and = achievable, if we work on it. I got another proposal from Hui Deng that = extended this a bit, including going beyond mere operational = considerations. In the past decade a fair number of mobility protocols have been = standardized. Although the protocols differ in terms of functions and = associated message format, we can identify a few key common features: presence of a centralized mobility anchor providing global reachability = and an always-on experience extensions to optimize handover performance while users roam across = wireless cells extensions to enable the use of heterogeneous wireless interfaces for = multi-mode terminals (e.g. cellular phones) The presence of the centralized mobility anchor allows a mobile device = to be reachable when it is not connected to its home domain. The anchor, = among other tasks, ensures forwarding of packets destined to or sent = from the mobile device. As such, most of the deployed architectures = today have a small number of centralized anchors managing the traffic of = millions of mobile subscribers. To optimize handovers for mobile users, 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 impose stringent requirements in terms of delay. Notions of = localization and distribution of local agents have been introduced to = reduce signalling overhead. Unfortunately today we witness difficulties = in getting such protocols deployed, often leading to sub-optimal = choices. Moreover, all the availability of multi-mode devices and the = possibility to use several network interfaces simultaneously have = motivated the development of more new protocol extensions. Mobile users are, more than ever, consuming Internet content, and impose = new requirements on mobile core networks for data traffic delivery. When = this traffic demand exceeds available capacity, service providers need = to implement new strategies such as selective traffic offload (e.g. 3GPP = work items LIPA/SIPTO) through alternative access networks (e.g. WLAN). = Moreover, the localization of content providers closer to the = Mobile/Fixed Internet Service Providers network requires taking into = account local Content Delivery Networks (CDNs) while providing mobility = services. =20 As long as demand exceeds capacity, both offloading and CDN techniques = could benefit from the development of more flat mobile architectures = (i.e., fewer levels of routing hierarchy introduced into the data path = by the mobility management system). This view is reinforced by the shift = in users' traffic behaviour, aimed at increasing direct communications = among peers in the same geographical area. The development of truly flat = mobile architectures would result in anchoring the traffic closer to = point of attachment of the user and overcoming the suboptimal routing = issues of a centralized mobility scheme. While deploying today's mobile networks, service providers face new = challenges. More often than not, mobile devices remain attached to the = same point of attachment, in which case specific IP mobility management = support is not required for applications that launch and complete while = connected to the same point of attachment. However, the mobility support = has been designed to be always on and to maintain the context for each = mobile subscriber as long as they are connected to the network. This can = result in a waste of resources and ever-increasing costs for the service = provider. Infrequent mobility and intelligence of many applications = suggest that mobility can be provided dynamically, thus simplifying the = context maintained in the different nodes of the mobile network. The proposed charter will address two complementary aspects of mobility = management procedures: the distribution of mobility anchors to achieve a = more flat design and the dynamic activation/deactivation of mobility = protocol support as an enabler to distributed mobility management. The = former has the goal of positioning mobility anchors (HA, LMA) closer to = the user; ideally, these mobility anchors could be collocated with the = first hop router. The latter, facilitated by the distribution of = mobility anchors, aims at identifying when mobility must be activated = and identifying sessions that do not impose mobility management -- thus = reducing the amount of state information to be maintained in the various = mobility anchors of the mobile network. The key idea is that dynamic = mobility management relaxes some constraints while also repositioning = mobility anchors; it avoids the establishment of non optimal tunnels = between two anchors topologically distant.=20 Considering the above, the working group will: Define the problem statement and associated requirements for distributed = mobility management. This work aims at defining the problem space and = identifies the key functional requirements. Produce a gap analysis mapping the above requirements against existing = solutions. Give best practices for the deployment of existing mobility protocols in = a distributed mobility management and describe limitations of each such = approach. Describe extensions, if needed, to current mobility protocols for their = application in distributed mobility architectures=20 Comments? Jari ------_=_NextPart_001_01CC9971.8EA9CC70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Jari,

 =

Just a minor = comment:

 =

This charter = addresses both the distribution of mobility functions and the dynamic mobility management. Even if dynamic activation/deactivation of mobility support = can be seen as an enabler to distributed mobility management, I think the work = item acronym should refer to both features. So, to avoid any ambiguity, = I’d suggest to use the acronym DDMM (Distributed and Dynamic Mobility = Management) for the work item.

 =

Regards,

Pierrick

 

 

De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] = De la part de Jari Arkko
Envoy=E9 : vendredi = 28 octobre 2011 14:21
=C0 : = mext@ietf.org
Objet : Re: [MEXT] = the future of the MEXT working group

 

And a follow-up on the charter. I'm = describing a couple of different takes on what the new charter could be. Comments and alternative proposals are welcome. This is what the current charter says = about DMM:


  The working group will also work on = operational considerations on
  setting up Mobile IPv6 networks so that traffic is = distributed
  in an optimal way, for instance by using existing protocol = mechanisms
  to select the closest home agents for new clients.

  Oct 2011 - Submit I-D 'Operational considerations for distributed = use of Mobile IPv6' for publication as = Informational.


Which is admittedly a bit short, but is also very concrete and = achievable, if we work on it. I got another proposal from Hui Deng that extended this a = bit, including going beyond mere operational considerations.


In the past decade a fair number of mobility = protocols have been standardized. Although the protocols differ in terms of = functions and associated message format, we can identify a few key common = features:
presence of a centralized mobility anchor providing global reachability = and an always-on experience
extensions to optimize handover performance while users roam across = wireless cells
extensions to enable the use of heterogeneous wireless interfaces for multi-mode terminals (e.g. cellular phones)
The presence of the centralized mobility anchor allows a mobile device = to be reachable when it is not connected to its home domain. The anchor, among = other tasks, ensures forwarding of packets destined to or sent from the mobile device. As such, most of the deployed architectures today have a small = number of centralized anchors managing the traffic of millions of mobile = subscribers.

To optimize handovers for mobile users, 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 impose = stringent requirements in terms of delay. Notions of localization and distribution = of local agents have been introduced to reduce signalling overhead. Unfortunately = today we witness difficulties in getting such protocols deployed, often = leading to sub-optimal choices. Moreover, all the availability of multi-mode = devices and the possibility to use several network interfaces simultaneously have = motivated the development of more new protocol extensions.

Mobile users are, more than ever, consuming Internet content, and impose = new requirements on mobile core networks for data traffic delivery. When = this traffic demand exceeds available capacity, service providers need to = implement new strategies such as selective traffic offload (e.g. 3GPP work items LIPA/SIPTO) through alternative access networks (e.g. WLAN). Moreover, = the localization of content providers closer to the Mobile/Fixed Internet = Service Providers network requires taking into account local Content Delivery = Networks (CDNs) while providing mobility services. 

As long as demand exceeds capacity, both offloading and CDN techniques = could benefit from the development of more flat mobile architectures (i.e., fewer = levels of routing hierarchy introduced into the data path by the mobility = management system). This view is reinforced by the shift in users’ traffic behaviour, aimed at increasing direct communications among peers in the = same geographical area. The development of truly flat mobile architectures = would result in anchoring the traffic closer to point of attachment of the = user and overcoming the suboptimal routing issues of a centralized mobility = scheme.

While deploying today’s mobile networks, service providers face = new challenges. More often than not, mobile devices remain attached to the = same point of attachment, in which case specific IP mobility management = support is not required for applications that launch and complete while connected = to the same point of attachment. However, the mobility support has been = designed to be always on and to maintain the context for each mobile subscriber as long = as they are connected to the network. This can result in a waste of = resources and ever-increasing costs for the service provider. Infrequent mobility and intelligence of many applications suggest that mobility can be provided dynamically, thus simplifying the context maintained in the different = nodes of the mobile network.

The proposed charter will address two complementary aspects of mobility management procedures: the distribution of mobility anchors to achieve a = more flat design and the dynamic activation/deactivation of mobility protocol = support as an enabler to distributed mobility management. The former has the = goal of positioning mobility anchors (HA, LMA) closer to the user; ideally, = these mobility anchors could be collocated with the first hop router. The = latter, facilitated by the distribution of mobility anchors, aims at identifying = when mobility must be activated and identifying sessions that do not impose = mobility management -- thus reducing the amount of state information to be = maintained in the various mobility anchors of the mobile network. The key idea is that dynamic mobility management relaxes some constraints while also = repositioning mobility anchors; it avoids the establishment of non optimal tunnels = between two anchors topologically distant.

Considering the above, the working group will:

Define the problem statement and associated requirements for distributed mobility management. This work aims at defining the problem space and identifies the key functional requirements.

Produce a gap analysis mapping the above requirements against existing solutions.

Give best practices for the deployment of existing mobility protocols in = a distributed mobility management and describe limitations of each such = approach.

Describe extensions, if needed, to current mobility protocols for their application in distributed mobility architectures =


Comments?

Jari

------_=_NextPart_001_01CC9971.8EA9CC70-- From sarikaya2012@gmail.com Wed Nov 2 08:38:49 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 816EB11E8099 for ; Wed, 2 Nov 2011 08:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.429 X-Spam-Level: X-Spam-Status: No, score=-3.429 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 yYzeCQEzQoBA for ; Wed, 2 Nov 2011 08:38:48 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C5C4911E8090 for ; Wed, 2 Nov 2011 08:38:48 -0700 (PDT) Received: by gye5 with SMTP id 5so290117gye.31 for ; Wed, 02 Nov 2011 08:38:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/tE1WXxbaWmMLTbZerr69b5h39vY979SZDzWJFzJUq4=; b=QmzFkK4tSzBoWp70H4fnJaiI/1ueFwsyyU/CIjb63eiPKqKc35htYNhQpJJMHUOaLq Ua4n6KreyPmr5uYVy+MmPVVRAOhh6Q2KMfUNI1rM18OF0JhwJSiEXPFAFWP4ynSkpfw5 SqAX4SzlzTB5tJLPP28LZIq3eL0wrIBHZATNQ= MIME-Version: 1.0 Received: by 10.236.175.4 with SMTP id y4mr7169627yhl.128.1320248327690; Wed, 02 Nov 2011 08:38:47 -0700 (PDT) Received: by 10.236.108.135 with HTTP; Wed, 2 Nov 2011 08:38:47 -0700 (PDT) In-Reply-To: <08376A56-ACA7-4653-A4F8-EEDCE55B45F4@gmail.com> References: <08376A56-ACA7-4653-A4F8-EEDCE55B45F4@gmail.com> Date: Wed, 2 Nov 2011 10:38:47 -0500 Message-ID: From: Behcet Sarikaya To: jouni korhonen Content-Type: multipart/alternative; boundary=20cf305b0a56965b1704b0c244e3 Cc: Julien Laganier , mext Subject: Re: [MEXT] draft agenda uploaded X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 15:38:49 -0000 --20cf305b0a56965b1704b0c244e3 Content-Type: text/plain; charset=ISO-8859-1 Hi Jouni, Can you please add draft-sarikaya-mext-multicastdmm-04.txt to the agenda. Thanks. Behcet On Wed, Nov 2, 2011 at 4:09 AM, jouni korhonen wrote: > Folks, > > The draft agenda can be found here: > http://www.ietf.org/proceedings/82/agenda/mext.txt > > Note that we only have 1h slot, so squeezing I-D presentations into the > agenda was a bit challenging assuming we also want to have some meaningful > discussion on the charter and related concerns. So as a guideline for > presenters. Prepare one slide that states what is the *beef* of your > proposal and then have the discussion. Chairs will show the slide, so no > swapping of laptops etc. > > - Julien & Jouni > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > --20cf305b0a56965b1704b0c244e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Jouni,

Can you please add

draft-sarikaya-mext-multicastdmm= -04.txt

to the agenda.

Thanks.
<= br>Behcet

On Wed, Nov 2, 2011 at 4:09 AM,= jouni korhonen <jouni.nospam@gmail.com> wrote:
Folks,

The draft agenda can be found here:
=A0 =A0 =A0 =A0http://www.ietf.org/proceedings/82/agenda/mext.txt

Note that we only have 1h slot, so squeezing I-D presentations into the age= nda was a bit challenging assuming we also want to have some meaningful dis= cussion on the charter and related concerns. So as a guideline for presente= rs. Prepare one slide that states what is the *beef* of your proposal and t= hen have the discussion. Chairs will show the slide, so no swapping of lapt= ops etc.

- Julien & Jouni
_______________________________________________
MEXT mailing list
MEXT@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mext

--20cf305b0a56965b1704b0c244e3-- From rkuntz@us.toyota-itc.com Wed Nov 2 10:49:14 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E831F0C9A for ; Wed, 2 Nov 2011 10:49:14 -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=[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 UKC9sVhtTl6a for ; Wed, 2 Nov 2011 10:49:14 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with SMTP id D4A0F1F0C4B for ; Wed, 2 Nov 2011 10:49:13 -0700 (PDT) Received: from mail-qy0-f177.google.com ([209.85.216.177]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP; Wed, 02 Nov 2011 10:49:13 PDT Received: by mail-qy0-f177.google.com with SMTP id 10so483576qyk.8 for ; Wed, 02 Nov 2011 10:49:12 -0700 (PDT) Received: by 10.68.60.97 with SMTP id g1mr6020084pbr.108.1320256152317; Wed, 02 Nov 2011 10:49:12 -0700 (PDT) Received: from [192.168.18.154] (adsl-99-49-9-53.dsl.pltn13.sbcglobal.net. [99.49.9.53]) by mx.google.com with ESMTPS id y6sm6420490pbi.5.2011.11.02.10.49.11 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Nov 2011 10:49:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Romain KUNTZ In-Reply-To: <08376A56-ACA7-4653-A4F8-EEDCE55B45F4@gmail.com> Date: Wed, 2 Nov 2011 10:49:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <08376A56-ACA7-4653-A4F8-EEDCE55B45F4@gmail.com> To: mext X-Mailer: Apple Mail (2.1251.1) Cc: Julien Laganier , jouni korhonen Subject: Re: [MEXT] draft agenda uploaded X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 17:49:14 -0000 Dear all, For the people willing to get a summary of the issues, requirements and = existing proposals for DMM, we have published the following draft a = couple of months ago: http://tools.ietf.org/html/draft-kuntz-dmm-summary Regards, Romain On Nov 2, 2011, at 2:09, jouni korhonen wrote: > Folks, >=20 > The draft agenda can be found here: > http://www.ietf.org/proceedings/82/agenda/mext.txt >=20 > Note that we only have 1h slot, so squeezing I-D presentations into = the agenda was a bit challenging assuming we also want to have some = meaningful discussion on the charter and related concerns. So as a = guideline for presenters. Prepare one slide that states what is the = *beef* of your proposal and then have the discussion. Chairs will show = the slide, so no swapping of laptops etc. >=20 > - Julien & Jouni > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From jouni.nospam@gmail.com Thu Nov 3 03:35:44 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6141F0C3E for ; Thu, 3 Nov 2011 03:35:44 -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 4jQr6qNANBol for ; Thu, 3 Nov 2011 03:35:43 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 749E41F0C3C for ; Thu, 3 Nov 2011 03:35:43 -0700 (PDT) Received: by eyg24 with SMTP id 24so1043144eyg.31 for ; Thu, 03 Nov 2011 03:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=0DTwXtnN6RIDc8GwSrHaY/jH+HUaubvv5apTTgcVuLc=; b=cK3Gh/CZsvZqpM42S9jk/cQHgmbLYrWWQI5jNpKQtAgzsvM/O7QuEJiywLSQL/sijz /2epq6NSZHdbdsLmk7UUPwgSK7vX3XS4VVGiJ5vg1vHviOH8i2Xmo23+xjn7F5l5pabZ /TsYY2InbAWQwN48lHfRcRaG13dVVgmXgf8og= Received: by 10.213.17.137 with SMTP id s9mr975597eba.59.1320316542597; Thu, 03 Nov 2011 03:35:42 -0700 (PDT) Received: from ?IPv6:2001:67c:64:42:226:bbff:fe18:6e9c? ([2001:67c:64:42:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id f41sm14511720eec.5.2011.11.03.03.35.39 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Nov 2011 03:35:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 3 Nov 2011 12:35:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <47EA1D91-E53F-461C-9A08-325A0D9CD5DF@gmail.com> References: <08376A56-ACA7-4653-A4F8-EEDCE55B45F4@gmail.com> To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1084) Cc: Julien Laganier , mext Subject: Re: [MEXT] draft agenda uploaded X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 10:35:44 -0000 Behcet, We are pretty much sold out when it comes to agenda time :( If there is = anything left after the charter discussion part we can squeeze in = additional presentations. - Jouni & Julien On Nov 2, 2011, at 5:38 PM, Behcet Sarikaya wrote: > Hi Jouni, >=20 > Can you please add >=20 > draft-sarikaya-mext-multicastdmm-04.txt >=20 > to the agenda. >=20 > Thanks. >=20 > Behcet >=20 > On Wed, Nov 2, 2011 at 4:09 AM, jouni korhonen = wrote: > Folks, >=20 > The draft agenda can be found here: > http://www.ietf.org/proceedings/82/agenda/mext.txt >=20 > Note that we only have 1h slot, so squeezing I-D presentations into = the agenda was a bit challenging assuming we also want to have some = meaningful discussion on the charter and related concerns. So as a = guideline for presenters. Prepare one slide that states what is the = *beef* of your proposal and then have the discussion. Chairs will show = the slide, so no swapping of laptops etc. >=20 > - Julien & Jouni > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext >=20 From charles.perkins@earthlink.net Thu Nov 3 10:27:23 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8BE61F0C85 for ; Thu, 3 Nov 2011 10:27:23 -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 TKjotJ4IqSkC for ; Thu, 3 Nov 2011 10:27:23 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 4736B1F0C81 for ; Thu, 3 Nov 2011 10:27:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=oOspxsFulzc0u5ibGjjWLOmdmGHgFHHhWe7i4ZqWFQzWpAzml/gd9Hca1ZJs7qQq; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [138.111.58.2] (helo=[172.17.96.136]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1RM14S-0003o0-0F; Thu, 03 Nov 2011 12:27:20 -0500 Message-ID: <4EB2CEF0.80705@earthlink.net> Date: Thu, 03 Nov 2011 10:27:12 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: jouni korhonen References: <08376A56-ACA7-4653-A4F8-EEDCE55B45F4@gmail.com> <47EA1D91-E53F-461C-9A08-325A0D9CD5DF@gmail.com> In-Reply-To: <47EA1D91-E53F-461C-9A08-325A0D9CD5DF@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad865334f001f9d05fc93761e83bcfc71bd8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Cc: Julien Laganier , mext Subject: Re: [MEXT] draft agenda uploaded X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 17:27:24 -0000 Hello folks, It should have been obvious that such a sea change in [mext] as is proposed would take a lot of discussion, and so we ought to have had more time for discussion of existing drafts. The single short timeslot has the effect of limiting discussion. This is especially unwelcome given that we didn't even have a timeslot scheduled at the last IETF. If there is time, I would like a few minutes to discuss the comparison matrix draft for DMM, draft-perkins-dmm-matrix-02 and the draft which enables the home agent to supply a data-plane home agent address to the mobile node, draft-perkins-mext-hatunaddr-02 Regards, Charlie P. On 11/3/2011 3:35 AM, jouni korhonen wrote: > > Behcet, > > We are pretty much sold out when it comes to agenda time :( If there is anything left after the charter discussion part we can squeeze in additional presentations. > > - Jouni& Julien > > > On Nov 2, 2011, at 5:38 PM, Behcet Sarikaya wrote: > >> Hi Jouni, >> >> Can you please add >> >> draft-sarikaya-mext-multicastdmm-04.txt >> >> to the agenda. >> >> Thanks. >> >> Behcet >> >> On Wed, Nov 2, 2011 at 4:09 AM, jouni korhonen wrote: >> Folks, >> >> The draft agenda can be found here: >> http://www.ietf.org/proceedings/82/agenda/mext.txt >> >> Note that we only have 1h slot, so squeezing I-D presentations into the agenda was a bit challenging assuming we also want to have some meaningful discussion on the charter and related concerns. So as a guideline for presenters. Prepare one slide that states what is the *beef* of your proposal and then have the discussion. Chairs will show the slide, so no swapping of laptops etc. >> >> - Julien& Jouni >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From charles.perkins@earthlink.net Thu Nov 3 10:49:32 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25441F0C76 for ; Thu, 3 Nov 2011 10:49:32 -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 r995E+TYAcUJ for ; Thu, 3 Nov 2011 10:49:32 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 027B21F0C40 for ; Thu, 3 Nov 2011 10:49:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=dlzif6kPJyz00BkNWvDz3/rvtQ/Ow1gzAVNK2mzyLQLiTodEBRmy/VnYQtv+6TrK; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [138.111.58.2] (helo=[172.17.96.136]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1RM1Pr-00007L-Qa; Thu, 03 Nov 2011 13:49:28 -0400 Message-ID: <4EB2D421.4030905@earthlink.net> Date: Thu, 03 Nov 2011 10:49:21 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Jari Arkko References: <4EAA9B4A.3020208@piuha.net> In-Reply-To: <4EAA9B4A.3020208@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86cccb02f4a65ae22eec64eb2da3c95900350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Cc: jouni.korhonen@nsn.com, mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 17:49:33 -0000 Hello folks, For several years now, I have been studying 4G wireless network architecture and wondering why there is such a disconnect between, say, LTE mobility management and IETF mobility management. Mobile IP has a secondary role, to say the least. IETF approaches may be seen to have several inadequacies, and 3GPP approaches also show some major problems. I think that it is important for the IETF to devote some serious effort towards bringing these two worlds together, because current directions are leading towards an impossibly baroque, wasteful, nearly impenetrable mess of complication. The effects overall is loss of performance and opportunity. Taking a look at S101 and S103, we can immediately recognize that they are drastically more complicated, restrictive, and operationally more expensive than Mobile IP. Taking a look at S102, we immediately see that 3GPP mobility management threatens to be different for each class of application, with an unnecessary per-application proliferation of servers, protocol, permissions, traffic controls, configuration, and so on. Taking a look at recent efforts towards WiFi offload, we see the same trend of complication and software hacks that could be avoided with proper IETF approaches. On the IETF side, we should specify: - Integrated authentication for access control as well as IP address continuity - Location-assisted handovers (think MIIS / ANDSF) - Modular/alternative security - Signaling on control plane, user traffic on data plane - Alternative tunneling (GTP is simply not going to die a quick death, to say the least) - geez, the list does go on, but no one reads long lists ... ... I don't know if we already have 3GPP liaison, but if we do the communication channels don't seem to have had very much effect within the [mext] work lately. My fear is that if we don't take action, we are choosing a future that is ever more complicated, non-extendible, non-flexible, radio technology specific, application specific, and bug-ridden. In short, everything we don't want the Internet to be. And, I am sure no one here doubts that the Internet of the future is all high-speed wireless. Where is the IETF going to be? If the [mext] working group is shut down, there is no natural place for this work to happen. Therefore, I hope that [mext] would NOT shut down, and instead recharter to tackle these urgent problems. Regards, Charlie P. On 10/28/2011 5:08 AM, Jari Arkko wrote: > All, > > We are making some changes to the working group. While we have > successfully published a large number of specifications in recent years, > recently it has been difficult to make progress in the group. The chairs > and ADs have looked at the situation and we believe we need a new focus > and a bit of new organization as well. We are terminating the working > group and moving the one remaining active work item to a new working > group, the "DMM" working group. Here's what is going to happen: > > o Jouni Korhonen and Julien Laganier will become the chairs of the group. > > o The group will meet in Taipei (there is a MEXT slot in the agenda). > > o The charter of the group will be changed to focus only on the > distributed mobility effort. We should discuss the details of this > charter change both on the list and in the meeting. The meeting agenda > should reserve some time both for technical discussions as well as the > charter discussion. > > o Once the discussion on the list and in the meeting has finished, we > will rename the group to "DMM" and put the new charter in effect. > > o If there are any other specifications that people would like to > publish beyond the distributed mobility work, we can offer to AD sponsor > them to RFCs outside the new working group. If there is some significant > new activity, we can create new working groups for that. > > Comments and feedback and/or alternate suggestions on this plan are > welcome. > > We would like to thank Marcelo for your many years of service in MEXT. > We could not have completed all the work we did without your energy and > push for high quality results. We would also like to thank Jouni for > taking on this new challenge, and Julien for continuing the work in this > space. > > Jari and Ralph > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From thierry.ernst@inria.fr Thu Nov 3 13:28:47 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2F411E8137 for ; Thu, 3 Nov 2011 13:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[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 b1XxTZRl0zzP for ; Thu, 3 Nov 2011 13:28:46 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id CF7B711E8114 for ; Thu, 3 Nov 2011 13:28:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.69,452,1315173600"; d="vcf'?scan'208";a="128209453" Received: from 10.244.112.78.rev.sfr.net (HELO [192.168.1.3]) ([78.112.244.10]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 03 Nov 2011 21:28:43 +0100 Message-ID: <4EB2F97A.8000002@inria.fr> Date: Thu, 03 Nov 2011 21:28:42 +0100 From: Thierry Ernst Organization: INRIA User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: mext@ietf.org References: <4EAA9B4A.3020208@piuha.net> <4EB2D421.4030905@earthlink.net> In-Reply-To: <4EB2D421.4030905@earthlink.net> Content-Type: multipart/mixed; boundary="------------030504070201050401050503" Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 20:28:47 -0000 This is a multi-part message in MIME format. --------------030504070201050401050503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'm supporting what Charlie wrote, and share the same concerns. Regards, Thierry. On 03/11/11 18:49, Charles E. Perkins wrote: > Hello folks, > > For several years now, I have been studying 4G wireless > network architecture and wondering why there is such a > disconnect between, say, LTE mobility management and > IETF mobility management. Mobile IP has a secondary > role, to say the least. IETF approaches may be seen to > have several inadequacies, and 3GPP approaches also show > some major problems. I think that it is important for > the IETF to devote some serious effort towards bringing > these two worlds together, because current directions > are leading towards an impossibly baroque, wasteful, > nearly impenetrable mess of complication. The effects > overall is loss of performance and opportunity. > > Taking a look at S101 and S103, we can immediately > recognize that they are drastically more complicated, > restrictive, and operationally more expensive than > Mobile IP. Taking a look at S102, we immediately see > that 3GPP mobility management threatens to be different > for each class of application, with an unnecessary > per-application proliferation of servers, protocol, > permissions, traffic controls, configuration, and so on. > Taking a look at recent efforts towards WiFi offload, > we see the same trend of complication and software > hacks that could be avoided with proper IETF > approaches. > > On the IETF side, we should specify: > - Integrated authentication for access control > as well as IP address continuity > - Location-assisted handovers (think MIIS / ANDSF) > - Modular/alternative security > - Signaling on control plane, user traffic on > data plane > - Alternative tunneling (GTP is simply not going > to die a quick death, to say the least) > - geez, the list does go on, but no one reads > long lists ... > ... > > I don't know if we already have 3GPP liaison, but > if we do the communication channels don't seem to > have had very much effect within the [mext] work > lately. > > My fear is that if we don't take action, we are > choosing a future that is ever more complicated, > non-extendible, non-flexible, radio technology > specific, application specific, and bug-ridden. > In short, everything we don't want the Internet > to be. And, I am sure no one here doubts that > the Internet of the future is all high-speed > wireless. Where is the IETF going to be? > > If the [mext] working group is shut down, there > is no natural place for this work to happen. > Therefore, I hope that [mext] would NOT shut > down, and instead recharter to tackle these > urgent problems. > > Regards, > Charlie P. > > > > On 10/28/2011 5:08 AM, Jari Arkko wrote: >> All, >> >> We are making some changes to the working group. While we have >> successfully published a large number of specifications in recent years, >> recently it has been difficult to make progress in the group. The chairs >> and ADs have looked at the situation and we believe we need a new focus >> and a bit of new organization as well. We are terminating the working >> group and moving the one remaining active work item to a new working >> group, the "DMM" working group. Here's what is going to happen: >> >> o Jouni Korhonen and Julien Laganier will become the chairs of the >> group. >> >> o The group will meet in Taipei (there is a MEXT slot in the agenda). >> >> o The charter of the group will be changed to focus only on the >> distributed mobility effort. We should discuss the details of this >> charter change both on the list and in the meeting. The meeting agenda >> should reserve some time both for technical discussions as well as the >> charter discussion. >> >> o Once the discussion on the list and in the meeting has finished, we >> will rename the group to "DMM" and put the new charter in effect. >> >> o If there are any other specifications that people would like to >> publish beyond the distributed mobility work, we can offer to AD sponsor >> them to RFCs outside the new working group. If there is some significant >> new activity, we can create new working groups for that. >> >> Comments and feedback and/or alternate suggestions on this plan are >> welcome. >> >> We would like to thank Marcelo for your many years of service in MEXT. >> We could not have completed all the work we did without your energy and >> push for high quality results. We would also like to thank Jouni for >> taking on this new challenge, and Julien for continuing the work in this >> space. >> >> Jari and Ralph >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext --------------030504070201050401050503 Content-Type: text/x-vcard; charset=utf-8; name="thierry_ernst.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="thierry_ernst.vcf" begin:vcard fn:Thierry Ernst n:Ernst;Thierry org:INRIA - Project Team IMARA - LaRA JRU tel;work:+33 1 3963 59 30 tel;fax:+33 1 39 63 54 91 tel;cell:+33 6 76 56 25 96 url:http://www.lara.prd.fr version:2.1 end:vcard --------------030504070201050401050503-- From jouni.nospam@gmail.com Thu Nov 3 14:02:50 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5CAC1F0C6F for ; Thu, 3 Nov 2011 14:02:50 -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 mPq92Pk0zV4U for ; Thu, 3 Nov 2011 14:02:49 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8F31F0C35 for ; Thu, 3 Nov 2011 14:02:49 -0700 (PDT) Received: by faas12 with SMTP id s12so2378024faa.31 for ; Thu, 03 Nov 2011 14:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=FVNh4L/y94VJAxnnI0LdgYYPGSQMwGkzDbakeD9pUxM=; b=pllQzkRqmrBhS32Gqqfz4PJWQ+9bcWM/ZqW2PF1c2y6yjEWy8LCsSBMjCG161bA8US mSfnUukYYSgCA7x4rIn+iLgyqt7xahx7uMPjeGl5rfkJilCADrqAToc1kHfrma7YEIKq fJwCBZ7zTxas5umWzu1PRulkFoswYNrRAPlgo= Received: by 10.223.39.20 with SMTP id d20mr18703711fae.37.1320354168476; Thu, 03 Nov 2011 14:02:48 -0700 (PDT) Received: from [10.0.7.154] (dsl-64-34.utaonline.at. [81.189.64.34]) by mx.google.com with ESMTPS id d21sm14008903fac.4.2011.11.03.14.02.45 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Nov 2011 14:02:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4EB2D421.4030905@earthlink.net> Date: Thu, 3 Nov 2011 23:02:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2326342E-97CA-4BD3-B704-F610FCB04C87@gmail.com> References: <4EAA9B4A.3020208@piuha.net> <4EB2D421.4030905@earthlink.net> To: Charles E. Perkins X-Mailer: Apple Mail (2.1084) Cc: jouni.korhonen@nsn.com, Jari Arkko , mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 21:02:50 -0000 Charlie, It was 2005, a warm May week in Athens when SA2, RAN2 and RAN3 had a = meeting., and EPS took its first steps.. This, for example, was on a = table: = http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_46_Athens/Docs/S2-051260.zip= That did/does not too bad actually. I still remember some operator folk = standing up back then and giving a loud comment "This science fiction.." = ;-) - Jouni On Nov 3, 2011, at 7:49 PM, Charles E. Perkins wrote: > Hello folks, >=20 > For several years now, I have been studying 4G wireless > network architecture and wondering why there is such a > disconnect between, say, LTE mobility management and > IETF mobility management. Mobile IP has a secondary > role, to say the least. IETF approaches may be seen to > have several inadequacies, and 3GPP approaches also show > some major problems. I think that it is important for > the IETF to devote some serious effort towards bringing > these two worlds together, because current directions > are leading towards an impossibly baroque, wasteful, > nearly impenetrable mess of complication. The effects > overall is loss of performance and opportunity. >=20 > Taking a look at S101 and S103, we can immediately > recognize that they are drastically more complicated, > restrictive, and operationally more expensive than > Mobile IP. Taking a look at S102, we immediately see > that 3GPP mobility management threatens to be different > for each class of application, with an unnecessary > per-application proliferation of servers, protocol, > permissions, traffic controls, configuration, and so on. > Taking a look at recent efforts towards WiFi offload, > we see the same trend of complication and software > hacks that could be avoided with proper IETF > approaches. >=20 > On the IETF side, we should specify: > - Integrated authentication for access control > as well as IP address continuity > - Location-assisted handovers (think MIIS / ANDSF) > - Modular/alternative security > - Signaling on control plane, user traffic on > data plane > - Alternative tunneling (GTP is simply not going > to die a quick death, to say the least) > - geez, the list does go on, but no one reads > long lists ... > ... >=20 > I don't know if we already have 3GPP liaison, but > if we do the communication channels don't seem to > have had very much effect within the [mext] work > lately. >=20 > My fear is that if we don't take action, we are > choosing a future that is ever more complicated, > non-extendible, non-flexible, radio technology > specific, application specific, and bug-ridden. > In short, everything we don't want the Internet > to be. And, I am sure no one here doubts that > the Internet of the future is all high-speed > wireless. Where is the IETF going to be? >=20 > If the [mext] working group is shut down, there > is no natural place for this work to happen. > Therefore, I hope that [mext] would NOT shut > down, and instead recharter to tackle these > urgent problems. >=20 > Regards, > Charlie P. >=20 >=20 >=20 > On 10/28/2011 5:08 AM, Jari Arkko wrote: >> All, >>=20 >> We are making some changes to the working group. While we have >> successfully published a large number of specifications in recent = years, >> recently it has been difficult to make progress in the group. The = chairs >> and ADs have looked at the situation and we believe we need a new = focus >> and a bit of new organization as well. We are terminating the working >> group and moving the one remaining active work item to a new working >> group, the "DMM" working group. Here's what is going to happen: >>=20 >> o Jouni Korhonen and Julien Laganier will become the chairs of the = group. >>=20 >> o The group will meet in Taipei (there is a MEXT slot in the agenda). >>=20 >> o The charter of the group will be changed to focus only on the >> distributed mobility effort. We should discuss the details of this >> charter change both on the list and in the meeting. The meeting = agenda >> should reserve some time both for technical discussions as well as = the >> charter discussion. >>=20 >> o Once the discussion on the list and in the meeting has finished, we >> will rename the group to "DMM" and put the new charter in effect. >>=20 >> o If there are any other specifications that people would like to >> publish beyond the distributed mobility work, we can offer to AD = sponsor >> them to RFCs outside the new working group. If there is some = significant >> new activity, we can create new working groups for that. >>=20 >> Comments and feedback and/or alternate suggestions on this plan are >> welcome. >>=20 >> We would like to thank Marcelo for your many years of service in = MEXT. >> We could not have completed all the work we did without your energy = and >> push for high quality results. We would also like to thank Jouni for >> taking on this new challenge, and Julien for continuing the work in = this >> space. >>=20 >> Jari and Ralph >>=20 >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >>=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From charles.perkins@earthlink.net Thu Nov 3 15:29:39 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A558911E80BD for ; Thu, 3 Nov 2011 15:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.952 X-Spam-Level: X-Spam-Status: No, score=-0.952 tagged_above=-999 required=5 tests=[AWL=-1.647, BAYES_00=-2.599, FB_WORD2_END_DOLLAR=3.294] 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 ZgIXsgZfiNOG for ; Thu, 3 Nov 2011 15:29:38 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 81D1B11E80C2 for ; Thu, 3 Nov 2011 15:29:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=tWI2O2xG5nkNDrjt5AIv8gpIVZ7bIpczLhImUoNYfBX26R9UHGfHi2PcM9CP9D/+; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [138.111.58.2] (helo=[172.17.96.136]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1RM5mx-00044j-Dq; Thu, 03 Nov 2011 18:29:35 -0400 Message-ID: <4EB315CA.70300@earthlink.net> Date: Thu, 03 Nov 2011 15:29:30 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: jouni korhonen References: <4EAA9B4A.3020208@piuha.net> <4EB2D421.4030905@earthlink.net> <2326342E-97CA-4BD3-B704-F610FCB04C87@gmail.com> In-Reply-To: <2326342E-97CA-4BD3-B704-F610FCB04C87@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8685bf80a9a271e3ab02b3df5df8ddffe0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Cc: mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 22:29:39 -0000 Hello Jouni, I think S2-051260 is an outstanding design document that everyone in [mext] should read. From it, we "SHOULD" have seen a much better designed system. The result, however, would not be recognizable from figure 1 and figure 2 except by a quite optimistic LTE expert. I started to think about how to quantify the huge jump in complexity between the stated design goals in the document and the result of S1 --> S$\infty$ but my head started to hurt... never mind Ga --> Gz and the 200 IEs for GTP, and all the other modules. Is it possible to have some discussion on my proposal [i.e., "On the IETF side, we should specify: ..."] at IETF 82? I realize it is quite broad and would probably engender a lot of discussion, but it's a discussion that needs to happen. Regards, Charlie P. On 11/3/2011 2:02 PM, jouni korhonen wrote: > Charlie, > > It was 2005, a warm May week in Athens when SA2, RAN2 and RAN3 had a meeting., and EPS took its first steps.. This, for example, was on a table: http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_46_Athens/Docs/S2-051260.zip > That did/does not too bad actually. I still remember some operator folk standing up back then and giving a loud comment "This science fiction.." ;-) > > - Jouni > > On Nov 3, 2011, at 7:49 PM, Charles E. Perkins wrote: > >> Hello folks, >> >> For several years now, I have been studying 4G wireless >> network architecture and wondering why there is such a >> disconnect between, say, LTE mobility management and >> IETF mobility management. Mobile IP has a secondary >> role, to say the least. IETF approaches may be seen to >> have several inadequacies, and 3GPP approaches also show >> some major problems. I think that it is important for >> the IETF to devote some serious effort towards bringing >> these two worlds together, because current directions >> are leading towards an impossibly baroque, wasteful, >> nearly impenetrable mess of complication. The effects >> overall is loss of performance and opportunity. >> >> Taking a look at S101 and S103, we can immediately >> recognize that they are drastically more complicated, >> restrictive, and operationally more expensive than >> Mobile IP. Taking a look at S102, we immediately see >> that 3GPP mobility management threatens to be different >> for each class of application, with an unnecessary >> per-application proliferation of servers, protocol, >> permissions, traffic controls, configuration, and so on. >> Taking a look at recent efforts towards WiFi offload, >> we see the same trend of complication and software >> hacks that could be avoided with proper IETF >> approaches. >> >> On the IETF side, we should specify: >> - Integrated authentication for access control >> as well as IP address continuity >> - Location-assisted handovers (think MIIS / ANDSF) >> - Modular/alternative security >> - Signaling on control plane, user traffic on >> data plane >> - Alternative tunneling (GTP is simply not going >> to die a quick death, to say the least) >> - geez, the list does go on, but no one reads >> long lists ... >> ... >> >> I don't know if we already have 3GPP liaison, but >> if we do the communication channels don't seem to >> have had very much effect within the [mext] work >> lately. >> >> My fear is that if we don't take action, we are >> choosing a future that is ever more complicated, >> non-extendible, non-flexible, radio technology >> specific, application specific, and bug-ridden. >> In short, everything we don't want the Internet >> to be. And, I am sure no one here doubts that >> the Internet of the future is all high-speed >> wireless. Where is the IETF going to be? >> >> If the [mext] working group is shut down, there >> is no natural place for this work to happen. >> Therefore, I hope that [mext] would NOT shut >> down, and instead recharter to tackle these >> urgent problems. >> >> Regards, >> Charlie P. >> >> >> >> On 10/28/2011 5:08 AM, Jari Arkko wrote: >>> All, >>> >>> We are making some changes to the working group. While we have >>> successfully published a large number of specifications in recent years, >>> recently it has been difficult to make progress in the group. The chairs >>> and ADs have looked at the situation and we believe we need a new focus >>> and a bit of new organization as well. We are terminating the working >>> group and moving the one remaining active work item to a new working >>> group, the "DMM" working group. Here's what is going to happen: >>> >>> o Jouni Korhonen and Julien Laganier will become the chairs of the group. >>> >>> o The group will meet in Taipei (there is a MEXT slot in the agenda). >>> >>> o The charter of the group will be changed to focus only on the >>> distributed mobility effort. We should discuss the details of this >>> charter change both on the list and in the meeting. The meeting agenda >>> should reserve some time both for technical discussions as well as the >>> charter discussion. >>> >>> o Once the discussion on the list and in the meeting has finished, we >>> will rename the group to "DMM" and put the new charter in effect. >>> >>> o If there are any other specifications that people would like to >>> publish beyond the distributed mobility work, we can offer to AD sponsor >>> them to RFCs outside the new working group. If there is some significant >>> new activity, we can create new working groups for that. >>> >>> Comments and feedback and/or alternate suggestions on this plan are >>> welcome. >>> >>> We would like to thank Marcelo for your many years of service in MEXT. >>> We could not have completed all the work we did without your energy and >>> push for high quality results. We would also like to thank Jouni for >>> taking on this new challenge, and Julien for continuing the work in this >>> space. >>> >>> Jari and Ralph >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > From Basavaraj.Patil@nokia.com Thu Nov 3 15:54:00 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE7E1F0C59 for ; Thu, 3 Nov 2011 15:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, 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 TetxLO1o8EWm for ; Thu, 3 Nov 2011 15:54:00 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id D99BC1F0C3D for ; Thu, 3 Nov 2011 15:53:59 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pA3MrvbO020476; Fri, 4 Nov 2011 00:53:57 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Nov 2011 00:53:52 +0200 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 3 Nov 2011 23:53:52 +0100 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.235]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0339.002; Thu, 3 Nov 2011 23:53:39 +0100 From: To: Thread-Topic: [MEXT] the future of the MEXT working group Thread-Index: AQHMlWpmfRWG/cEPIEyACm1+ri2dNZWRi8gAgAovg4A= Date: Thu, 3 Nov 2011 22:53:38 +0000 Message-ID: References: <4EAA9B4A.3020208@piuha.net> <4EAA9E34.2080903@piuha.net> In-Reply-To: <4EAA9E34.2080903@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.59.28] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Nov 2011 22:53:52.0862 (UTC) FILETIME=[756CC7E0:01CC9A7B] X-Nokia-AV: Clean Cc: mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 22:54:01 -0000 Hi Jari, Comments inline: On Oct 28, 2011, at 7:21 AM, ext Jari Arkko wrote: > And a follow-up on the charter. I'm describing a couple of different take= s on what the new charter could be. Comments and alternative proposals are = welcome. This is what the current charter says about DMM: >=20 >> The working group will also work on operational considerations on >> setting up Mobile IPv6 networks so that traffic is distributed >> in an optimal way, for instance by using existing protocol mechanisms >> to select the closest home agents for new clients. >>=20 >> Oct 2011 - Submit I-D 'Operational considerations for distributed use = of Mobile IPv6' for publication as Informational. >=20 > Which is admittedly a bit short, but is also very concrete and achievable= , if we work on it. I got another proposal from Hui Deng that extended this= a bit, including going beyond mere operational considerations. >=20 >> In the past decade a fair number of mobility protocols have been standar= dized. Although the protocols differ in terms of functions and associated m= essage format, we can identify a few key common features: >> presence of a centralized mobility anchor providing global reachability = and an always-on experience >> extensions to optimize handover performance while users roam across wire= less cells >> extensions to enable the use of heterogeneous wireless interfaces for mu= lti-mode terminals (e.g. cellular phones) What does "extensions to enable the use of heterogeneous wireless interface= s for multi-mode terminals (e.g. cellular phones" this imply? The term alwa= ys-on does not necessarily apply as well. If an MN is registered with an HA= it is reachable but always-on would require the MN to be network-attached = and registered with an HA which may not always be the case. >> The presence of the centralized mobility anchor allows a mobile device t= o be reachable when it is not connected to its home domain. What is a home domain for a user/MN?=20 >> The anchor, among other tasks, ensures forwarding of packets destined to= or sent from the mobile device. As such, most of the deployed architecture= s today have a small number of centralized anchors managing the traffic of = millions of mobile subscribers. >>=20 >> To optimize handovers for mobile users, the base protocols have been ext= ended to efficiently handle packet forwarding between the previous and new = points of attachment. These extensions are necessary when applications impo= se stringent requirements in terms of delay. Notions of localization and di= stribution of local agents have been introduced to reduce signalling overhe= ad. Unfortunately today we witness difficulties in getting such protocols d= eployed, often leading to sub-optimal choices. Moreover, all the availabili= ty of multi-mode devices and the possibility to use several network interfa= ces simultaneously have motivated the development of more new protocol exte= nsions. The comment about deployment of the Mobile IP protocols is irrelevant in th= is context.=20 >>=20 >> Mobile users are, more than ever, consuming Internet content, and impose= new requirements on mobile core networks for data traffic delivery. When t= his traffic demand exceeds available capacity, service providers need to im= plement new strategies such as selective traffic offload (e.g. 3GPP work it= ems LIPA/SIPTO) through alternative access networks (e.g. WLAN). Moreover, = the localization of content providers closer to the Mobile/Fixed Internet S= ervice Providers network requires taking into account local Content Deliver= y Networks (CDNs) while providing mobility services. =20 Offloading to wifi or the fact that CDNs are used for content delivery are = really not a motivator for DMM. >>=20 >> As long as demand exceeds capacity, both offloading and CDN techniques c= ould benefit from the development of more flat mobile architectures (i.e., = fewer levels of routing hierarchy introduced into the data path by the mobi= lity management system). Would you consider a P-GW/GGSN as introducing multiple levels of routing hi= erarchy? In Internet architecture terms the P-GW/GGSN is the NAS/Gateway ro= uter.=20 >> This view is reinforced by the shift in users=92 traffic behaviour, aime= d at increasing direct communications among peers in the same geographical = area. This is highly speculative. What study shows that users traffic behavior di= splays such characteristics? >> The development of truly flat mobile architectures would result in ancho= ring the traffic closer to point of attachment of the user and overcoming t= he suboptimal routing issues of a centralized mobility scheme. What is a truly flat mobile architecture? >>=20 >> While deploying today=92s mobile networks, service providers face new ch= allenges. More often than not, mobile devices remain attached to the same p= oint of attachment, in which case specific IP mobility management support i= s not required for applications that launch and complete while connected to= the same point of attachment. However, the mobility support has been desig= ned to be always on and to maintain the context for each mobile subscriber = as long as they are connected to the network. This can result in a waste of= resources and ever-increasing costs for the service provider. Infrequent m= obility and intelligence of many applications suggest that mobility can be = provided dynamically, thus simplifying the context maintained in the differ= ent nodes of the mobile network. >>=20 >> The proposed charter will address two complementary aspects of mobility = management procedures: the distribution of mobility anchors to achieve a mo= re flat design and the dynamic activation/deactivation of mobility protocol= support as an enabler to distributed mobility management. The former has t= he goal of positioning mobility anchors (HA, LMA) closer to the user; ideal= ly, these mobility anchors could be collocated with the first hop router. T= he latter, facilitated by the distribution of mobility anchors, aims at ide= ntifying when mobility must be activated and identifying sessions that do n= ot impose mobility management -- thus reducing the amount of state informat= ion to be maintained in the various mobility anchors of the mobile network.= The key idea is that dynamic mobility management relaxes some constraints = while also repositioning mobility anchors; it avoids the establishment of n= on optimal tunnels between two anchors topologically distant.=20 >>=20 >> Considering the above, the working group will: >>=20 >> Define the problem statement and associated requirements for distributed= mobility management. This work aims at defining the problem space and iden= tifies the key functional requirements. >>=20 >> Produce a gap analysis mapping the above requirements against existing s= olutions. Gap analysis is an academic exercise and not worth the effort of a WG. >>=20 >> Give best practices for the deployment of existing mobility protocols in= a distributed mobility management and describe limitations of each such ap= proach. I think this is the most sane proposal in terms of how existing protocols c= an be deployed to address concerns that have been highlighted in various I-= Ds. >>=20 >> Describe extensions, if needed, to current mobility protocols for their = application in distributed mobility architectures Yes. As needed. -Basavaraj >=20 > Comments? >=20 > Jari >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From jouni.nospam@gmail.com Thu Nov 3 17:22:05 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976911F0C59 for ; Thu, 3 Nov 2011 17:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 v5TOohUIyMJO for ; Thu, 3 Nov 2011 17:22:04 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3481F0C3D for ; Thu, 3 Nov 2011 17:22:04 -0700 (PDT) Received: by faas12 with SMTP id s12so2526586faa.31 for ; Thu, 03 Nov 2011 17:22:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=r2ps2d6hS570rKqLVhH3NxhbaFlu+c0ifCoLP+diiHk=; b=Y97GnW4pYiyP1vuYWmLhu1uQKvItW3M50fIKOK+9e5/UNQVatbb+Hoe8Y5KSdDP0IV dXhktQBNzIiJiq5b1yW1/CVcSlWdab2fglaeJhJ0Avn/+I4dciu4xct8k6tf2sGUBSxm sT7tShml5idItujVm0CEMY+eriWg1Hnrp41e0= Received: by 10.223.17.3 with SMTP id q3mr19937410faa.28.1320366123292; Thu, 03 Nov 2011 17:22:03 -0700 (PDT) Received: from [10.0.7.154] (dsl-64-34.utaonline.at. [81.189.64.34]) by mx.google.com with ESMTPS id l26sm14581168fad.17.2011.11.03.17.21.58 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Nov 2011 17:22:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: jouni korhonen In-Reply-To: <4EAA9E34.2080903@piuha.net> Date: Fri, 4 Nov 2011 02:21:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1B31D76B-4C76-4351-B270-437D4560007C@gmail.com> References: <4EAA9B4A.3020208@piuha.net> <4EAA9E34.2080903@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1084) Cc: "mext@ietf.org" Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 00:22:05 -0000 Hi, Few quick comments. I would remove all explicit references to 3GPP and = existing offload mechanisms therein. FWIW this WG is not supposed to be = a stub of SA2. The possible (protocol) enhancement must be generic = enough to be applicable outside of a specific deployment architecture. Also, I think we ought not only consider just mobility enhancement. More = efficient use of CoA(s) for direct/local/non-tunneled communication = along with existing mobility solutions should be in scope as well.=20 - Jouni On Oct 28, 2011, at 3:21 PM, Jari Arkko wrote: > And a follow-up on the charter. I'm describing a couple of different = takes on what the new charter could be. Comments and alternative = proposals are welcome. This is what the current charter says about DMM: >=20 >> The working group will also work on operational considerations on >> setting up Mobile IPv6 networks so that traffic is distributed >> in an optimal way, for instance by using existing protocol = mechanisms >> to select the closest home agents for new clients. >>=20 >> Oct 2011 - Submit I-D 'Operational considerations for distributed = use of Mobile IPv6' for publication as Informational. >=20 > Which is admittedly a bit short, but is also very concrete and = achievable, if we work on it. I got another proposal from Hui Deng that = extended this a bit, including going beyond mere operational = considerations. >=20 >> In the past decade a fair number of mobility protocols have been = standardized. Although the protocols differ in terms of functions and = associated message format, we can identify a few key common features: >> presence of a centralized mobility anchor providing global = reachability and an always-on experience >> extensions to optimize handover performance while users roam across = wireless cells >> extensions to enable the use of heterogeneous wireless interfaces for = multi-mode terminals (e.g. cellular phones) >> The presence of the centralized mobility anchor allows a mobile = device to be reachable when it is not connected to its home domain. The = anchor, among other tasks, ensures forwarding of packets destined to or = sent from the mobile device. As such, most of the deployed architectures = today have a small number of centralized anchors managing the traffic of = millions of mobile subscribers. >>=20 >> To optimize handovers for mobile users, 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 impose stringent requirements in terms of delay. Notions of = localization and distribution of local agents have been introduced to = reduce signalling overhead. Unfortunately today we witness difficulties = in getting such protocols deployed, often leading to sub-optimal = choices. Moreover, all the availability of multi-mode devices and the = possibility to use several network interfaces simultaneously have = motivated the development of more new protocol extensions. >>=20 >> Mobile users are, more than ever, consuming Internet content, and = impose new requirements on mobile core networks for data traffic = delivery. When this traffic demand exceeds available capacity, service = providers need to implement new strategies such as selective traffic = offload (e.g. 3GPP work items LIPA/SIPTO) through alternative access = networks (e.g. WLAN). Moreover, the localization of content providers = closer to the Mobile/Fixed Internet Service Providers network requires = taking into account local Content Delivery Networks (CDNs) while = providing mobility services. =20 >>=20 >> As long as demand exceeds capacity, both offloading and CDN = techniques could benefit from the development of more flat mobile = architectures (i.e., fewer levels of routing hierarchy introduced into = the data path by the mobility management system). This view is = reinforced by the shift in users=92 traffic behaviour, aimed at = increasing direct communications among peers in the same geographical = area. The development of truly flat mobile architectures would result in = anchoring the traffic closer to point of attachment of the user and = overcoming the suboptimal routing issues of a centralized mobility = scheme. >>=20 >> While deploying today=92s mobile networks, service providers face new = challenges. More often than not, mobile devices remain attached to the = same point of attachment, in which case specific IP mobility management = support is not required for applications that launch and complete while = connected to the same point of attachment. However, the mobility support = has been designed to be always on and to maintain the context for each = mobile subscriber as long as they are connected to the network. This can = result in a waste of resources and ever-increasing costs for the service = provider. Infrequent mobility and intelligence of many applications = suggest that mobility can be provided dynamically, thus simplifying the = context maintained in the different nodes of the mobile network. >>=20 >> The proposed charter will address two complementary aspects of = mobility management procedures: the distribution of mobility anchors to = achieve a more flat design and the dynamic activation/deactivation of = mobility protocol support as an enabler to distributed mobility = management. The former has the goal of positioning mobility anchors (HA, = LMA) closer to the user; ideally, these mobility anchors could be = collocated with the first hop router. The latter, facilitated by the = distribution of mobility anchors, aims at identifying when mobility must = be activated and identifying sessions that do not impose mobility = management -- thus reducing the amount of state information to be = maintained in the various mobility anchors of the mobile network. The = key idea is that dynamic mobility management relaxes some constraints = while also repositioning mobility anchors; it avoids the establishment = of non optimal tunnels between two anchors topologically distant.=20 >>=20 >> Considering the above, the working group will: >>=20 >> Define the problem statement and associated requirements for = distributed mobility management. This work aims at defining the problem = space and identifies the key functional requirements. >>=20 >> Produce a gap analysis mapping the above requirements against = existing solutions. >>=20 >> Give best practices for the deployment of existing mobility protocols = in a distributed mobility management and describe limitations of each = such approach. >>=20 >> Describe extensions, if needed, to current mobility protocols for = their application in distributed mobility architectures >=20 > Comments? >=20 > Jari >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From hesham@elevatemobile.com Thu Nov 3 17:44:27 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3690A21F8CBD for ; Thu, 3 Nov 2011 17:44: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 sQZYw-FlIlsO for ; Thu, 3 Nov 2011 17:44:26 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 3824721F8C5C for ; Thu, 3 Nov 2011 17:44:25 -0700 (PDT) Received: from [120.146.201.23] (helo=[10.0.0.24]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1RM7t2-0007py-VU; Fri, 04 Nov 2011 11:44:01 +1100 User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Fri, 04 Nov 2011 11:43:50 +1100 From: Hesham Soliman To: "Charles E. Perkins" , Jari Arkko Message-ID: Thread-Topic: [MEXT] the future of the MEXT working group In-Reply-To: <4EB2D421.4030905@earthlink.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: jouni.korhonen@nsn.com, mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 00:44:27 -0000 Hi Charlie, I agree completely with you on the problems with the current interfaces in LTE, and in 3G before that. I don't know what the best way to go about it would be. I say this because many people on this list are aware of what's happening in LTE and presumably have similar opinions about the complexity of their solutions, but it's still there. Hesham -----Original Message----- From: "Charles E. Perkins" Organization: Wichorus Inc. Date: Thu, 03 Nov 2011 10:49:21 -0700 To: Jari Arkko Cc: , Subject: Re: [MEXT] the future of the MEXT working group >Hello folks, > >For several years now, I have been studying 4G wireless >network architecture and wondering why there is such a >disconnect between, say, LTE mobility management and >IETF mobility management. Mobile IP has a secondary >role, to say the least. IETF approaches may be seen to >have several inadequacies, and 3GPP approaches also show >some major problems. I think that it is important for >the IETF to devote some serious effort towards bringing >these two worlds together, because current directions >are leading towards an impossibly baroque, wasteful, >nearly impenetrable mess of complication. The effects >overall is loss of performance and opportunity. > >Taking a look at S101 and S103, we can immediately >recognize that they are drastically more complicated, >restrictive, and operationally more expensive than >Mobile IP. Taking a look at S102, we immediately see >that 3GPP mobility management threatens to be different >for each class of application, with an unnecessary >per-application proliferation of servers, protocol, >permissions, traffic controls, configuration, and so on. >Taking a look at recent efforts towards WiFi offload, >we see the same trend of complication and software >hacks that could be avoided with proper IETF >approaches. > >On the IETF side, we should specify: >- Integrated authentication for access control > as well as IP address continuity >- Location-assisted handovers (think MIIS / ANDSF) >- Modular/alternative security >- Signaling on control plane, user traffic on > data plane >- Alternative tunneling (GTP is simply not going > to die a quick death, to say the least) >- geez, the list does go on, but no one reads > long lists ... >... > >I don't know if we already have 3GPP liaison, but >if we do the communication channels don't seem to >have had very much effect within the [mext] work >lately. > >My fear is that if we don't take action, we are >choosing a future that is ever more complicated, >non-extendible, non-flexible, radio technology >specific, application specific, and bug-ridden. >In short, everything we don't want the Internet >to be. And, I am sure no one here doubts that >the Internet of the future is all high-speed >wireless. Where is the IETF going to be? > >If the [mext] working group is shut down, there >is no natural place for this work to happen. >Therefore, I hope that [mext] would NOT shut >down, and instead recharter to tackle these >urgent problems. > >Regards, >Charlie P. > > > >On 10/28/2011 5:08 AM, Jari Arkko wrote: >> All, >> >> We are making some changes to the working group. While we have >> successfully published a large number of specifications in recent years, >> recently it has been difficult to make progress in the group. The chairs >> and ADs have looked at the situation and we believe we need a new focus >> and a bit of new organization as well. We are terminating the working >> group and moving the one remaining active work item to a new working >> group, the "DMM" working group. Here's what is going to happen: >> >> o Jouni Korhonen and Julien Laganier will become the chairs of the >>group. >> >> o The group will meet in Taipei (there is a MEXT slot in the agenda). >> >> o The charter of the group will be changed to focus only on the >> distributed mobility effort. We should discuss the details of this >> charter change both on the list and in the meeting. The meeting agenda >> should reserve some time both for technical discussions as well as the >> charter discussion. >> >> o Once the discussion on the list and in the meeting has finished, we >> will rename the group to "DMM" and put the new charter in effect. >> >> o If there are any other specifications that people would like to >> publish beyond the distributed mobility work, we can offer to AD sponsor >> them to RFCs outside the new working group. If there is some significant >> new activity, we can create new working groups for that. >> >> Comments and feedback and/or alternate suggestions on this plan are >> welcome. >> >> We would like to thank Marcelo for your many years of service in MEXT. >> We could not have completed all the work we did without your energy and >> push for high quality results. We would also like to thank Jouni for >> taking on this new challenge, and Julien for continuing the work in this >> space. >> >> Jari and Ralph >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www.ietf.org/mailman/listinfo/mext From mccap@petoni.org Thu Nov 3 18:16:21 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77CF321F8431 for ; Thu, 3 Nov 2011 18:16:21 -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.350, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_BIZOP=0.7] 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 OFqUvwfyQA6V for ; Thu, 3 Nov 2011 18:16:19 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id BD4A611E80AB for ; Thu, 3 Nov 2011 18:16:18 -0700 (PDT) Received: by qyk32 with SMTP id 32so746664qyk.10 for ; Thu, 03 Nov 2011 18:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=petoni.org; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=roC4nxZuNqmFEL3jSuaPpOIJoULTQYtNtAHtEni/45k=; b=E7SHeYo+gfGZ2K1sW74S3/4OaRqIQQJrDMKkdfTEUM6od4h5xU/V1g8RBPwqn6B4Sh HqlOCsHEYEa638XJKvv5NljvkAMmwuE06GojBccm7rWkWJYeD3sxNXnNUWNz4DfPIvJA 3taHF1IfEzWWX9CLvohIIDJsPzat3QvkcHpXw= MIME-Version: 1.0 Received: by 10.182.110.1 with SMTP id hw1mr2441105obb.38.1320369374599; Thu, 03 Nov 2011 18:16:14 -0700 (PDT) Received: by 10.182.47.97 with HTTP; Thu, 3 Nov 2011 18:16:14 -0700 (PDT) X-Originating-IP: [68.45.157.93] In-Reply-To: References: <4EB2D421.4030905@earthlink.net> Date: Thu, 3 Nov 2011 21:16:14 -0400 Message-ID: From: Pete McCann To: mext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: jouni.korhonen@nsn.com, Jari Arkko Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 01:16:21 -0000 A good architecture is made not only from deciding what to standardize but also from what not to standardize. Operators like to open up and specify interfaces because they think it give= s them leverage with suppliers. They don't want to be locked into a single v= endor for their whole network. Non-incumbent vendors like to open up and specify interfaces because it opens up new business opportunities for their boxes. A good architecture would integrate the NAS/Gateway with the radio. We should have exercised restraint in opening up any interface between those two. There is in 3GPP a feature called Local IP Access (LIPA). It was originall= y designed for femtocells, because it was obvious that people who deployed them on their own network would want access to their own local services on their own network instead of being put into a compulsory tunnel back to some distant home operator network. Perhaps IETF could take LIPA as a starting point to design a cleaner mobility management solution. It isn't clear to me that we should even start with tunnels as a basic buil= ding block. -Pete On Thu, Nov 3, 2011 at 8:43 PM, Hesham Soliman w= rote: > Hi Charlie, > > I agree completely with you on the problems with the current interfaces i= n > LTE, and in 3G before that. > I don't know what the best way to go about it would be. I say this becaus= e > many people on this list are aware of what's happening in LTE and > presumably have similar opinions about the complexity of their solutions, > but it's still there. > > Hesham > > -----Original Message----- > From: "Charles E. Perkins" > Organization: Wichorus Inc. > Date: Thu, 03 Nov 2011 10:49:21 -0700 > To: Jari Arkko > Cc: , > Subject: Re: [MEXT] the future of the MEXT working group > >>Hello folks, >> >>For several years now, I have been studying 4G wireless >>network architecture and wondering why there is such a >>disconnect between, say, LTE mobility management and >>IETF mobility management. =A0Mobile IP has a secondary >>role, to say the least. =A0IETF approaches may be seen to >>have several inadequacies, and 3GPP approaches also show >>some major problems. =A0I think that it is important for >>the IETF to devote some serious effort towards bringing >>these two worlds together, because current directions >>are leading towards an impossibly baroque, wasteful, >>nearly impenetrable mess of complication. =A0The effects >>overall is loss of performance and opportunity. >> >>Taking a look at S101 and S103, we can immediately >>recognize that they are drastically more complicated, >>restrictive, and operationally more expensive than >>Mobile IP. =A0Taking a look at S102, we immediately see >>that 3GPP mobility management threatens to be different >>for each class of application, with an unnecessary >>per-application proliferation of servers, protocol, >>permissions, traffic controls, configuration, and so on. >>Taking a look at recent efforts towards WiFi offload, >>we see the same trend of complication and software >>hacks that could be avoided with proper IETF >>approaches. >> >>On the IETF side, we should specify: >>- Integrated authentication for access control >> =A0 as well as IP address continuity >>- Location-assisted handovers (think MIIS / ANDSF) >>- Modular/alternative security >>- Signaling on control plane, user traffic on >> =A0 data plane >>- Alternative tunneling (GTP is simply not going >> =A0 to die a quick death, to say the least) >>- geez, the list does go on, but no one reads >> =A0 long lists ... >>... >> >>I don't know if we already have 3GPP liaison, but >>if we do the communication channels don't seem to >>have had very much effect within the [mext] work >>lately. >> >>My fear is that if we don't take action, we are >>choosing a future that is ever more complicated, >>non-extendible, non-flexible, radio technology >>specific, application specific, and bug-ridden. >>In short, everything we don't want the Internet >>to be. =A0And, I am sure no one here doubts that >>the Internet of the future is all high-speed >>wireless. =A0Where is the IETF going to be? >> >>If the [mext] working group is shut down, there >>is no natural place for this work to happen. >>Therefore, I hope that [mext] would NOT shut >>down, and instead recharter to tackle these >>urgent problems. >> >>Regards, >>Charlie P. >> >> >> >>On 10/28/2011 5:08 AM, Jari Arkko wrote: >>> All, >>> >>> We are making some changes to the working group. While we have >>> successfully published a large number of specifications in recent years= , >>> recently it has been difficult to make progress in the group. The chair= s >>> and ADs have looked at the situation and we believe we need a new focus >>> and a bit of new organization as well. We are terminating the working >>> group and moving the one remaining active work item to a new working >>> group, the "DMM" working group. Here's what is going to happen: >>> >>> o Jouni Korhonen and Julien Laganier will become the chairs of the >>>group. >>> >>> o The group will meet in Taipei (there is a MEXT slot in the agenda). >>> >>> o The charter of the group will be changed to focus only on the >>> distributed mobility effort. We should discuss the details of this >>> charter change both on the list and in the meeting. The meeting agenda >>> should reserve some time both for technical discussions as well as the >>> charter discussion. >>> >>> o Once the discussion on the list and in the meeting has finished, we >>> will rename the group to "DMM" and put the new charter in effect. >>> >>> o If there are any other specifications that people would like to >>> publish beyond the distributed mobility work, we can offer to AD sponso= r >>> them to RFCs outside the new working group. If there is some significan= t >>> new activity, we can create new working groups for that. >>> >>> Comments and feedback and/or alternate suggestions on this plan are >>> welcome. >>> >>> We would like to thank Marcelo for your many years of service in MEXT. >>> We could not have completed all the work we did without your energy and >>> push for high quality results. We would also like to thank Jouni for >>> taking on this new challenge, and Julien for continuing the work in thi= s >>> space. >>> >>> Jari and Ralph >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >> >>_______________________________________________ >>MEXT mailing list >>MEXT@ietf.org >>https://www.ietf.org/mailman/listinfo/mext > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From jouni.nospam@gmail.com Fri Nov 4 01:19:29 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A8E21F8B9A for ; Fri, 4 Nov 2011 01:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 BjQU+1IkpGzp for ; Fri, 4 Nov 2011 01:19:28 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id D452621F8B8E for ; Fri, 4 Nov 2011 01:19:25 -0700 (PDT) Received: by eyg24 with SMTP id 24so2133028eyg.31 for ; Fri, 04 Nov 2011 01:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=4Y39nNhJUdCt3FVZkwFLkVY5G4rt3s0WS8eQwyOJ1jY=; b=ektbPi4lziajPmalLgVLXqkkPWYTIB3/ZlEDoMtU4rq31/KE9UXfQNhZiDs6Tpu1Ir XMQG04xiM6F4jx2f6Njxs6Bn/znrRmy2/kpOm8i3KPbw5tVhykwsPR7fRkeuLuULJPxx ppLUhOwlvBTZYxxVimD0CjCtd/lu2M52mjPnw= Received: by 10.213.102.5 with SMTP id e5mr140071ebo.44.1320394762247; Fri, 04 Nov 2011 01:19:22 -0700 (PDT) Received: from dhcp-27-53.ripemtg.ripe.net (dhcp-27-53.ripemtg.ripe.net. [193.0.27.53]) by mx.google.com with ESMTPS id v3sm22945299eej.7.2011.11.04.01.19.17 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Nov 2011 01:19:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Fri, 4 Nov 2011 10:19:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1672201A-C652-4204-99D9-3DE4D23D2BB2@gmail.com> References: <4EB2D421.4030905@earthlink.net> To: Pete McCann X-Mailer: Apple Mail (2.1084) Cc: jouni.korhonen@nsn.com, Jari Arkko , mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 08:19:29 -0000 Pete, On Nov 4, 2011, at 3:16 AM, Pete McCann wrote: > A good architecture is made not only from deciding what to standardize = but > also from what not to standardize. Exactly. [snip] >=20 > Perhaps IETF could take LIPA as a starting point to design a cleaner > mobility management solution. What came out from a certain SDO as a "Local IP Access" did not turn out = as the most elegant solution :) But I do agree that from the idea & = initial use case point of view, it definitely is something to look at.. = even as a basis for a cleaner design. > It isn't clear to me that we should even start with tunnels as a basic = building > block. I am along the same lines. See my earlier mail on the charter = http://www.ietf.org/mail-archive/web/mext/current/msg04905.html - Jouni >=20 > -Pete >=20 > On Thu, Nov 3, 2011 at 8:43 PM, Hesham Soliman = wrote: >> Hi Charlie, >>=20 >> I agree completely with you on the problems with the current = interfaces in >> LTE, and in 3G before that. >> I don't know what the best way to go about it would be. I say this = because >> many people on this list are aware of what's happening in LTE and >> presumably have similar opinions about the complexity of their = solutions, >> but it's still there. >>=20 >> Hesham >>=20 >> -----Original Message----- >> From: "Charles E. Perkins" >> Organization: Wichorus Inc. >> Date: Thu, 03 Nov 2011 10:49:21 -0700 >> To: Jari Arkko >> Cc: , >> Subject: Re: [MEXT] the future of the MEXT working group >>=20 >>> Hello folks, >>>=20 >>> For several years now, I have been studying 4G wireless [snap] From pierrick.seite@orange.com Fri Nov 4 02:28:21 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F149421F8B88 for ; Fri, 4 Nov 2011 02:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 GBlPIIyFrkj9 for ; Fri, 4 Nov 2011 02:28:21 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id B414D21F8B68 for ; Fri, 4 Nov 2011 02:28:20 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AE63A8B8003; Fri, 4 Nov 2011 10:29:42 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id A10616C0001; Fri, 4 Nov 2011 10:29:42 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Nov 2011 10:28:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Nov 2011 10:28:18 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C4620203035E@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <1B31D76B-4C76-4351-B270-437D4560007C@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] the future of the MEXT working group Thread-Index: Acyah8uX8w/lMiZTRPqlSNN+Us2VZwASRBuQ References: <4EAA9B4A.3020208@piuha.net> <4EAA9E34.2080903@piuha.net> <1B31D76B-4C76-4351-B270-437D4560007C@gmail.com> From: To: , X-OriginalArrivalTime: 04 Nov 2011 09:28:19.0867 (UTC) FILETIME=[1720C6B0:01CC9AD4] Cc: mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 09:28:22 -0000 Hi, > -----Message d'origine----- > De=A0: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part = de > jouni korhonen > Envoy=E9=A0: vendredi 4 novembre 2011 01:22 > =C0=A0: Jari Arkko > Cc=A0: mext@ietf.org > Objet=A0: Re: [MEXT] the future of the MEXT working group >=20 >=20 > Hi, >=20 > Few quick comments. I would remove all explicit references to 3GPP and > existing offload mechanisms therein. FWIW this WG is not supposed to = be a > stub of SA2. The possible (protocol) enhancement must be generic = enough to > be applicable outside of a specific deployment architecture. >=20 I definitely agree to remove reference to 3GPP. However, I think we need = clear use-case to motivate the distribution. As a starting point, we = could assume a network architecture relying on the distribution of = traffic anchors for local IP access/CDN; then study how to bring = mobility support in this context.=20 > Also, I think we ought not only consider just mobility enhancement. = More > efficient use of CoA(s) for direct/local/non-tunneled communication = along > with existing mobility solutions should be in scope as well. >=20 Actually, this is the idea behind dynamic mobility management described = in the charter: use the CoA for IP flow which does not require mobility = support. We are inline. Pierrick > - Jouni >=20 > On Oct 28, 2011, at 3:21 PM, Jari Arkko wrote: >=20 > > And a follow-up on the charter. I'm describing a couple of different > takes on what the new charter could be. Comments and alternative = proposals > are welcome. This is what the current charter says about DMM: > > > >> The working group will also work on operational considerations on > >> setting up Mobile IPv6 networks so that traffic is distributed > >> in an optimal way, for instance by using existing protocol = mechanisms > >> to select the closest home agents for new clients. > >> > >> Oct 2011 - Submit I-D 'Operational considerations for distributed = use > of Mobile IPv6' for publication as Informational. > > > > Which is admittedly a bit short, but is also very concrete and > achievable, if we work on it. I got another proposal from Hui Deng = that > extended this a bit, including going beyond mere operational > considerations. > > > >> In the past decade a fair number of mobility protocols have been > standardized. Although the protocols differ in terms of functions and > associated message format, we can identify a few key common features: > >> presence of a centralized mobility anchor providing global = reachability > and an always-on experience > >> extensions to optimize handover performance while users roam across > wireless cells > >> extensions to enable the use of heterogeneous wireless interfaces = for > multi-mode terminals (e.g. cellular phones) > >> The presence of the centralized mobility anchor allows a mobile = device > to be reachable when it is not connected to its home domain. The = anchor, > among other tasks, ensures forwarding of packets destined to or sent = from > the mobile device. As such, most of the deployed architectures today = have > a small number of centralized anchors managing the traffic of millions = of > mobile subscribers. > >> > >> To optimize handovers for mobile users, 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 > impose stringent requirements in terms of delay. Notions of = localization > and distribution of local agents have been introduced to reduce = signalling > overhead. Unfortunately today we witness difficulties in getting such > protocols deployed, often leading to sub-optimal choices. Moreover, = all > the availability of multi-mode devices and the possibility to use = several > network interfaces simultaneously have motivated the development of = more > new protocol extensions. > >> > >> Mobile users are, more than ever, consuming Internet content, and > impose new requirements on mobile core networks for data traffic = delivery. > When this traffic demand exceeds available capacity, service providers > need to implement new strategies such as selective traffic offload = (e.g. > 3GPP work items LIPA/SIPTO) through alternative access networks (e.g. > WLAN). Moreover, the localization of content providers closer to the > Mobile/Fixed Internet Service Providers network requires taking into > account local Content Delivery Networks (CDNs) while providing = mobility > services. > >> > >> As long as demand exceeds capacity, both offloading and CDN = techniques > could benefit from the development of more flat mobile architectures = (i.e., > fewer levels of routing hierarchy introduced into the data path by the > mobility management system). This view is reinforced by the shift in > users' traffic behaviour, aimed at increasing direct communications = among > peers in the same geographical area. The development of truly flat = mobile > architectures would result in anchoring the traffic closer to point of > attachment of the user and overcoming the suboptimal routing issues of = a > centralized mobility scheme. > >> > >> While deploying today's mobile networks, service providers face new > challenges. More often than not, mobile devices remain attached to the > same point of attachment, in which case specific IP mobility = management > support is not required for applications that launch and complete = while > connected to the same point of attachment. However, the mobility = support > has been designed to be always on and to maintain the context for each > mobile subscriber as long as they are connected to the network. This = can > result in a waste of resources and ever-increasing costs for the = service > provider. Infrequent mobility and intelligence of many applications > suggest that mobility can be provided dynamically, thus simplifying = the > context maintained in the different nodes of the mobile network. > >> > >> The proposed charter will address two complementary aspects of = mobility > management procedures: the distribution of mobility anchors to achieve = a > more flat design and the dynamic activation/deactivation of mobility > protocol support as an enabler to distributed mobility management. The > former has the goal of positioning mobility anchors (HA, LMA) closer = to > the user; ideally, these mobility anchors could be collocated with the > first hop router. The latter, facilitated by the distribution of = mobility > anchors, aims at identifying when mobility must be activated and > identifying sessions that do not impose mobility management -- thus > reducing the amount of state information to be maintained in the = various > mobility anchors of the mobile network. The key idea is that dynamic > mobility management relaxes some constraints while also repositioning > mobility anchors; it avoids the establishment of non optimal tunnels > between two anchors topologically distant. > >> > >> Considering the above, the working group will: > >> > >> Define the problem statement and associated requirements for > distributed mobility management. This work aims at defining the = problem > space and identifies the key functional requirements. > >> > >> Produce a gap analysis mapping the above requirements against = existing > solutions. > >> > >> Give best practices for the deployment of existing mobility = protocols > in a distributed mobility management and describe limitations of each = such > approach. > >> > >> Describe extensions, if needed, to current mobility protocols for = their > application in distributed mobility architectures > > > > Comments? > > > > Jari > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From jouni.nospam@gmail.com Fri Nov 4 05:38:01 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A37221F8B8E for ; Fri, 4 Nov 2011 05:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 U-z06MlA1w82 for ; Fri, 4 Nov 2011 05:38:00 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4762521F89BA for ; Fri, 4 Nov 2011 05:38:00 -0700 (PDT) Received: by eyg24 with SMTP id 24so2332671eyg.31 for ; Fri, 04 Nov 2011 05:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=08XcnWi9q27l8/gjMJPpF+NqykB2YXTnLDNuYJ8lAA8=; b=GiRnYT1Xo9KQK2iAzOWfDpXEPj0tlFnzSEP6bTlo72MdcFTCX0SciiwVp9wQsxMlIb 0MUeEZuG+77jWiVGFdttcT8wQrSB1EMQrB7qxTZHt2eu6ZVCGw6+UW5c0jsO6pyCrqdh hDSgl7E2vBs/u7yX+Rk2Oe3gev7kiUpaVozqY= Received: by 10.213.17.74 with SMTP id r10mr226473eba.125.1320410277887; Fri, 04 Nov 2011 05:37:57 -0700 (PDT) Received: from dhcp-27-53.ripemtg.ripe.net (dhcp-27-53.ripemtg.ripe.net. [193.0.27.53]) by mx.google.com with ESMTPS id f41sm24848745eec.5.2011.11.04.05.37.54 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Nov 2011 05:37:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C4620203035E@ftrdmel0.rd.francetelecom.fr> Date: Fri, 4 Nov 2011 14:37:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2C16A256-DEA6-4690-B35B-D5A41FCD02A3@gmail.com> References: <4EAA9B4A.3020208@piuha.net> <4EAA9E34.2080903@piuha.net> <1B31D76B-4C76-4351-B270-437D4560007C@gmail.com> <843DA8228A1BA74CA31FB4E111A5C4620203035E@ftrdmel0.rd.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) Cc: jari.arkko@piuha.net, mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 12:38:01 -0000 Pierrick, On Nov 4, 2011, at 11:28 AM, = wrote: >> Also, I think we ought not only consider just mobility enhancement. = More >> efficient use of CoA(s) for direct/local/non-tunneled communication = along >> with existing mobility solutions should be in scope as well. >>=20 >=20 > Actually, this is the idea behind dynamic mobility management = described in the charter: use the CoA for IP flow which does not require = mobility support. We are inline. >=20 > Pierrick Nit picking and a bit of intentional teasing ;) Above is currently about = a half.. one clear statement in the charter proposal is "the = distribution of mobility anchors to achieve a more flat design". The = other clear statement is "the dynamic activation/deactivation of = mobility protocol support as an enabler". However to use CoA(s) or any = address you get locally falls greatly into the source address selection = issues, which is not really about mobility per se. You don't necessarily = even need distributed mobility anchors to facilitate that. Of course, = there are vast amount possible solution approaches in this space. - Jouni From pierrick.seite@orange.com Fri Nov 4 07:46:27 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7B821F8B7D for ; Fri, 4 Nov 2011 07:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.061 X-Spam-Level: X-Spam-Status: No, score=-3.061 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 34vNs1t3nKGa for ; Fri, 4 Nov 2011 07:46:26 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8760E21F849B for ; Fri, 4 Nov 2011 07:46:22 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 33788AB0004; Fri, 4 Nov 2011 15:47:23 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 2AC758D0001; Fri, 4 Nov 2011 15:47:23 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Nov 2011 15:46:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Nov 2011 15:46:19 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462020304E2@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <2C16A256-DEA6-4690-B35B-D5A41FCD02A3@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] the future of the MEXT working group Thread-Index: Acya7pWOvfOvm9cOTkOiYZoldDZd4wADASgQ References: <4EAA9B4A.3020208@piuha.net> <4EAA9E34.2080903@piuha.net> <1B31D76B-4C76-4351-B270-437D4560007C@gmail.com> <843DA8228A1BA74CA31FB4E111A5C4620203035E@ftrdmel0.rd.francetelecom.fr> <2C16A256-DEA6-4690-B35B-D5A41FCD02A3@gmail.com> From: To: X-OriginalArrivalTime: 04 Nov 2011 14:46:20.0898 (UTC) FILETIME=[844F0C20:01CC9B00] Cc: jari.arkko@piuha.net, mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 14:46:27 -0000 > -----Message d'origine----- > De=A0: jouni korhonen [mailto:jouni.nospam@gmail.com] > Envoy=E9=A0: vendredi 4 novembre 2011 13:38 > =C0=A0: SEITE Pierrick RD-RESA-REN > Cc=A0: jari.arkko@piuha.net; mext@ietf.org > Objet=A0: Re: [MEXT] the future of the MEXT working group >=20 > Pierrick, >=20 > On Nov 4, 2011, at 11:28 AM, > wrote: >=20 > >> Also, I think we ought not only consider just mobility enhancement. > More > >> efficient use of CoA(s) for direct/local/non-tunneled communication > along > >> with existing mobility solutions should be in scope as well. > >> > > > > Actually, this is the idea behind dynamic mobility management = described > in the charter: use the CoA for IP flow which does not require = mobility > support. We are inline. > > > > Pierrick >=20 > Nit picking and a bit of intentional teasing ;) Above is currently = about a > half.. one clear statement in the charter proposal is "the = distribution of > mobility anchors to achieve a more flat design". The other clear > statement is "the dynamic activation/deactivation of mobility protocol > support as an enabler". However to use CoA(s) or any address you get > locally falls greatly into the source address selection issues, which = is > not really about mobility per se. You don't necessarily even need > distributed mobility anchors to facilitate that.=20 I agree, and I'm not saying that we need to distribute mobility = management to benefit from dynamic MM. But I think that distribution can = facilitate dynamic MM, even brings dynamic MM natively. Typically, if HA = are co-located on each AR: the MN can initiate a communication with the = IP obtained from the current AR, with standard IP routing coming into = play. Then, if the MN changes the point of attachment, mobility = management come into play: previous AR plays the HA role and the current = IP is binded to the Ip obtained on the new AR. But, it's just an example = of solution and, as you said, there are many other possible ways. So, = I'll not digress more; I just want to stress that dynamic MM should not = be ignored in future work. Pierrick Of course, there are vast > amount possible solution approaches in this space. >=20 > - Jouni From Basavaraj.Patil@nokia.com Fri Nov 4 09:05:57 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF9921F8C93 for ; Fri, 4 Nov 2011 09:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.942 X-Spam-Level: X-Spam-Status: No, score=-102.942 tagged_above=-999 required=5 tests=[AWL=0.657, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 lE2Rrce9LfQg for ; Fri, 4 Nov 2011 09:05:56 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDA421F8C92 for ; Fri, 4 Nov 2011 09:05:55 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pA4G5ch8030683; Fri, 4 Nov 2011 18:05:49 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Nov 2011 18:05:25 +0200 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.235]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.01.0339.002; Fri, 4 Nov 2011 17:05:21 +0100 From: To: Thread-Topic: [MEXT] the future of the MEXT working group Thread-Index: AQHMlWpmfRWG/cEPIEyACm1+ri2dNZWbZjyAgABzzgCAAQGEgA== Date: Fri, 4 Nov 2011 16:05:21 +0000 Message-ID: <350CD199-C70E-491B-B81D-AFE1D3F95C05@nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.74.219.186] Content-Type: text/plain; charset="us-ascii" Content-ID: <6DED3A4F87B49C40B94AE028B9BE5306@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Nov 2011 16:05:25.0819 (UTC) FILETIME=[908088B0:01CC9B0B] X-Nokia-AV: Clean Cc: jouni.korhonen@nsn.com, jari.arkko@piuha.net, mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 16:05:57 -0000 On Nov 3, 2011, at 7:43 PM, ext Hesham Soliman wrote: > Hi Charlie, >=20 > I agree completely with you on the problems with the current interfaces i= n > LTE, and in 3G before that. > I don't know what the best way to go about it would be. I say this becaus= e > many people on this list are aware of what's happening in LTE and > presumably have similar opinions about the complexity of their solutions, > but it's still there. >=20 Unless you can make a clear and definitive case that the current LTE soluti= on does not work or scale or inefficient in terms of performance or otherwi= se, it is difficult to bring about change. Complexity has its own benefits.= . Its just a matter of who the beneficiaries are :) Hence claiming complexity as the reason to consider alternatives is an uphi= ll task. If this complexity becomes an issue in terms of interop, CAPEX/OPE= X costs etc. that may trigger a revisit to the architecture.=20 -Raj > Hesham >=20 > -----Original Message----- > From: "Charles E. Perkins" > Organization: Wichorus Inc. > Date: Thu, 03 Nov 2011 10:49:21 -0700 > To: Jari Arkko > Cc: , > Subject: Re: [MEXT] the future of the MEXT working group >=20 >> Hello folks, >>=20 >> For several years now, I have been studying 4G wireless >> network architecture and wondering why there is such a >> disconnect between, say, LTE mobility management and >> IETF mobility management. Mobile IP has a secondary >> role, to say the least. IETF approaches may be seen to >> have several inadequacies, and 3GPP approaches also show >> some major problems. I think that it is important for >> the IETF to devote some serious effort towards bringing >> these two worlds together, because current directions >> are leading towards an impossibly baroque, wasteful, >> nearly impenetrable mess of complication. The effects >> overall is loss of performance and opportunity. >>=20 >> Taking a look at S101 and S103, we can immediately >> recognize that they are drastically more complicated, >> restrictive, and operationally more expensive than >> Mobile IP. Taking a look at S102, we immediately see >> that 3GPP mobility management threatens to be different >> for each class of application, with an unnecessary >> per-application proliferation of servers, protocol, >> permissions, traffic controls, configuration, and so on. >> Taking a look at recent efforts towards WiFi offload, >> we see the same trend of complication and software >> hacks that could be avoided with proper IETF >> approaches. >>=20 >> On the IETF side, we should specify: >> - Integrated authentication for access control >> as well as IP address continuity >> - Location-assisted handovers (think MIIS / ANDSF) >> - Modular/alternative security >> - Signaling on control plane, user traffic on >> data plane >> - Alternative tunneling (GTP is simply not going >> to die a quick death, to say the least) >> - geez, the list does go on, but no one reads >> long lists ... >> ... >>=20 >> I don't know if we already have 3GPP liaison, but >> if we do the communication channels don't seem to >> have had very much effect within the [mext] work >> lately. >>=20 >> My fear is that if we don't take action, we are >> choosing a future that is ever more complicated, >> non-extendible, non-flexible, radio technology >> specific, application specific, and bug-ridden. >> In short, everything we don't want the Internet >> to be. And, I am sure no one here doubts that >> the Internet of the future is all high-speed >> wireless. Where is the IETF going to be? >>=20 >> If the [mext] working group is shut down, there >> is no natural place for this work to happen. >> Therefore, I hope that [mext] would NOT shut >> down, and instead recharter to tackle these >> urgent problems. >>=20 >> Regards, >> Charlie P. >>=20 >>=20 >>=20 >> On 10/28/2011 5:08 AM, Jari Arkko wrote: >>> All, >>>=20 >>> We are making some changes to the working group. While we have >>> successfully published a large number of specifications in recent years= , >>> recently it has been difficult to make progress in the group. The chair= s >>> and ADs have looked at the situation and we believe we need a new focus >>> and a bit of new organization as well. We are terminating the working >>> group and moving the one remaining active work item to a new working >>> group, the "DMM" working group. Here's what is going to happen: >>>=20 >>> o Jouni Korhonen and Julien Laganier will become the chairs of the >>> group. >>>=20 >>> o The group will meet in Taipei (there is a MEXT slot in the agenda). >>>=20 >>> o The charter of the group will be changed to focus only on the >>> distributed mobility effort. We should discuss the details of this >>> charter change both on the list and in the meeting. The meeting agenda >>> should reserve some time both for technical discussions as well as the >>> charter discussion. >>>=20 >>> o Once the discussion on the list and in the meeting has finished, we >>> will rename the group to "DMM" and put the new charter in effect. >>>=20 >>> o If there are any other specifications that people would like to >>> publish beyond the distributed mobility work, we can offer to AD sponso= r >>> them to RFCs outside the new working group. If there is some significan= t >>> new activity, we can create new working groups for that. >>>=20 >>> Comments and feedback and/or alternate suggestions on this plan are >>> welcome. >>>=20 >>> We would like to thank Marcelo for your many years of service in MEXT. >>> We could not have completed all the work we did without your energy and >>> push for high quality results. We would also like to thank Jouni for >>> taking on this new challenge, and Julien for continuing the work in thi= s >>> space. >>>=20 >>> Jari and Ralph >>>=20 >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>>=20 >>=20 >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From sarikaya2012@gmail.com Fri Nov 4 09:18:10 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB4821F8C34 for ; Fri, 4 Nov 2011 09:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Yy9B1gutwCLF for ; Fri, 4 Nov 2011 09:18:09 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1694621F8C1E for ; Fri, 4 Nov 2011 09:18:09 -0700 (PDT) Received: by ggnv1 with SMTP id v1so3042265ggn.31 for ; Fri, 04 Nov 2011 09:18:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=A1DMUbOxyuDo9ivVUrpPpNPx+NlIBSsqP3GSHaKtyJs=; b=YInjJvuRtArAqD93Y9TRlq0mAYzi7MQnq7ITbxyTc334NAMINkNqE7tSd6CdIG8vu4 g3R//DkR0ucaxWnbScfUEC0KOefVlq20Gz58P4hkgfh5Bx1Khu1UliV4Kn/eBy9OfwfE u1og6O2OkCygI0HGnvqaxIIjgGGdqw+U+ynNo= MIME-Version: 1.0 Received: by 10.236.192.233 with SMTP id i69mr21705751yhn.60.1320423488551; Fri, 04 Nov 2011 09:18:08 -0700 (PDT) Received: by 10.236.108.135 with HTTP; Fri, 4 Nov 2011 09:18:08 -0700 (PDT) In-Reply-To: <1672201A-C652-4204-99D9-3DE4D23D2BB2@gmail.com> References: <4EB2D421.4030905@earthlink.net> <1672201A-C652-4204-99D9-3DE4D23D2BB2@gmail.com> Date: Fri, 4 Nov 2011 11:18:08 -0500 Message-ID: From: Behcet Sarikaya To: jouni korhonen Content-Type: multipart/alternative; boundary=20cf3056431ffcfb2604b0eb0c9f Cc: Pete McCann , mext@ietf.org, Jari Arkko , jouni.korhonen@nsn.com Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 16:18:10 -0000 --20cf3056431ffcfb2604b0eb0c9f Content-Type: text/plain; charset=ISO-8859-1 Hi all, I am confused about all these very high level, intelligent looking comments, and I must say I am fed up with them :-). Non-tunneled communications is already there in DMM. You connect to the nearest HA and all new communications is non-tunneled. Do we agree that we should differentiate client-based and network based protocols and discuss them in different places? or even there is no issue for one. I think this is what we should decide now. Regards, Behcet On Fri, Nov 4, 2011 at 3:19 AM, jouni korhonen wrote: > Pete, > > On Nov 4, 2011, at 3:16 AM, Pete McCann wrote: > > > A good architecture is made not only from deciding what to standardize > but > > also from what not to standardize. > > Exactly. > > [snip] > > > > > Perhaps IETF could take LIPA as a starting point to design a cleaner > > mobility management solution. > > What came out from a certain SDO as a "Local IP Access" did not turn out > as the most elegant solution :) But I do agree that from the idea & initial > use case point of view, it definitely is something to look at.. even as a > basis for a cleaner design. > > > It isn't clear to me that we should even start with tunnels as a basic > building > > block. > > I am along the same lines. See my earlier mail on the charter > http://www.ietf.org/mail-archive/web/mext/current/msg04905.html > > - Jouni > > > > > > > -Pete > > > > On Thu, Nov 3, 2011 at 8:43 PM, Hesham Soliman > wrote: > >> Hi Charlie, > >> > >> I agree completely with you on the problems with the current interfaces > in > >> LTE, and in 3G before that. > >> I don't know what the best way to go about it would be. I say this > because > >> many people on this list are aware of what's happening in LTE and > >> presumably have similar opinions about the complexity of their > solutions, > >> but it's still there. > >> > >> Hesham > >> > >> -----Original Message----- > >> From: "Charles E. Perkins" > >> Organization: Wichorus Inc. > >> Date: Thu, 03 Nov 2011 10:49:21 -0700 > >> To: Jari Arkko > >> Cc: , > >> Subject: Re: [MEXT] the future of the MEXT working group > >> > >>> Hello folks, > >>> > >>> For several years now, I have been studying 4G wireless > > [snap] > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > --20cf3056431ffcfb2604b0eb0c9f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

I am confused about all these very high level, intelligent l= ooking comments, and I must say I am fed up with them :-).

Non-tunne= led communications is already there in DMM. You connect to the nearest HA a= nd all new communications is non-tunneled.

Do we agree that we should differentiate client-based and network based= protocols and discuss them in different places? or even there is no issue = for one.

I think this is what we should decide now.

Regards,<= br>
Behcet

On Fri, Nov 4, 2011 at 3:19 AM= , jouni korhonen <jouni.nospam@gmail.com> wrote:
Pete,

On Nov 4, 2011, at 3:16 AM, Pete McCann wrote:

> A good architecture is made not only from deciding what to standardize= but
> also from what not to standardize.

Exactly.

[snip]

>
> Perhaps IETF could take LIPA as a starting point to design a cleaner > mobility management solution.

What came out from a certain SDO as a "Local IP Access" did= not turn out as the most elegant solution :) But I do agree that from the = idea & initial use case point of view, it definitely is something to lo= ok at.. even as a basis for a cleaner design.

> It isn't clear to me that we should even start with tunnels as a b= asic building
> block.

I am along the same lines. See my earlier mail on the charter http://www.ietf.org/mail-archive/web/mext/current/msg04905.html=

- Jouni



>
> -Pete
>
> On Thu, Nov 3, 2011 at 8:43 PM, Hesham Soliman <hesham@elevatemobile.com> wrote:
>> Hi Charlie,
>>
>> I agree completely with you on the problems with the current inter= faces in
>> LTE, and in 3G before that.
>> I don't know what the best way to go about it would be. I say = this because
>> many people on this list are aware of what's happening in LTE = and
>> presumably have similar opinions about the complexity of their sol= utions,
>> but it's still there.
>>
>> Hesham
>>
>> -----Original Message-----
>> From: "Charles E. Perkins" <charles.perkins@earthlink.net>
>> Organization: Wichorus Inc.
>> Date: Thu, 03 Nov 2011 10:49:21 -0700
>> To: Jari Arkko <jari.ar= kko@piuha.net>
>> Cc: <jouni.korhonen@n= sn.com>, <mext@ietf.org><= br> >> Subject: Re: [MEXT] the future of the MEXT working group
>>
>>> Hello folks,
>>>
>>> For several years now, I have been studying 4G wireless

[snap]



_______________________________________________
MEXT mailing list
MEXT@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mext

--20cf3056431ffcfb2604b0eb0c9f-- From maxpassion@gmail.com Fri Nov 4 09:41:43 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BA421F8AFE for ; Fri, 4 Nov 2011 09:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 8igkZD7zd9C7 for ; Fri, 4 Nov 2011 09:41:42 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9D52721F8AE1 for ; Fri, 4 Nov 2011 09:41:42 -0700 (PDT) Received: by iaeo4 with SMTP id o4so3569029iae.31 for ; Fri, 04 Nov 2011 09:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=WI+Vv77rEDz4gT3eWCKZSEYmY8tN1R/Qscov7iZSvVE=; b=erxddeRAb1SNoy/zN4rMgd+Vq5jitQAZnUysIQtBPBzoP36mvS5no3gM8IUEJkX4rd zdNNLkp3MaEHptTaiByO3vEYgS1qj2mdr1tFQBy35Tg6a9pzIOJ3A0XxQQUZLFB8vrzL XVOIpS5ejF/7WyH1UCuxiN4XLrN4Kc2OwyP4c= MIME-Version: 1.0 Received: by 10.42.147.72 with SMTP id m8mr17114811icv.56.1320424902312; Fri, 04 Nov 2011 09:41:42 -0700 (PDT) Received: by 10.42.228.68 with HTTP; Fri, 4 Nov 2011 09:41:42 -0700 (PDT) In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46201FE517F@ftrdmel0.rd.francetelecom.fr> References: <4EAA9B4A.3020208@piuha.net> <4EAA9E34.2080903@piuha.net> <843DA8228A1BA74CA31FB4E111A5C46201FE517F@ftrdmel0.rd.francetelecom.fr> Date: Sat, 5 Nov 2011 00:41:42 +0800 Message-ID: From: liu dapeng To: pierrick.seite@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: jari.arkko@piuha.net, mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 16:41:43 -0000 Hi Pierrick, 2011/11/2, pierrick.seite@orange.com : > Hi Jari, > > > > Just a minor comment: > > > > This charter addresses both the distribution of mobility functions and th= e > dynamic mobility management. Even if dynamic activation/deactivation of > mobility support can be seen as an enabler to distributed mobility > management, I think the work item acronym should refer to both features. = So, > to avoid any ambiguity, I'd suggest to use the acronym DDMM (Distributed = and > Dynamic Mobility Management) for the work item. There is no contradiction between distributed and dynamic. Actually "dynamic mobility" could be considered as some sort of "distributed mobility". So I think DMM is a simple and concise acronym. Dapeng > > > Regards, > > Pierrick > > > > > > ________________________________ > > De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part de J= ari > Arkko > Envoy=E9 : vendredi 28 octobre 2011 14:21 > =C0 : mext@ietf.org > Objet : Re: [MEXT] the future of the MEXT working group > > > > And a follow-up on the charter. I'm describing a couple of different take= s > on what the new charter could be. Comments and alternative proposals are > welcome. This is what the current charter says about DMM: > > > > > The working group will also work on operational considerations on > setting up Mobile IPv6 networks so that traffic is distributed > in an optimal way, for instance by using existing protocol mechanisms > to select the closest home agents for new clients. > > Oct 2011 - Submit I-D 'Operational considerations for distributed use o= f > Mobile IPv6' for publication as Informational. > > > Which is admittedly a bit short, but is also very concrete and achievable= , > if we work on it. I got another proposal from Hui Deng that extended this= a > bit, including going beyond mere operational considerations. > > > > > In the past decade a fair number of mobility protocols have been > standardized. Although the protocols differ in terms of functions and > associated message format, we can identify a few key common features: > presence of a centralized mobility anchor providing global reachability a= nd > an always-on experience > extensions to optimize handover performance while users roam across wirel= ess > cells > extensions to enable the use of heterogeneous wireless interfaces for > multi-mode terminals (e.g. cellular phones) > The presence of the centralized mobility anchor allows a mobile device to= be > reachable when it is not connected to its home domain. The anchor, among > other tasks, ensures forwarding of packets destined to or sent from the > mobile device. As such, most of the deployed architectures today have a > small number of centralized anchors managing the traffic of millions of > mobile subscribers. > > To optimize handovers for mobile users, the base protocols have been > extended to efficiently handle packet forwarding between the previous and > new points of attachment. These extensions are necessary when application= s > impose stringent requirements in terms of delay. Notions of localization = and > distribution of local agents have been introduced to reduce signalling > overhead. Unfortunately today we witness difficulties in getting such > protocols deployed, often leading to sub-optimal choices. Moreover, all t= he > availability of multi-mode devices and the possibility to use several > network interfaces simultaneously have motivated the development of more = new > protocol extensions. > > Mobile users are, more than ever, consuming Internet content, and impose = new > requirements on mobile core networks for data traffic delivery. When this > traffic demand exceeds available capacity, service providers need to > implement new strategies such as selective traffic offload (e.g. 3GPP wor= k > items LIPA/SIPTO) through alternative access networks (e.g. WLAN). Moreov= er, > the localization of content providers closer to the Mobile/Fixed Internet > Service Providers network requires taking into account local Content > Delivery Networks (CDNs) while providing mobility services. > > As long as demand exceeds capacity, both offloading and CDN techniques co= uld > benefit from the development of more flat mobile architectures (i.e., few= er > levels of routing hierarchy introduced into the data path by the mobility > management system). This view is reinforced by the shift in users' traffi= c > behaviour, aimed at increasing direct communications among peers in the s= ame > geographical area. The development of truly flat mobile architectures wou= ld > result in anchoring the traffic closer to point of attachment of the user > and overcoming the suboptimal routing issues of a centralized mobility > scheme. > > While deploying today's mobile networks, service providers face new > challenges. More often than not, mobile devices remain attached to the sa= me > point of attachment, in which case specific IP mobility management suppor= t > is not required for applications that launch and complete while connected= to > the same point of attachment. However, the mobility support has been > designed to be always on and to maintain the context for each mobile > subscriber as long as they are connected to the network. This can result = in > a waste of resources and ever-increasing costs for the service provider. > Infrequent mobility and intelligence of many applications suggest that > mobility can be provided dynamically, thus simplifying the context > maintained in the different nodes of the mobile network. > > The proposed charter will address two complementary aspects of mobility > management procedures: the distribution of mobility anchors to achieve a > more flat design and the dynamic activation/deactivation of mobility > protocol support as an enabler to distributed mobility management. The > former has the goal of positioning mobility anchors (HA, LMA) closer to t= he > user; ideally, these mobility anchors could be collocated with the first = hop > router. The latter, facilitated by the distribution of mobility anchors, > aims at identifying when mobility must be activated and identifying sessi= ons > that do not impose mobility management -- thus reducing the amount of sta= te > information to be maintained in the various mobility anchors of the mobil= e > network. The key idea is that dynamic mobility management relaxes some > constraints while also repositioning mobility anchors; it avoids the > establishment of non optimal tunnels between two anchors topologically > distant. > > Considering the above, the working group will: > > Define the problem statement and associated requirements for distributed > mobility management. This work aims at defining the problem space and > identifies the key functional requirements. > > Produce a gap analysis mapping the above requirements against existing > solutions. > > Give best practices for the deployment of existing mobility protocols in = a > distributed mobility management and describe limitations of each such > approach. > > Describe extensions, if needed, to current mobility protocols for their > application in distributed mobility architectures > > > Comments? > > Jari > > --=20 ------ Best Regards, Dapeng Liu From charles.perkins@earthlink.net Fri Nov 4 10:05:43 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6004921F8C5C for ; Fri, 4 Nov 2011 10:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.393 X-Spam-Level: X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=0.206, 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 UUN57MnmFykP for ; Fri, 4 Nov 2011 10:05:43 -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 6582621F8C58 for ; Fri, 4 Nov 2011 10:05:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=hYGeZJ979feqa2tBlJHf6vZPpIk97Btuo80VrZK+zkLu8QQSQ3t4yxWv7vPugmOB; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [138.111.58.2] (helo=[172.17.96.136]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1RMND3-0000YP-Da; Fri, 04 Nov 2011 13:05:41 -0400 Message-ID: <4EB41B60.90105@earthlink.net> Date: Fri, 04 Nov 2011 10:05:36 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: sarikaya@ieee.org References: <4EB2D421.4030905@earthlink.net><1672201A-C652-4204-99D9-3DE4D23D2BB2@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86c49200b6689bc8aaef5f97bee3c996a4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Cc: mext@ietf.org, Behcet Sarikaya Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 17:05:43 -0000 Hello Behcet, On 11/4/2011 9:18 AM, Behcet Sarikaya wrote: > I am confused about all these very high level, intelligent looking > comments, and I must say I am fed up with them :-). - I'm guessing you don't wish to restrict to only stupid comments. - Do you mean that only low-level comments are of interest? That doesn't seem appropriate in response to the proposal to shut down the working group...? > Non-tunneled communications is already there in DMM. You connect to the > nearest HA and all new communications is non-tunneled. That doesn't provide IP address continuity, does it? > Do we agree that we should differentiate client-based and network based > protocols and discuss them in different places? If I understand your point, this is the status quo, right? > or even there is no issue for one. I did not understand the point of that. > I think this is what we should decide now. I'm not sure what "this" means in your sentence. Regards, Charlie P. From charles.perkins@earthlink.net Fri Nov 4 10:15:59 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB7721F8C91 for ; Fri, 4 Nov 2011 10:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 W3UNv0d9sphJ for ; Fri, 4 Nov 2011 10:15:58 -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 A113B1F0C34 for ; Fri, 4 Nov 2011 10:15:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=andtbCI97bub2ljqb4/W4xOpgyKISKi1EKH+ZJ3k77iGBFQ7iF4/0TG9R0ra2Dsh; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [138.111.58.2] (helo=[172.17.96.136]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1RMNMz-0008QG-J6; Fri, 04 Nov 2011 13:15:58 -0400 Message-ID: <4EB41DC5.1010409@earthlink.net> Date: Fri, 04 Nov 2011 10:15:49 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: <350CD199-C70E-491B-B81D-AFE1D3F95C05@nokia.com> In-Reply-To: <350CD199-C70E-491B-B81D-AFE1D3F95C05@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86f064a93ef503bb074f97e5d8524a8996350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Cc: mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 17:15:59 -0000 Hello Basavaraj, Comments inline: On 11/4/2011 9:05 AM, Basavaraj.Patil@nokia.com wrote: > Unless you can make a clear and definitive case that the current LTE > solution does not work or scale or inefficient in terms of performance > or otherwise, it is difficult to bring about change. Even with a clear case, it will be difficult to bring about change. > Complexity has > its own benefits.. Its just a matter of who the beneficiaries are Why don't we start from designing for the beneficiaries to be the end users? Every strategy has beneficiaries, but yours is in no way a useful criterion for design. Elminating electronic communications and commerce would have very many beneficiaries, as just one example. Enabling high-speed smooth handovers between heterogeneous radio technologies would benefit some people more than others. I'll be very surprised if [mext] explicitly aims to protect complexity on the basis of your argument. > Hence claiming complexity as the reason to consider alternatives is > an uphill task. If this complexity becomes an issue in terms of interop, > CAPEX/OPEX costs etc. that may trigger a revisit to the architecture. What about the points I already cited: > Taking a look at S101 and S103, we can immediately > recognize that they are drastically more complicated, > restrictive, and operationally more expensive than > Mobile IP. Taking a look at S102, we immediately see > that 3GPP mobility management threatens to be different > for each class of application, with an unnecessary > per-application proliferation of servers, protocol, > permissions, traffic controls, configuration, and so on. > Taking a look at recent efforts towards WiFi offload, > we see the same trend of complication and software > hacks that could be avoided with proper IETF > approaches. ... and ... > .......... if we don't take action, we are > choosing a future that is ever more complicated, > non-extendible, non-flexible, radio technology > specific, application specific, and bug-ridden. > In short, everything we don't want the Internet > to be. Do you disagree with _any_ of my claims above? Regards, Charlie P. >> -----Original Message----- >> From: "Charles E. Perkins" >> Organization: Wichorus Inc. >> Date: Thu, 03 Nov 2011 10:49:21 -0700 >> To: Jari Arkko >> Cc:, >> Subject: Re: [MEXT] the future of the MEXT working group >> >>> Hello folks, >>> >>> For several years now, I have been studying 4G wireless >>> network architecture and wondering why there is such a >>> disconnect between, say, LTE mobility management and >>> IETF mobility management. Mobile IP has a secondary >>> role, to say the least. IETF approaches may be seen to >>> have several inadequacies, and 3GPP approaches also show >>> some major problems. I think that it is important for >>> the IETF to devote some serious effort towards bringing >>> these two worlds together, because current directions >>> are leading towards an impossibly baroque, wasteful, >>> nearly impenetrable mess of complication. The effects >>> overall is loss of performance and opportunity. >>> >>> Taking a look at S101 and S103, we can immediately >>> recognize that they are drastically more complicated, >>> restrictive, and operationally more expensive than >>> Mobile IP. Taking a look at S102, we immediately see >>> that 3GPP mobility management threatens to be different >>> for each class of application, with an unnecessary >>> per-application proliferation of servers, protocol, >>> permissions, traffic controls, configuration, and so on. >>> Taking a look at recent efforts towards WiFi offload, >>> we see the same trend of complication and software >>> hacks that could be avoided with proper IETF >>> approaches. >>> >>> On the IETF side, we should specify: >>> - Integrated authentication for access control >>> as well as IP address continuity >>> - Location-assisted handovers (think MIIS / ANDSF) >>> - Modular/alternative security >>> - Signaling on control plane, user traffic on >>> data plane >>> - Alternative tunneling (GTP is simply not going >>> to die a quick death, to say the least) >>> - geez, the list does go on, but no one reads >>> long lists ... >>> ... >>> >>> I don't know if we already have 3GPP liaison, but >>> if we do the communication channels don't seem to >>> have had very much effect within the [mext] work >>> lately. >>> >>> My fear is that if we don't take action, we are >>> choosing a future that is ever more complicated, >>> non-extendible, non-flexible, radio technology >>> specific, application specific, and bug-ridden. >>> In short, everything we don't want the Internet >>> to be. And, I am sure no one here doubts that >>> the Internet of the future is all high-speed >>> wireless. Where is the IETF going to be? >>> >>> If the [mext] working group is shut down, there >>> is no natural place for this work to happen. >>> Therefore, I hope that [mext] would NOT shut >>> down, and instead recharter to tackle these >>> urgent problems. >>> >>> Regards, >>> Charlie P. >>> >>> >>> >>> On 10/28/2011 5:08 AM, Jari Arkko wrote: >>>> All, >>>> >>>> We are making some changes to the working group. While we have >>>> successfully published a large number of specifications in recent years, >>>> recently it has been difficult to make progress in the group. The chairs >>>> and ADs have looked at the situation and we believe we need a new focus >>>> and a bit of new organization as well. We are terminating the working >>>> group and moving the one remaining active work item to a new working >>>> group, the "DMM" working group. Here's what is going to happen: >>>> >>>> o Jouni Korhonen and Julien Laganier will become the chairs of the >>>> group. >>>> >>>> o The group will meet in Taipei (there is a MEXT slot in the agenda). >>>> >>>> o The charter of the group will be changed to focus only on the >>>> distributed mobility effort. We should discuss the details of this >>>> charter change both on the list and in the meeting. The meeting agenda >>>> should reserve some time both for technical discussions as well as the >>>> charter discussion. >>>> >>>> o Once the discussion on the list and in the meeting has finished, we >>>> will rename the group to "DMM" and put the new charter in effect. >>>> >>>> o If there are any other specifications that people would like to >>>> publish beyond the distributed mobility work, we can offer to AD sponsor >>>> them to RFCs outside the new working group. If there is some significant >>>> new activity, we can create new working groups for that. >>>> >>>> Comments and feedback and/or alternate suggestions on this plan are >>>> welcome. >>>> >>>> We would like to thank Marcelo for your many years of service in MEXT. >>>> We could not have completed all the work we did without your energy and >>>> push for high quality results. We would also like to thank Jouni for >>>> taking on this new challenge, and Julien for continuing the work in this >>>> space. >>>> >>>> Jari and Ralph >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > From charles.perkins@earthlink.net Fri Nov 4 10:31:46 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DAD321F8A97 for ; Fri, 4 Nov 2011 10:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 f4vKVPKuy+kU for ; Fri, 4 Nov 2011 10:31:46 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id E876221F8A71 for ; Fri, 4 Nov 2011 10:31:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=N8E8cYZ69ZZeEVwQNf/gzsv7DLq+FRNwZBylWE78r/cLOaZ1rEvISM9R+KjUIYQ9; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [138.111.58.2] (helo=[172.17.96.136]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1RMNcE-0000Uo-WA; Fri, 04 Nov 2011 13:31:43 -0400 Message-ID: <4EB4217A.8040109@earthlink.net> Date: Fri, 04 Nov 2011 10:31:38 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: jouni korhonen References: <4EAA9B4A.3020208@piuha.net> <4EAA9E34.2080903@piuha.net> <1B31D76B-4C76-4351-B270-437D4560007C@gmail.com> In-Reply-To: <1B31D76B-4C76-4351-B270-437D4560007C@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad866f7ad810b1c8adc933d4ae9af7a27d3d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Cc: mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 17:31:46 -0000 Hello Jouni, Comments inline: On 11/3/2011 5:21 PM, jouni korhonen wrote: > Few quick comments. I would remove all explicit references to 3GPP and > existing offload mechanisms therein. FWIW this WG is not supposed to > be a stub of SA2. The possible (protocol) enhancement must be generic > enough to be applicable outside of a specific deployment architecture. I agree 100%. I use 3GPP as an example. However, it is a likely bet that a huge fraction of the mobile devices in the future will implement wireless connectivity specified by 3GPP and depend upon network backhaul specified by 3GPP, so it is pretty relevant to consider the design needs specifically of 3GPP -- if nothing else, then at least as a reality check. > Also, I think we ought not only consider just mobility enhancement. > More efficient use of CoA(s) for direct/local/non-tunneled communication > along with existing mobility solutions should be in scope as well. Again, agree 100%. However, we might eventually determine that the methods for efficient use of CoA(s) are somewhat different than the methods for enabling IP address continuity and smooth handover. I wonder whether the two different technologies would even belong in the same working group. Before enabling a mechanism to select a CoA, we need some way for classifying the "characteristics" of an IP address as bound to a specific radio interface and Internet PoA. To me, it's not at all obvious that such a problem is "like" the other problems of interest within the Internet Area. Regards, Charlie P. From Basavaraj.Patil@nokia.com Fri Nov 4 11:06:18 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE16611E808E for ; Fri, 4 Nov 2011 11:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.024 X-Spam-Level: X-Spam-Status: No, score=-103.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 hk4J46YbZ2YM for ; Fri, 4 Nov 2011 11:06:17 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6D11911E807F for ; Fri, 4 Nov 2011 11:06:17 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pA4I6EES005346; Fri, 4 Nov 2011 20:06:15 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Nov 2011 20:06:09 +0200 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.235]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.01.0339.002; Fri, 4 Nov 2011 19:06:08 +0100 From: To: Thread-Topic: [MEXT] the future of the MEXT working group Thread-Index: AQHMlWpmfRWG/cEPIEyACm1+ri2dNZWbZjyAgABzzgCAAQGEgIAAE6WAgAAODwA= Date: Fri, 4 Nov 2011 18:06:08 +0000 Message-ID: References: <350CD199-C70E-491B-B81D-AFE1D3F95C05@nokia.com> <4EB41DC5.1010409@earthlink.net> In-Reply-To: <4EB41DC5.1010409@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.74.219.186] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Nov 2011 18:06:09.0945 (UTC) FILETIME=[6E567090:01CC9B1C] X-Nokia-AV: Clean Cc: mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 18:06:18 -0000 Hi Charlie, On Nov 4, 2011, at 12:15 PM, ext Charles E. Perkins wrote: > Hello Basavaraj, >=20 > Comments inline: >=20 > On 11/4/2011 9:05 AM, Basavaraj.Patil@nokia.com wrote: >=20 >> Unless you can make a clear and definitive case that the current LTE >> solution does not work or scale or inefficient in terms of performance >> or otherwise, it is difficult to bring about change. >=20 > Even with a clear case, it will be difficult to bring > about change. No doubt=85 But at least there is some reasoning/justification that one can= consider. >=20 >> Complexity has >> its own benefits.. Its just a matter of who the beneficiaries are >=20 > Why don't we start from designing for the beneficiaries to be > the end users? Every strategy has beneficiaries, but yours is > in no way a useful criterion for design. Elminating electronic > communications and commerce would have very many beneficiaries, > as just one example. Enabling high-speed smooth handovers > between heterogeneous radio technologies would benefit some > people more than others. I'll be very surprised if [mext] > explicitly aims to protect complexity on the basis of your > argument. I do agree that a simpler approach would have many beneficiaries including = end users. End users are happy with the status quo. Handovers across heterogeneous acc= ess technologies is a nice feature. But is not critical if the session can = be continued on the currently attached network. Applications are evolving s= uch that they can handle change in access network connectivity. A small set= of applications currently need the type of seamless mobility and handovers= that Mobile IP provides. But that advantage and benefit is waning IMHO. >=20 >> Hence claiming complexity as the reason to consider alternatives is >> an uphill task. If this complexity becomes an issue in terms of interop, >> CAPEX/OPEX costs etc. that may trigger a revisit to the architecture. >=20 > What about the points I already cited: >=20 >> Taking a look at S101 and S103, we can immediately >> recognize that they are drastically more complicated, >> restrictive, and operationally more expensive than >> Mobile IP. Taking a look at S102, we immediately see >> that 3GPP mobility management threatens to be different >> for each class of application, with an unnecessary >> per-application proliferation of servers, protocol, >> permissions, traffic controls, configuration, and so on. >> Taking a look at recent efforts towards WiFi offload, >> we see the same trend of complication and software >> hacks that could be avoided with proper IETF >> approaches. >=20 > ... and ... >=20 >> .......... if we don't take action, we are >> choosing a future that is ever more complicated, >> non-extendible, non-flexible, radio technology >> specific, application specific, and bug-ridden. >> In short, everything we don't want the Internet >> to be. >=20 >=20 > Do you disagree with _any_ of my claims above? I dont disagree with your points above and I guess having a document which = illustrates how a Mobile IP based approach can dramatically simplify the in= terfaces and complexity would be useful. But then again maybe the requireme= nts are such that any attempt to meet those with Mobile IP and IETF protoco= ls would result in an equivalently complex system. I don't know.. But thats= a possibility.=20 You could also view a future where the complexity of the architecture is ov= erwhelming enough to cause its own demise.=20 -Basavaraj >=20 > Regards, > Charlie P. >=20 >=20 >=20 >=20 >>> -----Original Message----- >>> From: "Charles E. Perkins" >>> Organization: Wichorus Inc. >>> Date: Thu, 03 Nov 2011 10:49:21 -0700 >>> To: Jari Arkko >>> Cc:, >>> Subject: Re: [MEXT] the future of the MEXT working group >>>=20 >>>> Hello folks, >>>>=20 >>>> For several years now, I have been studying 4G wireless >>>> network architecture and wondering why there is such a >>>> disconnect between, say, LTE mobility management and >>>> IETF mobility management. Mobile IP has a secondary >>>> role, to say the least. IETF approaches may be seen to >>>> have several inadequacies, and 3GPP approaches also show >>>> some major problems. I think that it is important for >>>> the IETF to devote some serious effort towards bringing >>>> these two worlds together, because current directions >>>> are leading towards an impossibly baroque, wasteful, >>>> nearly impenetrable mess of complication. The effects >>>> overall is loss of performance and opportunity. >>>>=20 >>>> Taking a look at S101 and S103, we can immediately >>>> recognize that they are drastically more complicated, >>>> restrictive, and operationally more expensive than >>>> Mobile IP. Taking a look at S102, we immediately see >>>> that 3GPP mobility management threatens to be different >>>> for each class of application, with an unnecessary >>>> per-application proliferation of servers, protocol, >>>> permissions, traffic controls, configuration, and so on. >>>> Taking a look at recent efforts towards WiFi offload, >>>> we see the same trend of complication and software >>>> hacks that could be avoided with proper IETF >>>> approaches. >>>>=20 >>>> On the IETF side, we should specify: >>>> - Integrated authentication for access control >>>> as well as IP address continuity >>>> - Location-assisted handovers (think MIIS / ANDSF) >>>> - Modular/alternative security >>>> - Signaling on control plane, user traffic on >>>> data plane >>>> - Alternative tunneling (GTP is simply not going >>>> to die a quick death, to say the least) >>>> - geez, the list does go on, but no one reads >>>> long lists ... >>>> ... >>>>=20 >>>> I don't know if we already have 3GPP liaison, but >>>> if we do the communication channels don't seem to >>>> have had very much effect within the [mext] work >>>> lately. >>>>=20 >>>> My fear is that if we don't take action, we are >>>> choosing a future that is ever more complicated, >>>> non-extendible, non-flexible, radio technology >>>> specific, application specific, and bug-ridden. >>>> In short, everything we don't want the Internet >>>> to be. And, I am sure no one here doubts that >>>> the Internet of the future is all high-speed >>>> wireless. Where is the IETF going to be? >>>>=20 >>>> If the [mext] working group is shut down, there >>>> is no natural place for this work to happen. >>>> Therefore, I hope that [mext] would NOT shut >>>> down, and instead recharter to tackle these >>>> urgent problems. >>>>=20 >>>> Regards, >>>> Charlie P. >>>>=20 >>>>=20 >>>>=20 >>>> On 10/28/2011 5:08 AM, Jari Arkko wrote: >>>>> All, >>>>>=20 >>>>> We are making some changes to the working group. While we have >>>>> successfully published a large number of specifications in recent yea= rs, >>>>> recently it has been difficult to make progress in the group. The cha= irs >>>>> and ADs have looked at the situation and we believe we need a new foc= us >>>>> and a bit of new organization as well. We are terminating the working >>>>> group and moving the one remaining active work item to a new working >>>>> group, the "DMM" working group. Here's what is going to happen: >>>>>=20 >>>>> o Jouni Korhonen and Julien Laganier will become the chairs of the >>>>> group. >>>>>=20 >>>>> o The group will meet in Taipei (there is a MEXT slot in the agenda). >>>>>=20 >>>>> o The charter of the group will be changed to focus only on the >>>>> distributed mobility effort. We should discuss the details of this >>>>> charter change both on the list and in the meeting. The meeting agend= a >>>>> should reserve some time both for technical discussions as well as th= e >>>>> charter discussion. >>>>>=20 >>>>> o Once the discussion on the list and in the meeting has finished, we >>>>> will rename the group to "DMM" and put the new charter in effect. >>>>>=20 >>>>> o If there are any other specifications that people would like to >>>>> publish beyond the distributed mobility work, we can offer to AD spon= sor >>>>> them to RFCs outside the new working group. If there is some signific= ant >>>>> new activity, we can create new working groups for that. >>>>>=20 >>>>> Comments and feedback and/or alternate suggestions on this plan are >>>>> welcome. >>>>>=20 >>>>> We would like to thank Marcelo for your many years of service in MEXT= . >>>>> We could not have completed all the work we did without your energy a= nd >>>>> push for high quality results. We would also like to thank Jouni for >>>>> taking on this new challenge, and Julien for continuing the work in t= his >>>>> space. >>>>>=20 >>>>> Jari and Ralph >>>>>=20 >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>=20 >>>=20 >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>=20 >>=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From hesham@elevatemobile.com Fri Nov 4 16:05:42 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B051F0C35 for ; Fri, 4 Nov 2011 16:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.158, 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 cVL13yB3MTNa for ; Fri, 4 Nov 2011 16:05:41 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id B4B5D1F0C3B for ; Fri, 4 Nov 2011 16:05:34 -0700 (PDT) Received: from [60.242.128.199] (helo=[192.168.0.2]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1RMSon-0003pC-SY; Sat, 05 Nov 2011 10:05:03 +1100 User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Sat, 05 Nov 2011 10:04:49 +1100 From: Hesham Soliman To: Message-ID: Thread-Topic: [MEXT] the future of the MEXT working group In-Reply-To: <350CD199-C70E-491B-B81D-AFE1D3F95C05@nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: jouni.korhonen@nsn.com, jari.arkko@piuha.net, mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 23:05:42 -0000 > > > >On Nov 3, 2011, at 7:43 PM, ext Hesham Soliman wrote: > >> Hi Charlie, >> >> I agree completely with you on the problems with the current interfaces >>in >> LTE, and in 3G before that. >> I don't know what the best way to go about it would be. I say this >>because >> many people on this list are aware of what's happening in LTE and >> presumably have similar opinions about the complexity of their >>solutions, >> but it's still there. >> > >Unless you can make a clear and definitive case that the current LTE >solution does not work or scale or inefficient in terms of performance or >otherwise, it is difficult to bring about change. Complexity has its own >benefits.. Its just a matter of who the beneficiaries are :) >Hence claiming complexity as the reason to consider alternatives is an >uphill task. If this complexity becomes an issue in terms of interop, >CAPEX/OPEX costs etc. that may trigger a revisit to the architecture. => Right, I think OPEX is the key issue here. The CAPEX argument is subjective and speculative but OPEX differences are a bit easier to show. Hesham > > >-Raj > > >> Hesham >> >> -----Original Message----- >> From: "Charles E. Perkins" >> Organization: Wichorus Inc. >> Date: Thu, 03 Nov 2011 10:49:21 -0700 >> To: Jari Arkko >> Cc: , >> Subject: Re: [MEXT] the future of the MEXT working group >> >>> Hello folks, >>> >>> For several years now, I have been studying 4G wireless >>> network architecture and wondering why there is such a >>> disconnect between, say, LTE mobility management and >>> IETF mobility management. Mobile IP has a secondary >>> role, to say the least. IETF approaches may be seen to >>> have several inadequacies, and 3GPP approaches also show >>> some major problems. I think that it is important for >>> the IETF to devote some serious effort towards bringing >>> these two worlds together, because current directions >>> are leading towards an impossibly baroque, wasteful, >>> nearly impenetrable mess of complication. The effects >>> overall is loss of performance and opportunity. >>> >>> Taking a look at S101 and S103, we can immediately >>> recognize that they are drastically more complicated, >>> restrictive, and operationally more expensive than >>> Mobile IP. Taking a look at S102, we immediately see >>> that 3GPP mobility management threatens to be different >>> for each class of application, with an unnecessary >>> per-application proliferation of servers, protocol, >>> permissions, traffic controls, configuration, and so on. >>> Taking a look at recent efforts towards WiFi offload, >>> we see the same trend of complication and software >>> hacks that could be avoided with proper IETF >>> approaches. >>> >>> On the IETF side, we should specify: >>> - Integrated authentication for access control >>> as well as IP address continuity >>> - Location-assisted handovers (think MIIS / ANDSF) >>> - Modular/alternative security >>> - Signaling on control plane, user traffic on >>> data plane >>> - Alternative tunneling (GTP is simply not going >>> to die a quick death, to say the least) >>> - geez, the list does go on, but no one reads >>> long lists ... >>> ... >>> >>> I don't know if we already have 3GPP liaison, but >>> if we do the communication channels don't seem to >>> have had very much effect within the [mext] work >>> lately. >>> >>> My fear is that if we don't take action, we are >>> choosing a future that is ever more complicated, >>> non-extendible, non-flexible, radio technology >>> specific, application specific, and bug-ridden. >>> In short, everything we don't want the Internet >>> to be. And, I am sure no one here doubts that >>> the Internet of the future is all high-speed >>> wireless. Where is the IETF going to be? >>> >>> If the [mext] working group is shut down, there >>> is no natural place for this work to happen. >>> Therefore, I hope that [mext] would NOT shut >>> down, and instead recharter to tackle these >>> urgent problems. >>> >>> Regards, >>> Charlie P. >>> >>> >>> >>> On 10/28/2011 5:08 AM, Jari Arkko wrote: >>>> All, >>>> >>>> We are making some changes to the working group. While we have >>>> successfully published a large number of specifications in recent >>>>years, >>>> recently it has been difficult to make progress in the group. The >>>>chairs >>>> and ADs have looked at the situation and we believe we need a new >>>>focus >>>> and a bit of new organization as well. We are terminating the working >>>> group and moving the one remaining active work item to a new working >>>> group, the "DMM" working group. Here's what is going to happen: >>>> >>>> o Jouni Korhonen and Julien Laganier will become the chairs of the >>>> group. >>>> >>>> o The group will meet in Taipei (there is a MEXT slot in the agenda). >>>> >>>> o The charter of the group will be changed to focus only on the >>>> distributed mobility effort. We should discuss the details of this >>>> charter change both on the list and in the meeting. The meeting agenda >>>> should reserve some time both for technical discussions as well as the >>>> charter discussion. >>>> >>>> o Once the discussion on the list and in the meeting has finished, we >>>> will rename the group to "DMM" and put the new charter in effect. >>>> >>>> o If there are any other specifications that people would like to >>>> publish beyond the distributed mobility work, we can offer to AD >>>>sponsor >>>> them to RFCs outside the new working group. If there is some >>>>significant >>>> new activity, we can create new working groups for that. >>>> >>>> Comments and feedback and/or alternate suggestions on this plan are >>>> welcome. >>>> >>>> We would like to thank Marcelo for your many years of service in MEXT. >>>> We could not have completed all the work we did without your energy >>>>and >>>> push for high quality results. We would also like to thank Jouni for >>>> taking on this new challenge, and Julien for continuing the work in >>>>this >>>> space. >>>> >>>> Jari and Ralph >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > From mccap@petoni.org Fri Nov 4 20:15:32 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8115B21F8ABE for ; Fri, 4 Nov 2011 20:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.86 X-Spam-Level: X-Spam-Status: No, score=-2.86 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 AbUrMLhEQlCk for ; Fri, 4 Nov 2011 20:15:31 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id CBF7821F8ABC for ; Fri, 4 Nov 2011 20:15:31 -0700 (PDT) Received: by ggnv1 with SMTP id v1so3616212ggn.31 for ; Fri, 04 Nov 2011 20:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=petoni.org; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qTHYIWxlmTc9kqVEbrtiUhtVMDcAG8YV+M+swsN59o4=; b=OXn4Mh+hkH+d5m7Ux8fNlZSNtmZYGVxjqOZFiwD5eM1d0zTyG5mCbNO1HosfJIFcnZ Cqy7boXgNYag0M9L0NMSnK+c9wvR9ODhy+4X5cV0Hl0nlprCUK/YwuJhcuDN4VhjwFyA X2CR9bqYHiPCv85NA9xcaUQ4qOBeuwTV7y2V8= MIME-Version: 1.0 Received: by 10.182.17.103 with SMTP id n7mr3567014obd.68.1320462931220; Fri, 04 Nov 2011 20:15:31 -0700 (PDT) Received: by 10.182.192.38 with HTTP; Fri, 4 Nov 2011 20:15:31 -0700 (PDT) X-Originating-IP: [68.45.157.93] In-Reply-To: References: <350CD199-C70E-491B-B81D-AFE1D3F95C05@nokia.com> <4EB41DC5.1010409@earthlink.net> Date: Fri, 4 Nov 2011 23:15:31 -0400 Message-ID: From: Pete McCann To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Cc: mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 03:15:32 -0000 On Fri, Nov 4, 2011 at 2:06 PM, wrote: > > Applications are evolving such that they can handle change in access network > connectivity. A small set of applications currently need the type of seamless > mobility and handovers that Mobile IP provides. But that advantage and benefit > is waning IMHO. The same argument could be applied to the GPRS architecture. Gluing additional access technologies to the P-GW with GTP tunnels is completely unnecessary. > I dont disagree with your points above and I guess having a document which > illustrates how a Mobile IP based approach can dramatically simplify the interfaces > and complexity would be useful. But then again maybe the requirements are such > that any attempt to meet those with Mobile IP and IETF protocols would result in > an equivalently complex system. I don't know.. But thats a possibility. We should definitely not try to replicate GPRS with Mobile IP. I think the point of this discussion is that some of the requirements (like IP address continuity throughout all space and time) that drove the existing architecture need to be relaxed. > You could also view a future where the complexity of the architecture is > overwhelming enough to cause its own demise. I think we may be close to that point already. -Pete From jouni.nospam@gmail.com Sun Nov 6 12:32:31 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6563C21F85CE for ; Sun, 6 Nov 2011 12:32:31 -0800 (PST) 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 TNJRlEXyakyC for ; Sun, 6 Nov 2011 12:32:30 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A017C21F858D for ; Sun, 6 Nov 2011 12:32:29 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so3532442bkb.31 for ; Sun, 06 Nov 2011 12:32:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=aoWJzkJcJGjxQcux2Lf4GL5TTf0Dccd07MjWHo4mg8c=; b=C8evP5T14s1ez4tf+IKbp541AVrQYbMf+jESAM/huI4PYNxcq8D/HJbrXUnURZFCNk ThJepp3lvE7oucs2ThEIBK8XPEdD4S8iAXJmsz0BjKr2tM1H63Q+gIeGSwsmufDKFeob 8sRHKzB+nukU5E1gFm+OCWarqmF3junc7FVSU= Received: by 10.204.140.129 with SMTP id i1mr17282023bku.19.1320611547161; Sun, 06 Nov 2011 12:32:27 -0800 (PST) Received: from [188.117.15.102] ([188.117.15.102]) by mx.google.com with ESMTPS id b20sm11338865bkr.11.2011.11.06.12.32.24 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 06 Nov 2011 12:32:24 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Sun, 6 Nov 2011 22:32:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EB2D421.4030905@earthlink.net> <1672201A-C652-4204-99D9-3DE4D23D2BB2@gmail.com> To: mext@ietf.org X-Mailer: Apple Mail (2.1084) Cc: Jouni Korhonen , Jari Arkko Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2011 20:32:31 -0000 On Nov 4, 2011, at 6:18 PM, Behcet Sarikaya wrote: > Hi all, >=20 > I am confused about all these very high level, intelligent looking = comments, and I must say I am fed up with them :-). >=20 > Non-tunneled communications is already there in DMM. You connect to = the nearest HA and all new communications is non-tunneled. >=20 > Do we agree that we should differentiate client-based and network = based protocols and discuss them in different places? or even there is = no issue for one. IMHO I see no reason to focus only on client-based or network-based = solutions. FWIW the DMM solution space: o is incremental to an existing IETF mobility protocol, be that client-, network- or even transport-based. o or alternatively may not depend on a specific mobility protocol at all i.e. non-anchored solution is also in scope. o solution is backward compatible in a sense that if a host or a network does not support DMM, nothing breaks. o focuses on IPv6 because anything IPv4 is just NAT-games. - Jouni >=20 > I think this is what we should decide now. >=20 > Regards, >=20 > Behcet >=20 > On Fri, Nov 4, 2011 at 3:19 AM, jouni korhonen = wrote: > Pete, >=20 > On Nov 4, 2011, at 3:16 AM, Pete McCann wrote: >=20 > > A good architecture is made not only from deciding what to = standardize but > > also from what not to standardize. >=20 > Exactly. >=20 > [snip] >=20 > > > > Perhaps IETF could take LIPA as a starting point to design a cleaner > > mobility management solution. >=20 > What came out from a certain SDO as a "Local IP Access" did not turn = out as the most elegant solution :) But I do agree that from the idea & = initial use case point of view, it definitely is something to look at.. = even as a basis for a cleaner design. >=20 > > It isn't clear to me that we should even start with tunnels as a = basic building > > block. >=20 > I am along the same lines. See my earlier mail on the charter = http://www.ietf.org/mail-archive/web/mext/current/msg04905.html >=20 > - Jouni >=20 >=20 >=20 > > > > -Pete > > > > On Thu, Nov 3, 2011 at 8:43 PM, Hesham Soliman = wrote: > >> Hi Charlie, > >> > >> I agree completely with you on the problems with the current = interfaces in > >> LTE, and in 3G before that. > >> I don't know what the best way to go about it would be. I say this = because > >> many people on this list are aware of what's happening in LTE and > >> presumably have similar opinions about the complexity of their = solutions, > >> but it's still there. > >> > >> Hesham > >> > >> -----Original Message----- > >> From: "Charles E. Perkins" > >> Organization: Wichorus Inc. > >> Date: Thu, 03 Nov 2011 10:49:21 -0700 > >> To: Jari Arkko > >> Cc: , > >> Subject: Re: [MEXT] the future of the MEXT working group > >> > >>> Hello folks, > >>> > >>> For several years now, I have been studying 4G wireless >=20 > [snap] >=20 >=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext >=20 From alexandru.petrescu@gmail.com Mon Nov 7 05:06:30 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA3421F8AEC for ; Mon, 7 Nov 2011 05:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.261 X-Spam-Level: X-Spam-Status: No, score=-6.261 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] 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 vwv6B0P30flY for ; Mon, 7 Nov 2011 05:06:26 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id CB67C21F8AC3 for ; Mon, 7 Nov 2011 05:06:25 -0800 (PST) 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.2) with ESMTP id pA7D6OeK020216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 7 Nov 2011 14:06:24 +0100 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 pA7D6N8k030600 for ; Mon, 7 Nov 2011 14:06:23 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id pA7D6Heq002869 for ; Mon, 7 Nov 2011 14:06:23 +0100 Message-ID: <4EB7D7C9.3040303@gmail.com> Date: Mon, 07 Nov 2011 14:06:17 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: mext@ietf.org References: <4EAA9B4A.3020208@piuha.net> In-Reply-To: <4EAA9B4A.3020208@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MEXT] automotive reqs WG item (was: the future of the MEXT working group) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 13:06:30 -0000 Hello Jari, WG members, Le 28/10/2011 14:08, Jari Arkko a écrit : > All, > > We are making some changes to the working group. While we have > successfully published a large number of specifications in recent > years, recently it has been difficult to make progress in the group. > The chairs and ADs have looked at the situation and we believe we > need a new focus and a bit of new organization as well. We are > terminating the working group and moving the one remaining active > work item to a new working group, the "DMM" working group. Here's > what is going to happen: > > o Jouni Korhonen and Julien Laganier will become the chairs of the > group. > > o The group will meet in Taipei (there is a MEXT slot in the > agenda). > > o The charter of the group will be changed to focus only on the > distributed mobility effort. We should discuss the details of this > charter change both on the list and in the meeting. The meeting > agenda should reserve some time both for technical discussions as > well as the charter discussion. > > o Once the discussion on the list and in the meeting has finished, > we will rename the group to "DMM" and put the new charter in effect. > > o If there are any other specifications that people would like to > publish beyond the distributed mobility work, we can offer to AD > sponsor them to RFCs outside the new working group. I wonder what is the plan about draft-ietf-mext-nemo-ro-automotive-req-02? "Automotive Industry Requirements for NEMO Route Optimization" http://tools.ietf.org/html/draft-ietf-mext-nemo-ro-automotive-req-02 I can see a number of options to move it forward, like for example: - change in authorship, title. - continue as part of new Charter (fulfill earlier objectives) or sponsor separately per your offer. - change in focus. What do you think? Alex > If there is some significant new activity, we can create new working > groups for that. > > Comments and feedback and/or alternate suggestions on this plan are > welcome. > > We would like to thank Marcelo for your many years of service in > MEXT. We could not have completed all the work we did without your > energy and push for high quality results. We would also like to > thank Jouni for taking on this new challenge, and Julien for > continuing the work in this space. > > Jari and Ralph > > _______________________________________________ MEXT mailing list > MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > From thierry.ernst@inria.fr Mon Nov 7 05:16:55 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F6821F8B33 for ; Mon, 7 Nov 2011 05:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.022 X-Spam-Level: X-Spam-Status: No, score=-10.022 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] 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 MqiwRPji3vOZ for ; Mon, 7 Nov 2011 05:16:51 -0800 (PST) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id AB69621F854E for ; Mon, 7 Nov 2011 05:16:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.69,470,1315173600"; d="vcf'?scan'208";a="128942171" Received: from dhcp-rocq-215.inria.fr ([128.93.62.215]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 07 Nov 2011 14:16:48 +0100 Message-ID: <4EB7DA40.3080807@inria.fr> Date: Mon, 07 Nov 2011 14:16:48 +0100 From: Thierry Ernst Organization: INRIA User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: mext@ietf.org References: <4EAA9B4A.3020208@piuha.net> <4EB7D7C9.3040303@gmail.com> In-Reply-To: <4EB7D7C9.3040303@gmail.com> Content-Type: multipart/mixed; boundary="------------060805070507030504090006" Subject: Re: [MEXT] automotive reqs WG item X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 13:16:55 -0000 This is a multi-part message in MIME format. --------------060805070507030504090006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Thanks Alex for raising this. My view on this is that the automotive industry has some needs that are partly related to NEMO RO, but not only related to NEMO. So, I would like to seek advice from our AD about where would be the best place at the IETF to discuss automotive requirements related to IPv6 ? Regarding the dratf itself, it is our intention to update it. Regards, Thierry On 07/11/11 14:06, Alexandru Petrescu wrote: > Hello Jari, WG members, > > > Le 28/10/2011 14:08, Jari Arkko a écrit : >> All, >> >> We are making some changes to the working group. While we have >> successfully published a large number of specifications in recent >> years, recently it has been difficult to make progress in the group. >> The chairs and ADs have looked at the situation and we believe we >> need a new focus and a bit of new organization as well. We are >> terminating the working group and moving the one remaining active >> work item to a new working group, the "DMM" working group. Here's >> what is going to happen: >> >> o Jouni Korhonen and Julien Laganier will become the chairs of the >> group. >> >> o The group will meet in Taipei (there is a MEXT slot in the >> agenda). >> >> o The charter of the group will be changed to focus only on the >> distributed mobility effort. We should discuss the details of this >> charter change both on the list and in the meeting. The meeting >> agenda should reserve some time both for technical discussions as >> well as the charter discussion. >> >> o Once the discussion on the list and in the meeting has finished, >> we will rename the group to "DMM" and put the new charter in effect. >> >> o If there are any other specifications that people would like to >> publish beyond the distributed mobility work, we can offer to AD >> sponsor them to RFCs outside the new working group. > > I wonder what is the plan about > draft-ietf-mext-nemo-ro-automotive-req-02? "Automotive Industry > Requirements for NEMO Route Optimization" > http://tools.ietf.org/html/draft-ietf-mext-nemo-ro-automotive-req-02 > > I can see a number of options to move it forward, like for example: > - change in authorship, title. > - continue as part of new Charter (fulfill earlier objectives) or > sponsor separately per your offer. > - change in focus. > > What do you think? > > Alex > >> If there is some significant new activity, we can create new working >> groups for that. > > >> >> Comments and feedback and/or alternate suggestions on this plan are >> welcome. >> >> We would like to thank Marcelo for your many years of service in >> MEXT. We could not have completed all the work we did without your >> energy and push for high quality results. We would also like to >> thank Jouni for taking on this new challenge, and Julien for >> continuing the work in this space. >> >> Jari and Ralph >> >> _______________________________________________ MEXT mailing list >> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext >> > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext --------------060805070507030504090006 Content-Type: text/x-vcard; charset=utf-8; name="thierry_ernst.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="thierry_ernst.vcf" begin:vcard fn:Thierry Ernst n:Ernst;Thierry org:INRIA - Project Team IMARA - LaRA JRU tel;work:+33 1 3963 59 30 tel;fax:+33 1 39 63 54 91 tel;cell:+33 6 76 56 25 96 url:http://www.lara.prd.fr version:2.1 end:vcard --------------060805070507030504090006-- From alexandru.petrescu@gmail.com Mon Nov 7 06:47:40 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333E821F8B3F for ; Mon, 7 Nov 2011 06:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.234 X-Spam-Level: X-Spam-Status: No, score=-6.234 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] 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 QiP5sOC2vdvc for ; Mon, 7 Nov 2011 06:47:36 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id 13DE321F8B14 for ; Mon, 7 Nov 2011 06:47:35 -0800 (PST) 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.2) with ESMTP id pA7ElYuU023552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 7 Nov 2011 15:47:34 +0100 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 pA7ElYOg016088 for ; Mon, 7 Nov 2011 15:47:34 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id pA7ElUYI031338 for ; Mon, 7 Nov 2011 15:47:34 +0100 Message-ID: <4EB7EF82.9090701@gmail.com> Date: Mon, 07 Nov 2011 15:47:30 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: mext@ietf.org References: <4EAA9B4A.3020208@piuha.net> <4EB7D7C9.3040303@gmail.com> <4EB7DA40.3080807@inria.fr> In-Reply-To: <4EB7DA40.3080807@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MEXT] automotive reqs WG item X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 14:47:40 -0000 Le 07/11/2011 14:16, Thierry Ernst a écrit : > > Thanks Alex for raising this. > > My view on this is that the automotive industry has some needs that > are partly related to NEMO RO, but not only related to NEMO. I agree. That's why its title could change (dont use "ro" in title nor filename). The contents of the draft as of now already include a number of use cases which do not necessarily need RO. Some NEMO wording could be softened, to present it as an alternative not necessarily _the_ solution. Additionally, a number of discussions happened in 2011 on IETF email lists (mext, 6man) which relate to automotive requirements and IPv6. How about adding VIN and ULA text into it? > So, I would like to seek advice from our AD about where would be the > best place at the IETF to discuss automotive requirements related to > IPv6 ? I am also interested to learn where else have automotive discussions happened at IETF, other than 6MAN and MEXT. VIN, March 2011: http://www.ietf.org/mail-archive/web/ipv6/current/msg13729.html ULA, September 2011: http://www.ietf.org/mail-archive/web/ipv6/current/msg14715.html > Regarding the dratf itself, it is our intention to update it. Good to know. Alex > > Regards, Thierry > > > > > > > On 07/11/11 14:06, Alexandru Petrescu wrote: >> Hello Jari, WG members, >> >> >> Le 28/10/2011 14:08, Jari Arkko a écrit : >>> All, >>> >>> We are making some changes to the working group. While we have >>> successfully published a large number of specifications in >>> recent years, recently it has been difficult to make progress in >>> the group. The chairs and ADs have looked at the situation and we >>> believe we need a new focus and a bit of new organization as >>> well. We are terminating the working group and moving the one >>> remaining active work item to a new working group, the "DMM" >>> working group. Here's what is going to happen: >>> >>> o Jouni Korhonen and Julien Laganier will become the chairs of >>> the group. >>> >>> o The group will meet in Taipei (there is a MEXT slot in the >>> agenda). >>> >>> o The charter of the group will be changed to focus only on the >>> distributed mobility effort. We should discuss the details of >>> this charter change both on the list and in the meeting. The >>> meeting agenda should reserve some time both for technical >>> discussions as well as the charter discussion. >>> >>> o Once the discussion on the list and in the meeting has >>> finished, we will rename the group to "DMM" and put the new >>> charter in effect. >>> >>> o If there are any other specifications that people would like >>> to publish beyond the distributed mobility work, we can offer to >>> AD sponsor them to RFCs outside the new working group. >> >> I wonder what is the plan about >> draft-ietf-mext-nemo-ro-automotive-req-02? "Automotive Industry >> Requirements for NEMO Route Optimization" >> http://tools.ietf.org/html/draft-ietf-mext-nemo-ro-automotive-req-02 >> >> >> I can see a number of options to move it forward, like for example: >> - change in authorship, title. - continue as part of new Charter >> (fulfill earlier objectives) or sponsor separately per your offer. >> - change in focus. >> >> What do you think? >> >> Alex >> >>> If there is some significant new activity, we can create new >>> working groups for that. >> >> >>> >>> Comments and feedback and/or alternate suggestions on this plan >>> are welcome. >>> >>> We would like to thank Marcelo for your many years of service in >>> MEXT. We could not have completed all the work we did without >>> your energy and push for high quality results. We would also like >>> to thank Jouni for taking on this new challenge, and Julien for >>> continuing the work in this space. >>> >>> Jari and Ralph >>> >>> _______________________________________________ MEXT mailing >>> list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext >>> >> >> >> _______________________________________________ MEXT mailing list >> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > > > > _______________________________________________ MEXT mailing list > MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From pierrick.seite@orange.com Mon Nov 7 06:53:24 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C8821F8B70 for ; Mon, 7 Nov 2011 06:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 PsQYsOHRvzoh for ; Mon, 7 Nov 2011 06:53:24 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0D021F8B6F for ; Mon, 7 Nov 2011 06:53:24 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 59EAE40001; Mon, 7 Nov 2011 15:53:23 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 4DE05FCC003; Mon, 7 Nov 2011 15:53:23 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Nov 2011 15:53:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Nov 2011 15:53:22 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462020308E2@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] the future of the MEXT working group Thread-Index: AcycwzmMJXGjZWkmTf2zK4evFJc/xwAmTteQ References: <4EB2D421.4030905@earthlink.net><1672201A-C652-4204-99D9-3DE4D23D2BB2@gmail.com> From: To: , X-OriginalArrivalTime: 07 Nov 2011 14:53:23.0375 (UTC) FILETIME=[FF5D2BF0:01CC9D5C] Cc: jouni.korhonen@nsn.com, jari.arkko@piuha.net Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 14:53:24 -0000 I agree with this scope. Pierrick >=20 > IMHO I see no reason to focus only on client-based or network-based > solutions. FWIW the DMM solution space: >=20 > o is incremental to an existing IETF mobility protocol, be that client-, > network- or even transport-based. > o or alternatively may not depend on a specific mobility protocol at all > i.e. non-anchored solution is also in scope. > o solution is backward compatible in a sense that if a host or a network > does not support DMM, nothing breaks. > o focuses on IPv6 because anything IPv4 is just NAT-games. >=20 > - Jouni >=20 From karagian@cs.utwente.nl Mon Nov 7 07:57:53 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16CA521F8AC9 for ; Mon, 7 Nov 2011 07:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=-2.113, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SARE_SUB_OBFU_Q1=0.227] 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 CqjkKY2pu6tL for ; Mon, 7 Nov 2011 07:57:52 -0800 (PST) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2620921F89BA for ; Mon, 7 Nov 2011 07:57:52 -0800 (PST) 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.1.323.3; Mon, 7 Nov 2011 16:52:07 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.58]) by EXHUB01.ad.utwente.nl ([fe80::200:5efe:130.89.4.228%12]) with mapi id 14.01.0323.003; Mon, 7 Nov 2011 16:52:04 +0100 From: To: , Thread-Topic: [MEXT] automotive reqs WG item Thread-Index: AQHMnU+LpgPh6JdNH0ai4mFC5mfMF5WhjvZA Date: Mon, 7 Nov 2011 15:52:04 +0000 Message-ID: References: <4EAA9B4A.3020208@piuha.net> <4EB7D7C9.3040303@gmail.com> <4EB7DA40.3080807@inria.fr> In-Reply-To: <4EB7DA40.3080807@inria.fr> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.89.12.129] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MEXT] automotive reqs WG item X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 15:57:53 -0000 Hi all, I agree with Alex and Thierry on this issue! Where is the best place at the IETF to discuss and work out automotive requ= irements? Best regards, Georgios > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Thierry Ernst > Sent: maandag 7 november 2011 14:17 > To: mext@ietf.org > Subject: Re: [MEXT] automotive reqs WG item >=20 >=20 > Thanks Alex for raising this. >=20 > My view on this is that the automotive industry has some needs that are > partly related to NEMO RO, but not only related to NEMO. >=20 > So, I would like to seek advice from our AD about where would be the best > place at the IETF to discuss automotive requirements related to IPv6 ? >=20 > Regarding the dratf itself, it is our intention to update it. >=20 > Regards, > Thierry >=20 >=20 >=20 >=20 >=20 >=20 > On 07/11/11 14:06, Alexandru Petrescu wrote: > > Hello Jari, WG members, > > > > > > Le 28/10/2011 14:08, Jari Arkko a =E9crit : > >> All, > >> > >> We are making some changes to the working group. While we have > >> successfully published a large number of specifications in recent > >> years, recently it has been difficult to make progress in the group. > >> The chairs and ADs have looked at the situation and we believe we > >> need a new focus and a bit of new organization as well. We are > >> terminating the working group and moving the one remaining active > >> work item to a new working group, the "DMM" working group. Here's > >> what is going to happen: > >> > >> o Jouni Korhonen and Julien Laganier will become the chairs of the > >> group. > >> > >> o The group will meet in Taipei (there is a MEXT slot in the agenda). > >> > >> o The charter of the group will be changed to focus only on the > >> distributed mobility effort. We should discuss the details of this > >> charter change both on the list and in the meeting. The meeting > >> agenda should reserve some time both for technical discussions as > >> well as the charter discussion. > >> > >> o Once the discussion on the list and in the meeting has finished, we > >> will rename the group to "DMM" and put the new charter in effect. > >> > >> o If there are any other specifications that people would like to > >> publish beyond the distributed mobility work, we can offer to AD > >> sponsor them to RFCs outside the new working group. > > > > I wonder what is the plan about > > draft-ietf-mext-nemo-ro-automotive-req-02? "Automotive Industry > > Requirements for NEMO Route Optimization" > > http://tools.ietf.org/html/draft-ietf-mext-nemo-ro-automotive-req-02 > > > > I can see a number of options to move it forward, like for example: > > - change in authorship, title. > > - continue as part of new Charter (fulfill earlier objectives) or > > sponsor separately per your offer. > > - change in focus. > > > > What do you think? > > > > Alex > > > >> If there is some significant new activity, we can create new working > >> groups for that. > > > > > >> > >> Comments and feedback and/or alternate suggestions on this plan are > >> welcome. > >> > >> We would like to thank Marcelo for your many years of service in > >> MEXT. We could not have completed all the work we did without your > >> energy and push for high quality results. We would also like to thank > >> Jouni for taking on this new challenge, and Julien for continuing the > >> work in this space. > >> > >> Jari and Ralph > >> > >> _______________________________________________ MEXT > mailing list > >> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > >> > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext From Dirk.von-Hugo@telekom.de Mon Nov 7 08:41:42 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B21421F89BA for ; Mon, 7 Nov 2011 08:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_SUB_OBFU_Q1=0.227] 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 nU64Fo0qbyul for ; Mon, 7 Nov 2011 08:41:41 -0800 (PST) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4AE21F849D for ; Mon, 7 Nov 2011 08:41:41 -0800 (PST) Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 07 Nov 2011 17:41:12 +0100 Received: from HE113484.emea1.cds.t-internal.com ([169.254.4.57]) by he110890 ([10.134.92.131]) with mapi; Mon, 7 Nov 2011 17:41:12 +0100 From: To: , , Date: Mon, 7 Nov 2011 17:41:11 +0100 Thread-Topic: [MEXT] automotive reqs WG item Thread-Index: AQHMnU+LpgPh6JdNH0ai4mFC5mfMF5WhjvZAgAANrBA= Message-ID: <05C81A773E48DD49B181B04BA21A342A267664CB53@HE113484.emea1.cds.t-internal.com> References: <4EAA9B4A.3020208@piuha.net> <4EB7D7C9.3040303@gmail.com> <4EB7DA40.3080807@inria.fr> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mobopts@irtf.org Subject: Re: [MEXT] automotive reqs WG item X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 16:41:42 -0000 Dear all, I agree with the importance of the topic and remember that at least in the = mobopts session the charter of which should be under discussion/revision th= is topic was also mentioned ... Would that work - or is the intention more on vehicular engineering rather = than research topics? Regards Dirk -----Urspr=FCngliche Nachricht----- Von: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] Im Auftrag von ka= ragian@cs.utwente.nl Gesendet: Montag, 7. November 2011 16:52 An: thierry.ernst@inria.fr; mext@ietf.org Betreff: Re: [MEXT] automotive reqs WG item Hi all, I agree with Alex and Thierry on this issue! Where is the best place at the IETF to discuss and work out automotive requ= irements? Best regards, Georgios > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of > Thierry Ernst > Sent: maandag 7 november 2011 14:17 > To: mext@ietf.org > Subject: Re: [MEXT] automotive reqs WG item > > > Thanks Alex for raising this. > > My view on this is that the automotive industry has some needs that are > partly related to NEMO RO, but not only related to NEMO. > > So, I would like to seek advice from our AD about where would be the best > place at the IETF to discuss automotive requirements related to IPv6 ? > > Regarding the dratf itself, it is our intention to update it. > > Regards, > Thierry > > > > > > > On 07/11/11 14:06, Alexandru Petrescu wrote: > > Hello Jari, WG members, > > > > > > Le 28/10/2011 14:08, Jari Arkko a =E9crit : > >> All, > >> > >> We are making some changes to the working group. While we have > >> successfully published a large number of specifications in recent > >> years, recently it has been difficult to make progress in the group. > >> The chairs and ADs have looked at the situation and we believe we > >> need a new focus and a bit of new organization as well. We are > >> terminating the working group and moving the one remaining active > >> work item to a new working group, the "DMM" working group. Here's > >> what is going to happen: > >> > >> o Jouni Korhonen and Julien Laganier will become the chairs of the > >> group. > >> > >> o The group will meet in Taipei (there is a MEXT slot in the agenda). > >> > >> o The charter of the group will be changed to focus only on the > >> distributed mobility effort. We should discuss the details of this > >> charter change both on the list and in the meeting. The meeting > >> agenda should reserve some time both for technical discussions as > >> well as the charter discussion. > >> > >> o Once the discussion on the list and in the meeting has finished, we > >> will rename the group to "DMM" and put the new charter in effect. > >> > >> o If there are any other specifications that people would like to > >> publish beyond the distributed mobility work, we can offer to AD > >> sponsor them to RFCs outside the new working group. > > > > I wonder what is the plan about > > draft-ietf-mext-nemo-ro-automotive-req-02? "Automotive Industry > > Requirements for NEMO Route Optimization" > > http://tools.ietf.org/html/draft-ietf-mext-nemo-ro-automotive-req-02 > > > > I can see a number of options to move it forward, like for example: > > - change in authorship, title. > > - continue as part of new Charter (fulfill earlier objectives) or > > sponsor separately per your offer. > > - change in focus. > > > > What do you think? > > > > Alex > > > >> If there is some significant new activity, we can create new working > >> groups for that. > > > > > >> > >> Comments and feedback and/or alternate suggestions on this plan are > >> welcome. > >> > >> We would like to thank Marcelo for your many years of service in > >> MEXT. We could not have completed all the work we did without your > >> energy and push for high quality results. We would also like to thank > >> Jouni for taking on this new challenge, and Julien for continuing the > >> work in this space. > >> > >> Jari and Ralph > >> > >> _______________________________________________ MEXT > mailing list > >> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > >> > > > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From jouni.nospam@gmail.com Mon Nov 7 08:51:06 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA66E21F8C5B for ; Mon, 7 Nov 2011 08:51:06 -0800 (PST) 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 oftSu4sCPJoP for ; Mon, 7 Nov 2011 08:51:06 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id E715721F8C52 for ; Mon, 7 Nov 2011 08:51:05 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so4320368bkb.31 for ; Mon, 07 Nov 2011 08:51:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=zX2nfFLkmhRHOrCVo3ZqJqgXnWBVjUy0Mn+kcK+LWCo=; b=ZvnujQXMs90wk2JbUxs+DhvnL72TXR+OvUh22a3xD7MuHB28VRFB416i9i6aDSAEdo JwBvhkv/VQa/1dbQVBfzHRS1KPFhvojyD0q4zR2za/EghaFp5YqCLzgQ2LdPPsuIoHRG 6Bdx4ZzeL4msdgpjLrLXF2nEWv4P2sQ/FA2H4= Received: by 10.205.114.65 with SMTP id ez1mr19685767bkc.99.1320684663678; Mon, 07 Nov 2011 08:51:03 -0800 (PST) Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPS id q6sm6268975bka.6.2011.11.07.08.51.02 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Nov 2011 08:51:03 -0800 (PST) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Nov 2011 18:51:01 +0200 Message-Id: <5B30E08E-48B7-4188-AA90-E58AE90985D3@gmail.com> To: mext@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [MEXT] IETF82 - session administrivia X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 16:51:06 -0000 Folks, For our forthcoming meeting we need a note taker or two, and a jabber = scribe. Feel free to volunteer as there really is not much time to waste = on the usual note taker and jabber scribe "call". Just drop a mail to = chairs. - Jouni & Julien= From Basavaraj.Patil@nokia.com Mon Nov 7 12:06:27 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7599C21F8472 for ; Mon, 7 Nov 2011 12:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 J5H5CdizUIQq for ; Mon, 7 Nov 2011 12:06:26 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 94DE521F846D for ; Mon, 7 Nov 2011 12:06:26 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pA7K6FVT019377; Mon, 7 Nov 2011 22:06:16 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Nov 2011 22:06:11 +0200 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by 008-AM1MMR1-012.mgdnok.nokia.com (65.54.30.21) with Microsoft SMTP Server (TLS) id 14.1.339.2; Mon, 7 Nov 2011 21:06:10 +0100 Received: from 008-AM1MPN1-071.mgdnok.nokia.com ([169.254.1.235]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0339.002; Mon, 7 Nov 2011 21:06:10 +0100 From: To: , , Thread-Topic: [MEXT] automotive reqs WG item Thread-Index: AQHMnU+Nqxf5P6XWiE2/GoZVRFZNtJWhfwEA///RrQA= Date: Mon, 7 Nov 2011 20:06:09 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.33] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Nov 2011 20:06:11.0545 (UTC) FILETIME=[B210A490:01CC9D88] X-Nokia-AV: Clean Subject: Re: [MEXT] automotive reqs WG item X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 20:06:27 -0000 On 11/7/11 9:52 AM, "ext karagian@cs.utwente.nl" wrote: >Hi all, > >I agree with Alex and Thierry on this issue! >Where is the best place at the IETF to discuss and work out automotive >requirements? Maybe it would be worthwhile to organize a BoF and consider the potential for a separate WG since the automotive requirements are not just mobility related. -Raj > >Best regards, >Georgios > >> -----Original Message----- >> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of >> Thierry Ernst >> Sent: maandag 7 november 2011 14:17 >> To: mext@ietf.org >> Subject: Re: [MEXT] automotive reqs WG item >>=20 >>=20 >> Thanks Alex for raising this. >>=20 >> My view on this is that the automotive industry has some needs that are >> partly related to NEMO RO, but not only related to NEMO. >>=20 >> So, I would like to seek advice from our AD about where would be the >>best >> place at the IETF to discuss automotive requirements related to IPv6 ? >>=20 >> Regarding the dratf itself, it is our intention to update it. >>=20 >> Regards, >> Thierry >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 07/11/11 14:06, Alexandru Petrescu wrote: >> > Hello Jari, WG members, >> > >> > >> > Le 28/10/2011 14:08, Jari Arkko a =E9crit : >> >> All, >> >> >> >> We are making some changes to the working group. While we have >> >> successfully published a large number of specifications in recent >> >> years, recently it has been difficult to make progress in the group. >> >> The chairs and ADs have looked at the situation and we believe we >> >> need a new focus and a bit of new organization as well. We are >> >> terminating the working group and moving the one remaining active >> >> work item to a new working group, the "DMM" working group. Here's >> >> what is going to happen: >> >> >> >> o Jouni Korhonen and Julien Laganier will become the chairs of the >> >> group. >> >> >> >> o The group will meet in Taipei (there is a MEXT slot in the agenda). >> >> >> >> o The charter of the group will be changed to focus only on the >> >> distributed mobility effort. We should discuss the details of this >> >> charter change both on the list and in the meeting. The meeting >> >> agenda should reserve some time both for technical discussions as >> >> well as the charter discussion. >> >> >> >> o Once the discussion on the list and in the meeting has finished, we >> >> will rename the group to "DMM" and put the new charter in effect. >> >> >> >> o If there are any other specifications that people would like to >> >> publish beyond the distributed mobility work, we can offer to AD >> >> sponsor them to RFCs outside the new working group. >> > >> > I wonder what is the plan about >> > draft-ietf-mext-nemo-ro-automotive-req-02? "Automotive Industry >> > Requirements for NEMO Route Optimization" >> > http://tools.ietf.org/html/draft-ietf-mext-nemo-ro-automotive-req-02 >> > >> > I can see a number of options to move it forward, like for example: >> > - change in authorship, title. >> > - continue as part of new Charter (fulfill earlier objectives) or >> > sponsor separately per your offer. >> > - change in focus. >> > >> > What do you think? >> > >> > Alex >> > >> >> If there is some significant new activity, we can create new working >> >> groups for that. >> > >> > >> >> >> >> Comments and feedback and/or alternate suggestions on this plan are >> >> welcome. >> >> >> >> We would like to thank Marcelo for your many years of service in >> >> MEXT. We could not have completed all the work we did without your >> >> energy and push for high quality results. We would also like to thank >> >> Jouni for taking on this new challenge, and Julien for continuing the >> >> work in this space. >> >> >> >> Jari and Ralph >> >> >> >> _______________________________________________ MEXT >> mailing list >> >> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext >> >> >> > >> > >> > _______________________________________________ >> > MEXT mailing list >> > MEXT@ietf.org >> > https://www.ietf.org/mailman/listinfo/mext > >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www.ietf.org/mailman/listinfo/mext From charles.perkins@earthlink.net Mon Nov 7 12:43:03 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4515411E80D2 for ; Mon, 7 Nov 2011 12:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 4kQky7Sbtvpg for ; Mon, 7 Nov 2011 12:43:02 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 62E0711E80A6 for ; Mon, 7 Nov 2011 12:43:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Vj401QqF2ARIWrRevBfyNoe0vApLCE2/jyj6mWibpjvjsR2WnLAqei3P0fJwApKu; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [138.111.58.2] (helo=[172.17.96.136]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1RNW1z-0005Nx-Dw; Mon, 07 Nov 2011 15:42:59 -0500 Message-ID: <4EB842CE.5090202@earthlink.net> Date: Mon, 07 Nov 2011 12:42:54 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8604b48cbb0eb47f4864f28d83afca0ab2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Cc: mext@ietf.org Subject: Re: [MEXT] automotive reqs WG item X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 20:43:03 -0000 Hello Raj, Not disagreeing that a BOF would be useful, but I'm wondering whether the requirements as laid out in the expired Internet Draft would fit in a single working group. The distinction between IP-based and C2C-CC-based applications would probably need a very contentious BOF, just on that single issue. There have been so many failed proposals to replace TCP, that it's hard to avoid skepticism for this one. Anyway, I'd have more confidence that a BOF which was restricted to just the mobility part of the problem might get some useful results. Regards, Charlie P. On 11/7/2011 12:06 PM, Basavaraj.Patil@nokia.com wrote: > > > On 11/7/11 9:52 AM, "ext karagian@cs.utwente.nl" > wrote: > >> Hi all, >> >> I agree with Alex and Thierry on this issue! >> Where is the best place at the IETF to discuss and work out automotive >> requirements? > > Maybe it would be worthwhile to organize a BoF and consider the potential > for a separate WG since the automotive requirements are not just mobility > related. > > -Raj > >> >> Best regards, >> Georgios >> >>> -----Original Message----- >>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of >>> Thierry Ernst >>> Sent: maandag 7 november 2011 14:17 >>> To: mext@ietf.org >>> Subject: Re: [MEXT] automotive reqs WG item >>> >>> >>> Thanks Alex for raising this. >>> >>> My view on this is that the automotive industry has some needs that are >>> partly related to NEMO RO, but not only related to NEMO. >>> >>> So, I would like to seek advice from our AD about where would be the >>> best >>> place at the IETF to discuss automotive requirements related to IPv6 ? >>> >>> Regarding the dratf itself, it is our intention to update it. >>> >>> Regards, >>> Thierry >>> >>> >>> >>> >>> >>> >>> On 07/11/11 14:06, Alexandru Petrescu wrote: >>>> Hello Jari, WG members, >>>> >>>> >>>> Le 28/10/2011 14:08, Jari Arkko a écrit : >>>>> All, >>>>> >>>>> We are making some changes to the working group. While we have >>>>> successfully published a large number of specifications in recent >>>>> years, recently it has been difficult to make progress in the group. >>>>> The chairs and ADs have looked at the situation and we believe we >>>>> need a new focus and a bit of new organization as well. We are >>>>> terminating the working group and moving the one remaining active >>>>> work item to a new working group, the "DMM" working group. Here's >>>>> what is going to happen: >>>>> >>>>> o Jouni Korhonen and Julien Laganier will become the chairs of the >>>>> group. >>>>> >>>>> o The group will meet in Taipei (there is a MEXT slot in the agenda). >>>>> >>>>> o The charter of the group will be changed to focus only on the >>>>> distributed mobility effort. We should discuss the details of this >>>>> charter change both on the list and in the meeting. The meeting >>>>> agenda should reserve some time both for technical discussions as >>>>> well as the charter discussion. >>>>> >>>>> o Once the discussion on the list and in the meeting has finished, we >>>>> will rename the group to "DMM" and put the new charter in effect. >>>>> >>>>> o If there are any other specifications that people would like to >>>>> publish beyond the distributed mobility work, we can offer to AD >>>>> sponsor them to RFCs outside the new working group. >>>> >>>> I wonder what is the plan about >>>> draft-ietf-mext-nemo-ro-automotive-req-02? "Automotive Industry >>>> Requirements for NEMO Route Optimization" >>>> http://tools.ietf.org/html/draft-ietf-mext-nemo-ro-automotive-req-02 >>>> >>>> I can see a number of options to move it forward, like for example: >>>> - change in authorship, title. >>>> - continue as part of new Charter (fulfill earlier objectives) or >>>> sponsor separately per your offer. >>>> - change in focus. >>>> >>>> What do you think? >>>> >>>> Alex >>>> >>>>> If there is some significant new activity, we can create new working >>>>> groups for that. >>>> >>>> >>>>> >>>>> Comments and feedback and/or alternate suggestions on this plan are >>>>> welcome. >>>>> >>>>> We would like to thank Marcelo for your many years of service in >>>>> MEXT. We could not have completed all the work we did without your >>>>> energy and push for high quality results. We would also like to thank >>>>> Jouni for taking on this new challenge, and Julien for continuing the >>>>> work in this space. >>>>> >>>>> Jari and Ralph >>>>> >>>>> _______________________________________________ MEXT >>> mailing list >>>>> MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext >>>>> >>>> >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From yokota@kddilabs.jp Thu Nov 10 04:41:50 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C080E21F84FA for ; Thu, 10 Nov 2011 04:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJKKQ0suFiSk for ; Thu, 10 Nov 2011 04:41:49 -0800 (PST) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id A6F6521F84D4 for ; Thu, 10 Nov 2011 04:41:46 -0800 (PST) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 1EFEC1748153 for ; Thu, 10 Nov 2011 21:41:46 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIBIv8HjPDKI for ; Thu, 10 Nov 2011 21:41:45 +0900 (JST) Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 34AF7174814B for ; Thu, 10 Nov 2011 21:41:45 +0900 (JST) Received: from [127.0.0.1] (unknown [10.8.0.6]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id C440A1B9AB for ; Thu, 10 Nov 2011 21:40:59 +0900 (JST) Message-ID: <4EBBC682.7070101@kddilabs.jp> Date: Thu, 10 Nov 2011 21:41:38 +0900 From: Hidetoshi Yokota User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mext@ietf.org References: <350CD199-C70E-491B-B81D-AFE1D3F95C05@nokia.com> <4EB41DC5.1010409@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 12:41:50 -0000 Hi, I think that the point is to give a choice to the network and user if mobility is needed or not. Some applications benefit from seamless mobility (e.g., VoIP), but others may not (e.g., Web access). The network and user should be able to specify the capability of mobility and appropriate access network for each application. In that sense, Dynamic MM is an interesting feature. I agree that the current 3GPP architecture is very complicated and may not be optimal, but I don't think it is a good idea to change it in IETF... Regards, -- Hidetoshi (2011/11/05 12:15), Pete McCann wrote: > On Fri, Nov 4, 2011 at 2:06 PM, wrote: >> >> Applications are evolving such that they can handle change in access network >> connectivity. A small set of applications currently need the type of seamless >> mobility and handovers that Mobile IP provides. But that advantage and benefit >> is waning IMHO. > > The same argument could be applied to the GPRS architecture. Gluing > additional access technologies to the P-GW with GTP tunnels is completely > unnecessary. > >> I dont disagree with your points above and I guess having a document which >> illustrates how a Mobile IP based approach can dramatically simplify the interfaces >> and complexity would be useful. But then again maybe the requirements are such >> that any attempt to meet those with Mobile IP and IETF protocols would result in >> an equivalently complex system. I don't know.. But thats a possibility. > > We should definitely not try to replicate GPRS with Mobile IP. I think the > point of this discussion is that some of the requirements (like IP address > continuity throughout all space and time) that drove the existing architecture > need to be relaxed. > >> You could also view a future where the complexity of the architecture is >> overwhelming enough to cause its own demise. > > I think we may be close to that point already. > > -Pete > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > > From charles.perkins@earthlink.net Thu Nov 10 13:42:25 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908C521F8484 for ; Thu, 10 Nov 2011 13:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTPb5l0U81oT for ; Thu, 10 Nov 2011 13:42:25 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD4C21F8486 for ; Thu, 10 Nov 2011 13:42:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=hb1UmzZLr081F58NT8UXTN8OWTJI9prp0l+SB34AJl8diafH7mvvQ2Cjd8bGkV+0; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [123.124.244.146] by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1ROcO5-0004Qe-Jn; Thu, 10 Nov 2011 16:42:22 -0500 Message-ID: <4EBC4537.7050501@earthlink.net> Date: Thu, 10 Nov 2011 13:42:15 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Hidetoshi Yokota References: <350CD199-C70E-491B-B81D-AFE1D3F95C05@nokia.com><4EB41DC5.1010409@earthlink.net> <4EBBC682.7070101@kddilabs.jp> In-Reply-To: <4EBBC682.7070101@kddilabs.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad868c4c8bd301d7b413b56f14bab15e6d82350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 123.124.244.146 Cc: mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 21:42:25 -0000 Hello Hidetoshi, On 11/10/2011 4:41 AM, Hidetoshi Yokota wrote: > Hi, > > I think that the point is to give a choice to the network and user if > mobility is needed or not. Some applications benefit from seamless > mobility (e.g., VoIP), but others may not (e.g., Web access). The > network and user should be able to specify the capability of mobility > and appropriate access network for each application. In that sense, > Dynamic MM is an interesting feature. I pretty much agree with this; I expect that working out the details will be pretty tedious and perhaps even contentious. > I agree that the current 3GPP architecture is very complicated and may > not be optimal, but I don't think it is a good idea to change it in IETF... I agree we can't "change" 3GPP architecture in the IETF, but we can respond to the needs which are evident from considering the 3GPP architecture. It seems very few believe that LTE is really immune from further evolution and even significant change in the future. If IETF does NOT respond to the needs made evident in current 3GPP specifications, we have little hope of proper integration into their future evolved designs. Regards, Charlie P. From yokota@kddilabs.jp Thu Nov 10 17:12:48 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1886E1F0C55 for ; Thu, 10 Nov 2011 17:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9f1zuRlwW1cu for ; Thu, 10 Nov 2011 17:12:47 -0800 (PST) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id A72291F0C3C for ; Thu, 10 Nov 2011 17:12:46 -0800 (PST) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id D10A2174810E; Fri, 11 Nov 2011 10:12:36 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9f71z8f+42sZ; Fri, 11 Nov 2011 10:12:36 +0900 (JST) Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 8922A17480AB; Fri, 11 Nov 2011 10:12:36 +0900 (JST) Received: from [127.0.0.1] (KOMOBILEX3.mn.mip.kddilabs.jp [172.19.90.26]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 96D911B9AB; Fri, 11 Nov 2011 10:11:50 +0900 (JST) Message-ID: <4EBC7681.8010203@kddilabs.jp> Date: Fri, 11 Nov 2011 10:12:33 +0900 From: Hidetoshi Yokota User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Charles E. Perkins" References: <350CD199-C70E-491B-B81D-AFE1D3F95C05@nokia.com><4EB41DC5.1010409@earthlink.net> <4EBBC682.7070101@kddilabs.jp> <4EBC4537.7050501@earthlink.net> In-Reply-To: <4EBC4537.7050501@earthlink.net> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 01:12:48 -0000 Hi Charlie, (2011/11/11 6:42), Charles E. Perkins wrote: > > Hello Hidetoshi, > > On 11/10/2011 4:41 AM, Hidetoshi Yokota wrote: >> Hi, >> >> I think that the point is to give a choice to the network and user if >> mobility is needed or not. Some applications benefit from seamless >> mobility (e.g., VoIP), but others may not (e.g., Web access). The >> network and user should be able to specify the capability of mobility >> and appropriate access network for each application. In that sense, >> Dynamic MM is an interesting feature. > > I pretty much agree with this; I expect that working out the > details will be pretty tedious and perhaps even contentious. > > >> I agree that the current 3GPP architecture is very complicated and may >> not be optimal, but I don't think it is a good idea to change it in >> IETF... > > I agree we can't "change" 3GPP architecture in the IETF, but > we can respond to the needs which are evident from considering > the 3GPP architecture. It seems very few believe that LTE > is really immune from further evolution and even significant > change in the future. If IETF does NOT respond to the needs made > evident in current 3GPP specifications, we have little hope of > proper integration into their future evolved designs. I fully agree with your point and am glad you initiated this discussion. One of the reasons for its complicatedness is that the 3GPP architecture has been incrementally built considering all the backward compatibility and interoperability along with introducing new features and minimizing the unhappiness of all. I respect this effort and achievement we all enjoy today. On the other hand, the current mobile traffic is way too much for this architecture to be able to handle. If IETF can contribute to tackling this issue toward the future evolved design, it will be very valuable. I don't know if DMM is the start point or we need a new WG, but we still have a high mountain to climb. Regards, -- Hidetoshi > Regards, > Charlie P. > > > From hesham@elevatemobile.com Thu Nov 10 18:29:38 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26B411E808F for ; Thu, 10 Nov 2011 18:29:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xhyp+UWnA72o for ; Thu, 10 Nov 2011 18:29:38 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 50B7B11E8080 for ; Thu, 10 Nov 2011 18:29:37 -0800 (PST) Received: from [120.146.201.23] (helo=[10.0.0.24]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1ROgrf-00056x-0s; Fri, 11 Nov 2011 13:29:11 +1100 User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Fri, 11 Nov 2011 13:28:55 +1100 From: Hesham Soliman To: "Charles E. Perkins" , Hidetoshi Yokota Message-ID: Thread-Topic: [MEXT] the future of the MEXT working group In-Reply-To: <4EBC4537.7050501@earthlink.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 02:29:38 -0000 Hi Charlie, >>I agree that the current 3GPP architecture is very complicated and may >> not be optimal, but I don't think it is a good idea to change it in >>IETF... > >I agree we can't "change" 3GPP architecture in the IETF, but >we can respond to the needs which are evident from considering >the 3GPP architecture. It seems very few believe that LTE >is really immune from further evolution and even significant >change in the future. If IETF does NOT respond to the needs made >evident in current 3GPP specifications, we have little hope of >proper integration into their future evolved designs. => I think we should all learn from the RFC 3314 experience where IETF (IPv6 WG at the time) made clear recommendations to 3GPP about address configuration and all the recommendations were adopted in the same release. I know these are smaller recommendations but this happens all the time and we shouldn't worry about achieving things before trying to get a unified view and presenting it. RFC 3316 is another example, although it was more of a consensus-based approach between the two organisations Hesham > >Regards, >Charlie P. >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www.ietf.org/mailman/listinfo/mext From jouni.nospam@gmail.com Sat Nov 12 16:06:14 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3530911E8085 for ; Sat, 12 Nov 2011 16:06:14 -0800 (PST) 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 cmkCWwYWdyJM for ; Sat, 12 Nov 2011 16:06:13 -0800 (PST) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBA411E8082 for ; Sat, 12 Nov 2011 16:06:13 -0800 (PST) Received: by pzk5 with SMTP id 5so5607019pzk.9 for ; Sat, 12 Nov 2011 16:06:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=RCJH2FEHxYLKJRkNeGByYFV22TTeW+ibKzQ/KOfqxZE=; b=XxR78r8VhpKvVhVbzWtYv/0mR94UGetAti7soz/qGeyNOlr+IOeML2d/OaHS0EtTpx LNjqsjnQC4hXilhVIeZBN1FyjO4JcydbNeyMlNJbHAELLUa5KIdVj9faiozpODlVW36u ZvdmSMK1/qM5k+NtuJJbBtqr48epol8dpGeqI= Received: by 10.68.30.129 with SMTP id s1mr36560354pbh.4.1321142771049; Sat, 12 Nov 2011 16:06:11 -0800 (PST) Received: from [192.168.0.15] (61-31-89-133.static.tfn.net.tw. [61.31.89.133]) by mx.google.com with ESMTPS id g8sm24653424pbe.11.2011.11.12.16.06.07 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 Nov 2011 16:06:10 -0800 (PST) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 13 Nov 2011 02:06:00 +0200 Message-Id: <4E87A903-3C6D-4921-9304-85E10202E6EA@gmail.com> To: Marco Liebsch , Carl Williams , luo.wen@zte.com.cn, Ji In Kim Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: mext@ietf.org Subject: [MEXT] note takers from MEXT session X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 00:06:14 -0000 Folks, Since the number of volunteers for note takers have been overwhelming, = we'll do the following. Everyone having a slot for presentation will = take notes that I can then merge to combined MEXT notes. Thank you in = advance to Marco, Carl, Wen and Ji-In. Jouni & Julien= From maxpassion@gmail.com Sun Nov 13 01:31:00 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9800421F8B5A for ; Sun, 13 Nov 2011 01:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.546 X-Spam-Level: X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 E3BrniOJgK8S for ; Sun, 13 Nov 2011 01:31:00 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E66EE21F8B58 for ; Sun, 13 Nov 2011 01:30:59 -0800 (PST) Received: by iaeo4 with SMTP id o4so7750637iae.31 for ; Sun, 13 Nov 2011 01:31:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B53TSUyR6PtTqOwQoL7dW70pSBFL0zi74kpYDyiO/hM=; b=K7K5lJQMT/ATBq/AZqPvgF/nbaAJtXUmZvlMFlGAowrANSSrAqZVAnqwNh01aO+tC+ p6WbGHjENLOtjO3Wm87UhTvY6f8xBz08Jq2Ws9M8HItYuQZEl+B/oHCdgft9TSI8iVuq BZohRulkCPx2SkvPCkwj7bMKw2lfMrB725bVA= MIME-Version: 1.0 Received: by 10.42.154.7 with SMTP id o7mr18626943icw.48.1321176660068; Sun, 13 Nov 2011 01:31:00 -0800 (PST) Received: by 10.42.228.68 with HTTP; Sun, 13 Nov 2011 01:30:59 -0800 (PST) In-Reply-To: References: <4EB2D421.4030905@earthlink.net> <1672201A-C652-4204-99D9-3DE4D23D2BB2@gmail.com> Date: Sun, 13 Nov 2011 17:30:59 +0800 Message-ID: From: liu dapeng To: jouni korhonen Content-Type: text/plain; charset=ISO-8859-1 Cc: Jouni Korhonen , Jari Arkko , mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 09:31:00 -0000 2011/11/7, jouni korhonen : > > On Nov 4, 2011, at 6:18 PM, Behcet Sarikaya wrote: > >> Hi all, >> >> I am confused about all these very high level, intelligent looking >> comments, and I must say I am fed up with them :-). >> >> Non-tunneled communications is already there in DMM. You connect to the >> nearest HA and all new communications is non-tunneled. >> >> Do we agree that we should differentiate client-based and network based >> protocols and discuss them in different places? or even there is no issue >> for one. > > > IMHO I see no reason to focus only on client-based or network-based > solutions. FWIW the DMM solution space: > > o is incremental to an existing IETF mobility protocol, be that client-, > network- or even transport-based. > o or alternatively may not depend on a specific mobility protocol at all > i.e. non-anchored solution is also in scope. > o solution is backward compatible in a sense that if a host or a network > does not support DMM, nothing breaks. > o focuses on IPv6 because anything IPv4 is just NAT-games. I have concern about only focuse on IPv6. IPv4 is still widely used today, we have to consider that. regards, Dapeng > - Jouni > >> >> I think this is what we should decide now. >> >> Regards, >> >> Behcet >> >> On Fri, Nov 4, 2011 at 3:19 AM, jouni korhonen >> wrote: >> Pete, >> >> On Nov 4, 2011, at 3:16 AM, Pete McCann wrote: >> >> > A good architecture is made not only from deciding what to standardize >> > but >> > also from what not to standardize. >> >> Exactly. >> >> [snip] >> >> > >> > Perhaps IETF could take LIPA as a starting point to design a cleaner >> > mobility management solution. >> >> What came out from a certain SDO as a "Local IP Access" did not turn out >> as the most elegant solution :) But I do agree that from the idea & >> initial use case point of view, it definitely is something to look at.. >> even as a basis for a cleaner design. >> >> > It isn't clear to me that we should even start with tunnels as a basic >> > building >> > block. >> >> I am along the same lines. See my earlier mail on the charter >> http://www.ietf.org/mail-archive/web/mext/current/msg04905.html >> >> - Jouni >> >> >> >> > >> > -Pete >> > >> > On Thu, Nov 3, 2011 at 8:43 PM, Hesham Soliman >> > wrote: >> >> Hi Charlie, >> >> >> >> I agree completely with you on the problems with the current interfaces >> >> in >> >> LTE, and in 3G before that. >> >> I don't know what the best way to go about it would be. I say this >> >> because >> >> many people on this list are aware of what's happening in LTE and >> >> presumably have similar opinions about the complexity of their >> >> solutions, >> >> but it's still there. >> >> >> >> Hesham >> >> >> >> -----Original Message----- >> >> From: "Charles E. Perkins" >> >> Organization: Wichorus Inc. >> >> Date: Thu, 03 Nov 2011 10:49:21 -0700 >> >> To: Jari Arkko >> >> Cc: , >> >> Subject: Re: [MEXT] the future of the MEXT working group >> >> >> >>> Hello folks, >> >>> >> >>> For several years now, I have been studying 4G wireless >> >> [snap] >> >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > -- ------ Best Regards, Dapeng Liu From maxpassion@gmail.com Sun Nov 13 01:56:51 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6348D21F8468 for ; Sun, 13 Nov 2011 01:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 XRyMqAzRIgw1 for ; Sun, 13 Nov 2011 01:56:50 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id CECFF21F8467 for ; Sun, 13 Nov 2011 01:56:50 -0800 (PST) Received: by iaeo4 with SMTP id o4so7775335iae.31 for ; Sun, 13 Nov 2011 01:56:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SK1EjnKmnrRbW62p1+50SUrt56kfhtMd+C4c41CtcRQ=; b=dRZ4RRVTj4UB8rCspDQpUFDld/jWnwWFc/bsbEA4cbd1ppSMgo6Wg6i5gJPBS6emuw YU/sTDvXQ+5hPtsfF2hBdfxb6JTyninYcMqArcKSpJ9aSD7zps1RwslyzLQBU9frc2fV Jyr80rd9E00W3Kg1bgNu1IHV1UQJjGb51ljWs= MIME-Version: 1.0 Received: by 10.42.117.193 with SMTP id u1mr18981872icq.24.1321178210950; Sun, 13 Nov 2011 01:56:50 -0800 (PST) Received: by 10.42.228.68 with HTTP; Sun, 13 Nov 2011 01:56:50 -0800 (PST) In-Reply-To: <4EBC7681.8010203@kddilabs.jp> References: <350CD199-C70E-491B-B81D-AFE1D3F95C05@nokia.com> <4EB41DC5.1010409@earthlink.net> <4EBBC682.7070101@kddilabs.jp> <4EBC4537.7050501@earthlink.net> <4EBC7681.8010203@kddilabs.jp> Date: Sun, 13 Nov 2011 17:56:50 +0800 Message-ID: From: liu dapeng To: Hidetoshi Yokota Content-Type: text/plain; charset=ISO-8859-1 Cc: mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 09:56:51 -0000 2011/11/11, Hidetoshi Yokota : > Hi Charlie, > > (2011/11/11 6:42), Charles E. Perkins wrote: >> >> Hello Hidetoshi, >> >> On 11/10/2011 4:41 AM, Hidetoshi Yokota wrote: >>> Hi, >>> >>> I think that the point is to give a choice to the network and user if >>> mobility is needed or not. Some applications benefit from seamless >>> mobility (e.g., VoIP), but others may not (e.g., Web access). The >>> network and user should be able to specify the capability of mobility >>> and appropriate access network for each application. In that sense, >>> Dynamic MM is an interesting feature. >> >> I pretty much agree with this; I expect that working out the >> details will be pretty tedious and perhaps even contentious. >> >> >>> I agree that the current 3GPP architecture is very complicated and may >>> not be optimal, but I don't think it is a good idea to change it in >>> IETF... >> >> I agree we can't "change" 3GPP architecture in the IETF, but >> we can respond to the needs which are evident from considering >> the 3GPP architecture. It seems very few believe that LTE >> is really immune from further evolution and even significant >> change in the future. If IETF does NOT respond to the needs made >> evident in current 3GPP specifications, we have little hope of >> proper integration into their future evolved designs. > > I fully agree with your point and am glad you initiated this discussion. > One of the reasons for its complicatedness is that the 3GPP architecture > has been incrementally built considering all the backward compatibility > and interoperability along with introducing new features and minimizing > the unhappiness of all. I respect this effort and achievement we all > enjoy today. On the other hand, the current mobile traffic is way too > much for this architecture to be able to handle. If IETF can contribute > to tackling this issue toward the future evolved design, it will be very > valuable. I don't know if DMM is the start point or we need a new WG, > but we still have a high mountain to climb. I fully aggree with this point. The mobile operators faces the presure of rapidly traffic increasing. We should consider this point when we try to optimize mobility protocols. regards, Dapeng > Regards, > -- > Hidetoshi > >> Regards, >> Charlie P. >> >> >> > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > -- ------ Best Regards, Dapeng Liu From jouni.nospam@gmail.com Sun Nov 13 09:10:50 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1845E21F8B1A for ; Sun, 13 Nov 2011 09:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.038 X-Spam-Level: X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_IP_061228=0.895, SARE_RECV_SPAM_DOMN0b=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 Nz8gz7WLJIEd for ; Sun, 13 Nov 2011 09:10:49 -0800 (PST) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6E421F8B17 for ; Sun, 13 Nov 2011 09:10:49 -0800 (PST) Received: by pzk5 with SMTP id 5so7353592pzk.9 for ; Sun, 13 Nov 2011 09:10:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Tk9tUggeKvXViyJgE66Ags1bYycLbsUeARK+tXp1MeE=; b=wX0JXdqT1y4+1+9HL4Wuzx725G0u37u+8uDZHAY4BGed5h+EvXzqgd9O6hcjICuK5L VU/Gvx0m5t/NKpIzCG4jcV+Th7hOljv1Vj6/bfnHqH/ZMrspD+H53MPD2ZbU8u2aEYFK PTYk5+VoloKFyp0f0WC0UIXQXGi2B1kZF+XsE= Received: by 10.68.29.197 with SMTP id m5mr43425095pbh.9.1321204248096; Sun, 13 Nov 2011 09:10:48 -0800 (PST) Received: from [192.168.0.15] (61-230-55-233.dynamic.hinet.net. [61.230.55.233]) by mx.google.com with ESMTPS id g8sm31008546pbe.11.2011.11.13.09.10.44 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Nov 2011 09:10:46 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Sun, 13 Nov 2011 19:10:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4E374797-95D5-45DA-A2F8-E04D18E0E5ED@gmail.com> References: <4EB2D421.4030905@earthlink.net> <1672201A-C652-4204-99D9-3DE4D23D2BB2@gmail.com> To: liu dapeng X-Mailer: Apple Mail (2.1084) Cc: Jouni Korhonen , Jari Arkko , mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 17:10:50 -0000 On Nov 13, 2011, at 11:30 AM, liu dapeng wrote: > 2011/11/7, jouni korhonen : >>=20 >> On Nov 4, 2011, at 6:18 PM, Behcet Sarikaya wrote: >>=20 >>> Hi all, >>>=20 >>> I am confused about all these very high level, intelligent looking >>> comments, and I must say I am fed up with them :-). >>>=20 >>> Non-tunneled communications is already there in DMM. You connect to = the >>> nearest HA and all new communications is non-tunneled. >>>=20 >>> Do we agree that we should differentiate client-based and network = based >>> protocols and discuss them in different places? or even there is no = issue >>> for one. >>=20 >>=20 >> IMHO I see no reason to focus only on client-based or network-based >> solutions. FWIW the DMM solution space: >>=20 >> o is incremental to an existing IETF mobility protocol, be that = client-, >> network- or even transport-based. >> o or alternatively may not depend on a specific mobility protocol at = all >> i.e. non-anchored solution is also in scope. >> o solution is backward compatible in a sense that if a host or a = network >> does not support DMM, nothing breaks. >> o focuses on IPv6 because anything IPv4 is just NAT-games. >=20 > I have concern about only focuse on IPv6. IPv4 is still widely used > today, we have to consider that. I understand this. However, the day any DMM solution hits the market can = we assume that IPv4 is the protocol those new subscribers & mobiles are = then mainly using? Given the minimum 2-3 year window anything penetrates = the mass market we manage to define here, I hope IPv6 will have more = significant role, for example, in cellular systems. - Jouni >=20 > regards, > Dapeng >=20 >> - Jouni >>=20 >>>=20 >>> I think this is what we should decide now. >>>=20 >>> Regards, >>>=20 >>> Behcet >>>=20 >>> On Fri, Nov 4, 2011 at 3:19 AM, jouni korhonen = >>> wrote: >>> Pete, >>>=20 >>> On Nov 4, 2011, at 3:16 AM, Pete McCann wrote: >>>=20 >>>> A good architecture is made not only from deciding what to = standardize >>>> but >>>> also from what not to standardize. >>>=20 >>> Exactly. >>>=20 >>> [snip] >>>=20 >>>>=20 >>>> Perhaps IETF could take LIPA as a starting point to design a = cleaner >>>> mobility management solution. >>>=20 >>> What came out from a certain SDO as a "Local IP Access" did not turn = out >>> as the most elegant solution :) But I do agree that from the idea & >>> initial use case point of view, it definitely is something to look = at.. >>> even as a basis for a cleaner design. >>>=20 >>>> It isn't clear to me that we should even start with tunnels as a = basic >>>> building >>>> block. >>>=20 >>> I am along the same lines. See my earlier mail on the charter >>> http://www.ietf.org/mail-archive/web/mext/current/msg04905.html >>>=20 >>> - Jouni >>>=20 >>>=20 >>>=20 >>>>=20 >>>> -Pete >>>>=20 >>>> On Thu, Nov 3, 2011 at 8:43 PM, Hesham Soliman >>>> wrote: >>>>> Hi Charlie, >>>>>=20 >>>>> I agree completely with you on the problems with the current = interfaces >>>>> in >>>>> LTE, and in 3G before that. >>>>> I don't know what the best way to go about it would be. I say this >>>>> because >>>>> many people on this list are aware of what's happening in LTE and >>>>> presumably have similar opinions about the complexity of their >>>>> solutions, >>>>> but it's still there. >>>>>=20 >>>>> Hesham >>>>>=20 >>>>> -----Original Message----- >>>>> From: "Charles E. Perkins" >>>>> Organization: Wichorus Inc. >>>>> Date: Thu, 03 Nov 2011 10:49:21 -0700 >>>>> To: Jari Arkko >>>>> Cc: , >>>>> Subject: Re: [MEXT] the future of the MEXT working group >>>>>=20 >>>>>> Hello folks, >>>>>>=20 >>>>>> For several years now, I have been studying 4G wireless >>>=20 >>> [snap] >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>>=20 >>=20 >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >>=20 >=20 >=20 > --=20 >=20 > ------ > Best Regards, > Dapeng Liu From pierrick.seite@orange.com Sun Nov 13 21:20:20 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB49221F8B31 for ; Sun, 13 Nov 2011 21:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.123 X-Spam-Level: X-Spam-Status: No, score=-3.123 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 Dfuntmse0NaJ for ; Sun, 13 Nov 2011 21:20:20 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 2726921F8B2E for ; Sun, 13 Nov 2011 21:20:20 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 142B2858006 for ; Mon, 14 Nov 2011 06:30:34 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 0FB2A858001 for ; Mon, 14 Nov 2011 06:30:34 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Nov 2011 06:20:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Nov 2011 06:20:17 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46202067D95@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PMIP based DMM Thread-Index: AcyijRiP+NZSfumqRbi4lxWiUOK8Vg== From: To: X-OriginalArrivalTime: 14 Nov 2011 05:20:19.0328 (UTC) FILETIME=[19C43800:01CCA28D] Subject: [MEXT] PMIP based DMM X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 05:20:20 -0000 Folks, Please find an update of draft-seite-netext-dma, now posted in MEXT: http://www.ietf.org/internet-drafts/draft-seite-mext-dma-00.txt=20 This draft discusses distributed and dynamic mobility management with Proxy Mobile IPv6, without requiring protocol extensions. Comments are welcome. Regards, Pierrick From h.anthony.chan@huawei.com Sun Nov 13 21:56:24 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0790C11E81F2 for ; Sun, 13 Nov 2011 21:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.441 X-Spam-Level: X-Spam-Status: No, score=-6.441 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 OR0z8bqe5MvM for ; Sun, 13 Nov 2011 21:56:18 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 05C6C11E81F9 for ; Sun, 13 Nov 2011 21:56:18 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUM00CCZZ5586@szxga05-in.huawei.com> for mext@ietf.org; Mon, 14 Nov 2011 13:55:53 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUM00562Z4SBV@szxga05-in.huawei.com> for mext@ietf.org; Mon, 14 Nov 2011 13:55:53 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFA36625; Mon, 14 Nov 2011 13:55:51 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 14 Nov 2011 13:55:48 +0800 Received: from SZXEML505-MBS.china.huawei.com ([169.254.2.27]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Mon, 14 Nov 2011 13:55:41 +0800 Date: Mon, 14 Nov 2011 05:55:40 +0000 From: h chan In-reply-to: <4EAA9E34.2080903@piuha.net> X-Originating-IP: [10.47.133.159] To: Jari Arkko , "mext@ietf.org" Message-id: <6E31144C030982429702B11D6746B98C19287452@SZXEML505-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_bGeqM9RMrN706GtWO1J3vw)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: [MEXT] the future of the MEXT working group Thread-index: AQHMlWqjs77o4fA/80+2iVSF0+QTGZWRJzIAgBqc9HA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4EAA9B4A.3020208@piuha.net> <4EAA9E34.2080903@piuha.net> Subject: Re: [MEXT] the future of the MEXT working group X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 05:56:24 -0000 --Boundary_(ID_bGeqM9RMrN706GtWO1J3vw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT The DMM design team consisting of people from initially 8 (and later more) major operators and vendors had worked on DMM from over a year ago. It was also open to anyone and had later been joined by more people from more both industry and academia. In the past, the activities from this team (such as dmm discussion group and a couple of dmm meetings in Prague and in Quebec City) had been considered individual activities not part of the mext WG. As the mext WG is now re-chartered into DMM WG and has used the charter statement from the team as candidate input to the re-charter statement, is it reasonable to consider incorporating the work from this team into the DMM WG? It is of cause open to more suggestions and inputs from anyone as it had always been in the past. The following 2 documents were the initial outputs from the team: Problem statement: draft-chan-distributed-mobility-ps- Use cases: draft-yokota-dmm-scenario-00 and a charter statement The majority of the charter statement can be found in the introduction charter of the above problem statement from over a year ago. This charter statement from this team is now being used by Jari as input to the re-charter to the WG. In the last dmm meeting in July, work had already started in drafting the requirements, and an initial draft has also been produced in one session of the above ps draft, which had taken the discussions into account and had closely relate the requirements to address the problem statements. In addition, the contents from the above documents had largely been used and improved in the following journal paper so that they had also been reviewed through the journal publication process: "Distributed and Dynamic Mobility Management in Mobile Internet: Current Approaches and Issues," Journal of Communications, vol. 6, no. 1, pp. 4-15, Feb 2011. I especially point out the above because they are the team work of many people resulting from a lot of efforts as well as using extensive discussions in emails (design team and then dmm mailing list) and in meetings. I have not mentioned many other drafts on dmm from many other authors here. Also, the earlier discussions in the dmm mailing list had caused the mext WG to not hold mext meeting in Quebec City with the reason that there was not enough interest in dmm. If the mext WG is to rename to dmm WG, are we going to use the dmm mailing list in future? H Anthony Chan, Fellow IEEE From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Jari Arkko Sent: Friday, October 28, 2011 8:21 PM To: mext@ietf.org Subject: Re: [MEXT] the future of the MEXT working group And a follow-up on the charter. I'm describing a couple of different takes on what the new charter could be. Comments and alternative proposals are welcome. This is what the current charter says about DMM: The working group will also work on operational considerations on setting up Mobile IPv6 networks so that traffic is distributed in an optimal way, for instance by using existing protocol mechanisms to select the closest home agents for new clients. Oct 2011 - Submit I-D 'Operational considerations for distributed use of Mobile IPv6' for publication as Informational. Which is admittedly a bit short, but is also very concrete and achievable, if we work on it. I got another proposal from Hui Deng that extended this a bit, including going beyond mere operational considerations. In the past decade a fair number of mobility protocols have been standardized. Although the protocols differ in terms of functions and associated message format, we can identify a few key common features: presence of a centralized mobility anchor providing global reachability and an always-on experience extensions to optimize handover performance while users roam across wireless cells extensions to enable the use of heterogeneous wireless interfaces for multi-mode terminals (e.g. cellular phones) The presence of the centralized mobility anchor allows a mobile device to be reachable when it is not connected to its home domain. The anchor, among other tasks, ensures forwarding of packets destined to or sent from the mobile device. As such, most of the deployed architectures today have a small number of centralized anchors managing the traffic of millions of mobile subscribers. To optimize handovers for mobile users, 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 impose stringent requirements in terms of delay. Notions of localization and distribution of local agents have been introduced to reduce signalling overhead. Unfortunately today we witness difficulties in getting such protocols deployed, often leading to sub-optimal choices. Moreover, all the availability of multi-mode devices and the possibility to use several network interfaces simultaneously have motivated the development of more new protocol extensions. Mobile users are, more than ever, consuming Internet content, and impose new requirements on mobile core networks for data traffic delivery. When this traffic demand exceeds available capacity, service providers need to implement new strategies such as selective traffic offload (e.g. 3GPP work items LIPA/SIPTO) through alternative access networks (e.g. WLAN). Moreover, the localization of content providers closer to the Mobile/Fixed Internet Service Providers network requires taking into account local Content Delivery Networks (CDNs) while providing mobility services. As long as demand exceeds capacity, both offloading and CDN techniques could benefit from the development of more flat mobile architectures (i.e., fewer levels of routing hierarchy introduced into the data path by the mobility management system). This view is reinforced by the shift in users' traffic behaviour, aimed at increasing direct communications among peers in the same geographical area. The development of truly flat mobile architectures would result in anchoring the traffic closer to point of attachment of the user and overcoming the suboptimal routing issues of a centralized mobility scheme. While deploying today's mobile networks, service providers face new challenges. More often than not, mobile devices remain attached to the same point of attachment, in which case specific IP mobility management support is not required for applications that launch and complete while connected to the same point of attachment. However, the mobility support has been designed to be always on and to maintain the context for each mobile subscriber as long as they are connected to the network. This can result in a waste of resources and ever-increasing costs for the service provider. Infrequent mobility and intelligence of many applications suggest that mobility can be provided dynamically, thus simplifying the context maintained in the different nodes of the mobile network. The proposed charter will address two complementary aspects of mobility management procedures: the distribution of mobility anchors to achieve a more flat design and the dynamic activation/deactivation of mobility protocol support as an enabler to distributed mobility management. The former has the goal of positioning mobility anchors (HA, LMA) closer to the user; ideally, these mobility anchors could be collocated with the first hop router. The latter, facilitated by the distribution of mobility anchors, aims at identifying when mobility must be activated and identifying sessions that do not impose mobility management -- thus reducing the amount of state information to be maintained in the various mobility anchors of the mobile network. The key idea is that dynamic mobility management relaxes some constraints while also repositioning mobility anchors; it avoids the establishment of non optimal tunnels between two anchors topologically distant. Considering the above, the working group will: Define the problem statement and associated requirements for distributed mobility management. This work aims at defining the problem space and identifies the key functional requirements. Produce a gap analysis mapping the above requirements against existing solutions. Give best practices for the deployment of existing mobility protocols in a distributed mobility management and describe limitations of each such approach. Describe extensions, if needed, to current mobility protocols for their application in distributed mobility architectures Comments? Jari --Boundary_(ID_bGeqM9RMrN706GtWO1J3vw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

 

The DMM design team consisting of people from initially 8 (and later more) major operators and vendors had worked on DMM from over a year ago. It was also open to anyone and had later been joined by more people from more both industry and academia. In the past, the activities from this team (such as dmm discussion group and a couple of dmm meetings in Prague and in Quebec City) had been considered individual activities not part of the mext WG. As the mext WG is now re-chartered into DMM WG and has used the charter statement from the team as candidate input to the re-charter statement, is it reasonable to consider incorporating the work from this team into the DMM WG? It is of cause open to more suggestions and inputs from anyone as it had always been in the past.

 

The following 2 documents were the initial outputs from the team:

Problem statement: draft-chan-distributed-mobility-ps-

Use cases: draft-yokota-dmm-scenario-00

and a charter statement

 

The majority of the charter statement can be found in the introduction charter of the above problem statement from over a year ago.

This charter statement from this team is now being used by Jari as input to the re-charter to the WG.

 

In the last dmm meeting in July, work had already started in drafting the requirements, and an initial draft has also been produced in one session of the above ps draft, which had taken the discussions into account and had closely relate the requirements to address the problem statements.

 

In addition, the contents from the above documents had largely been used and improved in the following journal paper so that they had also been reviewed through the journal publication process:

 

“Distributed and Dynamic Mobility Management in Mobile Internet: Current Approaches and Issues,” Journal of Communications, vol. 6, no. 1, pp. 4-15, Feb 2011.

 

I especially point out the above because they are the team work of many people resulting from a lot of efforts as well as using extensive discussions in emails (design team and then dmm mailing list) and in meetings.

 

I have not mentioned many other drafts on dmm from many other authors here.

 

Also, the earlier discussions in the dmm mailing list had caused the mext WG to not hold mext meeting in Quebec City with the reason that there was not enough interest in dmm. If the mext WG is to rename to dmm WG, are we going to use the dmm mailing list in future?

 

H Anthony Chan, Fellow IEEE

 

From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Jari Arkko
Sent: Friday, October 28, 2011 8:21 PM
To: mext@ietf.org
Subject: Re: [MEXT] the future of the MEXT working group

 

And a follow-up on the charter. I'm describing a couple of different takes on what the new charter could be. Comments and alternative proposals are welcome. This is what the current charter says about DMM:

  The working group will also work on operational considerations on
  setting up Mobile IPv6 networks so that traffic is distributed
  in an optimal way, for instance by using existing protocol mechanisms
  to select the closest home agents for new clients.

  Oct 2011 - Submit I-D 'Operational considerations for distributed use of Mobile IPv6' for publication as Informational.


Which is admittedly a bit short, but is also very concrete and achievable, if we work on it. I got another proposal from Hui Deng that extended this a bit, including going beyond mere operational considerations.

In the past decade a fair number of mobility protocols have been standardized. Although the protocols differ in terms of functions and associated message format, we can identify a few key common features:
presence of a centralized mobility anchor providing global reachability and an always-on experience
extensions to optimize handover performance while users roam across wireless cells
extensions to enable the use of heterogeneous wireless interfaces for multi-mode terminals (e.g. cellular phones)
The presence of the centralized mobility anchor allows a mobile device to be reachable when it is not connected to its home domain. The anchor, among other tasks, ensures forwarding of packets destined to or sent from the mobile device. As such, most of the deployed architectures today have a small number of centralized anchors managing the traffic of millions of mobile subscribers.

To optimize handovers for mobile users, 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 impose stringent requirements in terms of delay. Notions of localization and distribution of local agents have been introduced to reduce signalling overhead. Unfortunately today we witness difficulties in getting such protocols deployed, often leading to sub-optimal choices. Moreover, all the availability of multi-mode devices and the possibility to use several network interfaces simultaneously have motivated the development of more new protocol extensions.

Mobile users are, more than ever, consuming Internet content, and impose new requirements on mobile core networks for data traffic delivery. When this traffic demand exceeds available capacity, service providers need to implement new strategies such as selective traffic offload (e.g. 3GPP work items LIPA/SIPTO) through alternative access networks (e.g. WLAN). Moreover, the localization of content providers closer to the Mobile/Fixed Internet Service Providers network requires taking into account local Content Delivery Networks (CDNs) while providing mobility services. 

As long as demand exceeds capacity, both offloading and CDN techniques could benefit from the development of more flat mobile architectures (i.e., fewer levels of routing hierarchy introduced into the data path by the mobility management system). This view is reinforced by the shift in users’ traffic behaviour, aimed at increasing direct communications among peers in the same geographical area. The development of truly flat mobile architectures would result in anchoring the traffic closer to point of attachment of the user and overcoming the suboptimal routing issues of a centralized mobility scheme.

While deploying today’s mobile networks, service providers face new challenges. More often than not, mobile devices remain attached to the same point of attachment, in which case specific IP mobility management support is not required for applications that launch and complete while connected to the same point of attachment. However, the mobility support has been designed to be always on and to maintain the context for each mobile subscriber as long as they are connected to the network. This can result in a waste of resources and ever-increasing costs for the service provider. Infrequent mobility and intelligence of many applications suggest that mobility can be provided dynamically, thus simplifying the context maintained in the different nodes of the mobile network.

The proposed charter will address two complementary aspects of mobility management procedures: the distribution of mobility anchors to achieve a more flat design and the dynamic activation/deactivation of mobility protocol support as an enabler to distributed mobility management. The former has the goal of positioning mobility anchors (HA, LMA) closer to the user; ideally, these mobility anchors could be collocated with the first hop router. The latter, facilitated by the distribution of mobility anchors, aims at identifying when mobility must be activated and identifying sessions that do not impose mobility management -- thus reducing the amount of state information to be maintained in the various mobility anchors of the mobile network. The key idea is that dynamic mobility management relaxes some constraints while also repositioning mobility anchors; it avoids the establishment of non optimal tunnels between two anchors topologically distant.

Considering the above, the working group will:

Define the problem statement and associated requirements for distributed mobility management. This work aims at defining the problem space and identifies the key functional requirements.

Produce a gap analysis mapping the above requirements against existing solutions.

Give best practices for the deployment of existing mobility protocols in a distributed mobility management and describe limitations of each such approach.

Describe extensions, if needed, to current mobility protocols for their application in distributed mobility architectures


Comments?

Jari

--Boundary_(ID_bGeqM9RMrN706GtWO1J3vw)-- From charliep@computer.org Mon Nov 14 02:10:55 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF8011E80AF for ; Mon, 14 Nov 2011 02:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-8Cyy9GybIT for ; Mon, 14 Nov 2011 02:10:54 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 67C8421F8F81 for ; Mon, 14 Nov 2011 02:05:16 -0800 (PST) Received: from [130.129.83.71] by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1RPt7S-00052C-Kt for mext@ietf.org; Mon, 14 Nov 2011 04:46:27 -0500 Message-ID: <4EC0E36D.2050508@computer.org> Date: Mon, 14 Nov 2011 01:46:21 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86270baa998236315e751abc98e2869932350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.83.71 Subject: [MEXT] Presentation about enabling Mobile IPv6 for heterogeneous networks of the future X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: charliep@computer.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 10:10:56 -0000 Hello folks, Here is a link to the presentation I made last week at the Miracle 2011 workshop. It is intended to - describe particular problems of importance for 4G - describe specific approaches for solutions One thesis of the workshop was that LTE is subject to continued and perhaps substantial new design efforts, thus offering future application for any IETF actions that could be undertaken within [mext]. http://arkko.com/miracle2011/presentations/session3/s3-Charles.pdf The part about assistance for location information for target access networks would be important for smooth handovers, but is pretty much separate from the nuts and bolts suggestions of the previous slides. Many of these problems could have a significant impact on the ability of 3GPP to adopt any eventual DMM solution (other than _completely_ unanchored, that is). If I could distill the message down to one sentence: either we revise Mobile IPv6, or IETF mobility management risks becoming mostly irrelevant. Comments will be appreciated. Regards, Charlie P. From jouni.nospam@gmail.com Mon Nov 21 04:23:49 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C962521F8BA2 for ; Mon, 21 Nov 2011 04:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.855 X-Spam-Level: X-Spam-Status: No, score=-2.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, 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 V1vp0Vn6jw58 for ; Mon, 21 Nov 2011 04:23:48 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id C6F9421F8BBC for ; Mon, 21 Nov 2011 04:23:47 -0800 (PST) Received: by fabs1 with SMTP id s1so1472730fab.31 for ; Mon, 21 Nov 2011 04:23:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:subject:date:message-id:cc:to:mime-version :x-mailer; bh=emw4FuZj5sfNMolnrIItmCeBERD671Pj18W4zxLO4G8=; b=r8tWm65FVXe7gu85gcmSwepfRHAmA2/R/v2pV0+1xHYfaekXpbH4P0cHwirUfPfwz8 /2jbuD4uIlF6mZ8V714p8SRrL+J42/ctnFt1bk2En5lVM2W9j3pF3fMiGqGtPCYtvg4P DQkMhKvC2KPyCJVosWYfQ8dLRBiIMoT2s+I+4= Received: by 10.205.133.16 with SMTP id hw16mr13775099bkc.128.1321878226910; Mon, 21 Nov 2011 04:23:46 -0800 (PST) Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPS id dq2sm7131366bkb.11.2011.11.21.04.23.44 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Nov 2011 04:23:45 -0800 (PST) From: Jouni Content-Type: multipart/mixed; boundary="Apple-Mail=_4F4E8344-CA0B-4B04-92E7-C1B7F0B8D960" Date: Mon, 21 Nov 2011 14:23:43 +0200 Message-Id: To: mext@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Cc: mext-chairs@ietf.org Subject: [MEXT] Draft meeting notes for review. X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 12:23:49 -0000 --Apple-Mail=_4F4E8344-CA0B-4B04-92E7-C1B7F0B8D960 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks, See the attached *draft* notes. Thanks a lot to Wen Luo and Pierrick = Seite for taking excellent & detailed notes. - Jouni --Apple-Mail=_4F4E8344-CA0B-4B04-92E7-C1B7F0B8D960 Content-Disposition: attachment; filename=mext82.txt Content-Type: text/plain; name="mext82.txt" Content-Transfer-Encoding: quoted-printable Combined *DRAFT* notes from Pierrick and Wen Luo=0D Introduction=0D ----------------------------------------------------------------------=0D= Chair: the meeting will focus on DMM and rechartering discussion=0D =0D CP: 1H meeting for presentation and rechartering discussion is not = enough. Should schedule another meeting in the week=0D =0D Jouni: I'll relay to the AD.=0D =0D Behcet seconds Charlie and stresses that the agenda has been extended to = include other item than distributed mobility=0D =0D Per-Host Locators for Distributed Mobility Management =0D ----------------------------------------------------- =0D Marco Liebsch (ML) presents draft-liebsch-mext-dmm-nat-phl=0D =0D This a new draft. The goal is to provide IP session continuity after = mobility anchor relocation=0D =0D key features:=0D - No change in mobility protocols=0D - address both PMIP and MIP=0D - Replace tunnel by NATs -> two NATs level=0D =0D Sri Gundavelli: How the status is created on the NAT?=0D ML: current mechanism only focuses on the data plane. For the control = plane, different mechanisms could be studied. We can have a database = maintaining the mapping, similar to LISP. The issue on dynamic update of = the binding. We have thought about but not yet write down. It depends = on whether you consider the ingress router and NAT on the pMAG.=0D SG: can we assume a signalling protocol between those entity?=0D ML: Yes, we can assume=0D SG: so, it is not a pure database signalling but state creation=0D ML: yes=0D Pete McCan: on the forwarding plane, we can do NAT, tunnel, or even = routing?=0D ML: the advantage we see here, is that we can use routing reusing the = existing routing plane. You don't need per host state on all these = router. You just need state on the Ingress Router (IR). =0D PMC: right. The point is that the solution doesn't look very = distributes, it looks like an additional layer of hierarchy. The = architecture between the Ingress Router and the pMA may be more = distributed. =0D ML: I don't think it is an additional hierarchy in mobility anchors. = It's router which needs Per-host state, true. But it needs to state only = after anchor relocation, which means: on the pMA the identifier is = routable, it don't need to state there. It's only when the MN moves that = you need to create a state on the Ingress Router.=0D =0D =0D Approaches to Distributed mobility management using Mobile IPv6 and its = extensions=0D = --------------------------------------------------------------------------= -------- =0D Raj Patil presents draft-patil-mext-dmm-approaches=0D Already presented during previous meeting=0D =0D Scope: the draft discusses solutions how deploy DMM=0D =0D Raj reminds "well-known" issues of centralize architectures=0D Raj argues that we can take existing protocols and their extensions = (HMIP, PMIP) we don't need new protocols but it=C3=ADs worth providing a = BCP.=0D =0D No question/comment=0D =0D PMIP Based Distributed Mobility Management Approach=0D --------------------------------------------------- =0D Wen Luo (WL) presents draft-liu-dmm-pmip-based-approach=0D =0D Solution in few words:=0D - MN to CN comm. via MAG to MAG direct path.=0D - Traffic anchored at the MAG close to the CN=0D - LMA used only as a locator=0D =0D Charles Perkins: how can the cn distinguish between the pMAG and a = malicious node sending out this update?=0D WL: do you mean there is a security issue?=0D CP: Yes=0D WL: CN and MN are in the same PMIP domain.=0D SG: How does the MN know the MAG-CN?.=0D WG: get it from the LMA.=0D SG: so, how does the LMA know?=0D WL: both the MN and CN register to the LMA as PMIP does, they are in the = same PMIP domain=0D SG: But the CN has no security relation with the LMA=0D WL: if the CN register to the LMA, the LMA knows the CN-CoA.=0D SG: it=C3=ADs true if both MNs are anchored at same LMA but what if the = CN has no relation to the LMA?=0D WL: you mean using two different LMA?=0D SG: not only, the CN may be a fixed node, so not anchored at the LMA.=0D WL: ok, I can consider it further=0D Marco Liebsch (ML): already commented in last IETF, but if you=C3=ADre = considering that both the MN and CN are registered to the same LMA, what = are the difference with LR designed in netext WG?=0D WL: we have some difference in handover considerations between this = solution and the one in netext. =0D ML: you could consider direct tunnel to CN which is not registered to = the PMIP domain. In this case, CN is a generic IPv6 node and you = establish a direct route to it. That=C3=ADs something new.=0D WL: In this case the MAG of the MN does not know the CoA of the CN. So, = it operates as the PMIP does.=0D ML: ok, some addition =0D =0D Bruno: If CN and MN are in same LMA, HMIP has same benefits. So I don=C3=AD= t see any reason to not use HMIP. =0D WL: HMIP is complicated and hard to deploy =0D =0D Use of Proxy Mbile IPv6 for Distributed Mobility Control=0D -------------------------------------------------------- =0D Ji-In Kim (JIK) presents draft-sjkoh-mext-pmip-dmc =0D =0D Solution in two words:=0D - The MN and the CN are in the same PMIP domain -> communication between = two MNs=0D - the initiator gets location of its correspondent up to a centralized = location database (partial distribution) or floods the network to query = all MAGs (fully distributed solution)=0D - new messages to achieve this: PBQ/PBA=0D - then inter-MAG tunnelling=0D - Address both partial and full DMM approaches=0D =0D SG: How does the nMAG knows the LMA for the MN? In other words, how do = you know where to send PBQ? =0D JK (clarifying the question for JIK): here, you cannot make an = assumption that that CN and the MN are in same PMIP domain: the CN can = be generic IPv6 node, e.g. a node in the Internet. In this case, how = does it work?=0D SG: yes, how do you enforce this assumption? =0D JIK: the LMA is the anchor point, so the CN sends a packet where the = destination home address is the LMA, so,... SG: no, the destination address belongs to one of the LMA prefixes. But = how do you know the LMA which has allocated that prefix: LMA is hosting = P1, P2, P3 prefixes. When the CN sends a packet to P1::/, how do you = know the LMA corresponding to that prefix.=0D JIK:...=0D =0D JK: You should discuss offline or in the ML=0D =0D Dapeng Liu: for the Full distributed approach. How do you do the = authentication if there is no LMA there.=0D JIK: the SD-PMIP [note: fully distributed] is the worst case. So, the = MAG replies to the CN, so,... =0D DP: do you mean that the MAG does the authentication of the MN?=0D JIK: mhhh...=0D =0D JK: ok, let=C3=ADs continue discuss on the ML or offline=0D =0D Re-chartering discussion=0D ------------------------ Introduction:=0D =0D The discussion is based on AD's email (sent on the October, 28th), based = on a proposal from a group of motivated people. =0D =0D Jouni reminds that a short sentence on distributed mobility management = already exist in the charter. =0D =0D =0D We already had discussed on the ML (Jouni posted a summary). The = discussion has been motivated by 3GPP architecture and evolution. It=C3=AD= s a good thing but protocol designed here must not address only 3GPP = needs.=0D =0D Reusing existing mobility protocol should be the priority. Non anchored = solution are also in the scope.=0D =0D DMM should not break anything.=0D =0D Focus on IPv6 based solution, but we'll not ignore IPv4 .=0D =0D Summarizing the discussion, it is suggested a 4 steps process:=0D 1. address problem statement and requirement.=0D 2. gap analysis with centralized approaches.=0D 3. BCP reusing current protocols and existing extensions.=0D 4. specify new extensions if needed.=0D =0D Open discussion:=0D =0D CP: [Charlie says again that 1H long meeting is not enough to discuss = such issues. According to Charlie, posting the claim for rechartering = only 2 or 2 weeks before the IETF does not give enough time for = discussion.] =0D Shorten the WG to DMM may be problematic. MEXT is the right place to = address improvement of Mobile IP and, considering what 4G networks = should do, it=C3=ADs clear that Mobile IP has some design inadequacies = that need to be remedied. =0D [Charlie made a proposal to AD for that]. It seems that there are enough = people to support effort on other issues than DMM, at least to identify = remaining issues: Charlie thinks that we should not short the WG down. =0D= Charlie suggests to try to identify other work items before next IETF.=0D= =0D Jari Arkko (JA): We do not have enough time to reach a conclusion during = this meeting. =0D Jari clarifies that it is not shorting down MEXT, but, here it is to = focus on one topic. Jari has nothing against adding new things in the = charter IF there is significant interest. But we need to see interest = and demonstrated interest we=C3=ADve not =0D seen that for everything in the past.=0D =0D CP: appreciate what Jari said. Because we have not enough time to = discuss during IETF 82 meeting, Charlie suggests to have a ML discussion = to see if there is people to support effort on redesign of (P)MIPv6. = Then make a decision on IETF 83.=0D =0D JA: discuss what people want to do (and if there is energy on the WG to = work on) is useful now, we'll focus on that. =0D =0D Raj Patil: agree on continue enhanced mobility protocol as Charlie said. = There are extensions that can be still be specified. Think there are = enough people that are able to support the effort.=0D =0D JA: Jari reminds that there is not so much remaining items in the = charter: AD's sponsored security document is going to the IESG. Other = documents in the security space would be too. Jari is not in favour to = include vague items like "improving protocols". If people have good, and = precise, ideas and energy to work on, there is no objection to include = these items in the charter.=0D =0D Anthony Chan: [going back to the DMM discussion] Jouni's slides = summarize too much previous discussion. Anthony says that large number = of people discussed the DMM stuff on an ad-hoc mailing list (called = DMM); they have issued couple of documents (including the current = charter proposal). Also, I-D exists on problem statement and use-cases. = Anthony suggests to get this as an input to going further. Anthony = stresses the need for a problem statement and requirement and volunteers = to continue to work on.=0D =0D JK: it's an open process; everybody is encouraged to provide inputs and = inject their own ideas.=0D =0D JA: Clearly we take off-list work. Recharter text is based on that work. = The question is: do you have opinion about the charter here? Do you want = a tiny version? What is it the charter want to say? =0D =0D HC: stresses the need to have a clear understanding on what the issues = are. The evolution of network architecture gives the framework and may = impact mobility design. For example, introduction of CDN. Also, there no = clear definition of distributed mobility. Thus, need a document which = clearly defines the problem. =0D =0D =0D Hannes: In previous WG session there were a discussion on the lack of = deployment for Mobile IP. Last week, Charlie gave a presentation on a = workshop. Encourage people to share their views/thoughts, on the ML, to = get a better understanding on the problems and what the issues are.=0D =0D PMC: some of these issues, especially, when we talk about a MN using a = CoA without tunnelling are getting into details inside some of the = mobile operating systems. Pete suggest either people from the IETF or = outside the IETF can get involved in the discussion. Involve either some = of the major operating systems, vendors,... So we could develop a system = architecture at the same time we develop protocols for the network side. = We could involved outside entities in a way we did not in the past. =0D =0D JK: yes. Good input.=0D =0D Behcet Sarikaya (BS): [Behcet seconds Charlie]. I [Behcet] don't like = non-anchored solutions. =0D =0D JK: Is there a reason for that?=0D =0D BS: Yes I'll explain. [Behcet likes the slides] Also, I'd like to see = problem statement and requirements to really understand motivation for = CP/DP separation, distribution,... Behcet suggest to start focusing on = MIP. Then, if there is interest, consider PMIP (or whatever) as well.=0D =0D ML: fully agree that this work should not be specific to 3GPP = architecture but 3GPP has no problem on using MIP/PMIP. The problem is = on the deployment. But looking at the proposal we have on the table so = far to address distributed mobility, some of them tries to address = different aspects of the problem. So, Marco fully agrees we should work = on a joint view of the problem, then agree on some design = goals/requirements. We may agree on mechanisms which may easily apply to = MIP/PMIP. Or, we may reach the conclusion we need support of other = protocols, like Diameter, or Radius. Modify these protocols is Out of = the WG scope but we should cooperate with corresponding WG. First step = is problem statement getting design goals and requirements, then define = how to touch MIP/PMIP.=0D =0D DL: Dapeng responds to Behcet: we should not preclude PMIP or = non-anchored solutions at this step, we should consider both = possibilities.=0D =0D SG: It is fundamental to not define new signalling semantics. Anything = we do must be based on MIP/PMIP protocols semantic. This should be the = based criteria.=0D =0D Ryuji Wakikawa (RW): comment on the second bullet of (slide?). It's not = clear. Do people want to define one protocol covering HA/LMA = distribution? Because, we use to say "Anchor point". Anchor point may = be HA/LMA/MAG, so there may be different solutions. Sentence stating = optimal tunnel between mobility anchors: this is pretty much PMIP. = Charter is vague, maybe you assume some solution. Ryuji suggests to = revise the charter to clearly identify what we want to work on. =0D =0D JK: Jouni has the same feeling but reminds that the charter has still = not converge to what we want to have.=0D =0D CP: Charlie suggest to consider the extreme cases: 1) completely = hierarchical solution 2) completely non-anchored solution. We can make = lot of progress just considering extreme cases and figure out how it = works. =0D =0D HC: want to clarify 2nd bullet: many solutions for deployments of = anchors, the fundamental is geographical distribution which can be more = or less flatten, which may lead to lot of anchors. It is up to the = deployment. The issue is to make them work together. =0D =0D CP: Of course there are many possibilities. But it impacts the solution = space when you decide the level of distribution. MN may use different = anchors at the same time, so inducing lot of signalling. So, lot of = anchors and lot of signalling.=0D =0D PMC: Pete advocates to relax the requirement of maintaining the same IP = address for the MN during the session (even when PoA handover).=0D =0D JK: yes, it is what we have today.=0D =0D JA: It is hard to draw for a conclusion, but there are few things it can = be asked to the room; on what the charter should include: four things if = you like to see these in the charter or not. Q1: First one will be this narrow scope that only operational document = that describing how to use current protocols in a distributed fashion, = no extensions. Q2: Second one is more or less like this on the screen now which is = basically all of the above and also possibly some extensions related to = DMM. Q3: The third question is we should include both proxy and client = mobility, and Q4: fourth thing is if you want more open ended MIPv6 improvement. =0D =0D JCZ: do we need support of the OS and manufacturers support? Refer to = long discussion within netext on logical interface=0D JA: everything we do need support from manufactures.=0D =0D Q1: narrow definition of the charter focusing on operational = considerations or wider scope including protocol extensions =0D =0D Consensus on wider 'Q2' scope=0D =0D Q3: include both Client Based and Network Based mobility solutions in = this work.=0D =0D Consensus on including both Client an Network.=0D =0D ML: says it would be more natural to start with narrow scope, then move = to wider scope if necessary=0D =0D JA: Jari agrees and says that the charter should reflect this.=0D =0D Q4: enhance deployability of MIP.=0D =0D JA: it is unclear on Enhance deployability of MIP; it might be = interested but we need more details on what it can be proposed =0D =0D JK: we'll continue discussion on the mailing list and work on the = charter text.=20 Clear concensus for Q2 & Q3. =0D =0D Additional document presentations=0D ---------------------------------=0D =0D No time to present=0D =0D o Distributed Mobility Management Protocol with Multicast=0D Support (draft-sarikaya-mext-multicastdmm) - Behcet Sarikaya (Huawei)=0D= =0D o global HAHA (draft-kuntz-dmm-summary-01) - Ryuji Wakikawa (Toyota)=0D =0D o Negotiation of security protocol for Mobile IPv6 operation = (draft-patil-mext-sec-negotiate-03) - Bruno Faria=0D --Apple-Mail=_4F4E8344-CA0B-4B04-92E7-C1B7F0B8D960-- From marc.lampo@eurid.eu Mon Nov 28 00:15:16 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F50F11E808F for ; Mon, 28 Nov 2011 00:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.001 X-Spam-Level: *** X-Spam-Status: No, score=3.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, MSGID_MULTIPLE_AT=1.449, RDNS_NONE=0.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 cYIu2btUWcL1 for ; Mon, 28 Nov 2011 00:15:15 -0800 (PST) Received: from cuda.eurid.eu (unknown [62.41.4.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2283121F8BC3 for ; Mon, 28 Nov 2011 00:15:13 -0800 (PST) X-ASG-Debug-ID: 1322468109-02dadd0667a0650001-NRjzFm Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by cuda.eurid.eu with ESMTP id wSEK8TkgmgTPmswQ for ; Mon, 28 Nov 2011 09:15:09 +0100 (CET) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 4EC8DE4056 for ; Mon, 28 Nov 2011 09:15:09 +0100 (CET) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbUzc1nBqasl for ; Mon, 28 Nov 2011 09:15:09 +0100 (CET) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 3DEECE4050 for ; Mon, 28 Nov 2011 09:15:09 +0100 (CET) From: "Marc Lampo" To: Date: Mon, 28 Nov 2011 09:15:09 +0100 (CET) X-ASG-Orig-Subj: feedback on draft-ietf-firewall-[vendor|admin]-05 Message-ID: <006901ccada5$d8644200$892cc600$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: AcytpdgEd6e1lIHyScO+9L374FdmaA== Content-Language: en-za X-Originating-IP: [172.20.5.51] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1322468109 X-Barracuda-URL: http://10.31.100.125:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Subject: [MEXT] feedback on draft-ietf-firewall-[vendor|admin]-05 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 08:15:16 -0000 Hello, Looking at the list archive, I see no comments on these drafts, published October 17th. Nor do I find any traces of discussions on IETF-82. However, from a security point of view, I do have a remark. In both drafts, the "Security Considerations" state : (quoting extracts) ... "recommends a liberal setting of firewall rules" ... ... "some malicious traffic may be permitted" ... ... "allow the initiation of Denial of Service attacks against Mobile IPv6 capable nodes" ... Is this acceptable ? Being concerned with security, I'd say that these statements as "Security Considerations" might lead to the conclusion that these mobility extensions cannot be used, in practice ?! We hear that mobile networks might be the first to be IPv6 only (if there aren't already such networks around) --> IPv6 only in mobile nets : the target for Mobility Extensions We see that more and more banks offer clients for smartphones for Internet banking --> the "correspondent node" might very well be in some bank's DMZ ??? if they, bank security admins, will accept to setup security devices in such a way that "firewall rules are liberal" and "potentially allow that DOS attacks are started" ??? It is my impression that, to put mobility information so "deep" in the stack - as "extension header" with IPPROTO_NONE in the next header field - implies that security infrastructure will need quite some CPU resources to work its way through them. Wouldn't it have been wiser to assign a (UDP ?) portnumber to the Mobility "application" ? Kind regards, Marc Lampo Security Officer       EURid     Woluwelaan 150         1831 Diegem - Belgium     marc.lampo@eurid.eu     http://www.eurid.eu From Basavaraj.Patil@nokia.com Tue Nov 29 09:53:06 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50DA21F8B64 for ; Tue, 29 Nov 2011 09:53:06 -0800 (PST) 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 X1s-kjSMvxVw for ; Tue, 29 Nov 2011 09:53:06 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id B77C821F8B61 for ; Tue, 29 Nov 2011 09:53:05 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pATHqWWR027087; Tue, 29 Nov 2011 19:52:32 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Nov 2011 19:52:31 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.176]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.01.0355.003; Tue, 29 Nov 2011 18:52:31 +0100 From: To: , Thread-Topic: [MEXT] feedback on draft-ietf-firewall-[vendor|admin]-05 Thread-Index: AcytpdgEd6e1lIHyScO+9L374FdmaAA3yRcA Date: Tue, 29 Nov 2011 17:52:30 +0000 Message-ID: In-Reply-To: <006901ccada5$d8644200$892cc600$@lampo@eurid.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.33] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 29 Nov 2011 17:52:31.0990 (UTC) FILETIME=[AB202960:01CCAEBF] X-Nokia-AV: Clean Subject: Re: [MEXT] feedback on draft-ietf-firewall-[vendor|admin]-05 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 17:53:06 -0000 Hi Marco, In I-D: draft-ietf-mext-mip6-tls we do propose the use of UDP encapsulation for signaling and traffic between the MN and HA. This would make the processing and firewall rules simpler (UDP port) as you mentioned in your email. -Raj On 11/28/11 2:15 AM, "ext Marc Lampo" wrote: >Hello, > >Looking at the list archive, I see no comments on these drafts, published >October 17th. >Nor do I find any traces of discussions on IETF-82. > >However, from a security point of view, I do have a remark. >In both drafts, the "Security Considerations" state : >(quoting extracts) >... "recommends a liberal setting of firewall rules" ... >... "some malicious traffic may be permitted" ... >... "allow the initiation of Denial of Service attacks against Mobile IPv6 >capable nodes" ... > >Is this acceptable ? >Being concerned with security, I'd say that these statements as "Security >Considerations" >might lead to the conclusion that these mobility extensions cannot be >used, in practice ?! > >We hear that mobile networks might be the first to be IPv6 only (if there >aren't already such networks around) > --> IPv6 only in mobile nets : the target for Mobility Extensions >We see that more and more banks offer clients for smartphones for Internet >banking > --> the "correspondent node" might very well be in some bank's DMZ > >??? if they, bank security admins, will accept to setup security devices > in such a way that "firewall rules are liberal" > and "potentially allow that DOS attacks are started" ??? > >It is my impression that, to put mobility information so "deep" in the >stack > - as "extension header" with IPPROTO_NONE in the next header field - >implies that security infrastructure will need quite some CPU resources >to work its way through them. >Wouldn't it have been wiser to assign a (UDP ?) portnumber to the Mobility >"application" ? > > >Kind regards, > > > >Marc Lampo >Security Officer >=20 > EURid > Woluwelaan 150 > 1831 Diegem - Belgium > marc.lampo@eurid.eu > http://www.eurid.eu >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www.ietf.org/mailman/listinfo/mext From suresh.krishnan@ericsson.com Tue Nov 29 13:22:17 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C865911E80D0 for ; Tue, 29 Nov 2011 13:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.41 X-Spam-Level: X-Spam-Status: No, score=-104.41 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_FUTURE_12_24=2.189, RCVD_IN_DNSWL_MED=-4, 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 QfXe4rju3iAL for ; Tue, 29 Nov 2011 13:22:17 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 143B111E80C4 for ; Tue, 29 Nov 2011 13:22:17 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pATLL9A8022984; Tue, 29 Nov 2011 15:21:43 -0600 Received: from [142.133.10.111] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.137.0; Tue, 29 Nov 2011 16:21:22 -0500 Message-ID: <4ED69E3E.4000200@ericsson.com> Date: Wed, 30 Nov 2011 16:21:02 -0500 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Marc Lampo References: <006901ccada5$d8644200$892cc600$@lampo@eurid.eu> In-Reply-To: <006901ccada5$d8644200$892cc600$@lampo@eurid.eu> X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "mext@ietf.org" Subject: Re: [MEXT] feedback on draft-ietf-firewall-[vendor|admin]-05 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 21:22:17 -0000 Hi Marc, Thanks for your comments. Please see responses inline. On 11/28/2011 03:15 AM, Marc Lampo wrote: > Hello, > > Looking at the list archive, I see no comments on these drafts, published > October 17th. > Nor do I find any traces of discussions on IETF-82. > > However, from a security point of view, I do have a remark. > In both drafts, the "Security Considerations" state : > (quoting extracts) > ... "recommends a liberal setting of firewall rules" ... > ... "some malicious traffic may be permitted" ... > ... "allow the initiation of Denial of Service attacks against Mobile IPv6 > capable nodes" ... This selective quoting misses out the context. This text only refers to MIPv6 *signaling* traffic that is *encrypted*. I am not sure what more can be done here. If you get an encrypted packet at a firewall, you can either drop it or allow it to pass. > > Is this acceptable ? > Being concerned with security, I'd say that these statements as "Security > Considerations" > might lead to the conclusion that these mobility extensions cannot be > used, in practice ?! > > We hear that mobile networks might be the first to be IPv6 only (if there > aren't already such networks around) > --> IPv6 only in mobile nets : the target for Mobility Extensions > We see that more and more banks offer clients for smartphones for Internet > banking > --> the "correspondent node" might very well be in some bank's DMZ These blanket IPsec rules are applicable only for packets to/from the HA address and not any arbitrary address. They are not relevant to the CNs. > > ??? if they, bank security admins, will accept to setup security devices > in such a way that "firewall rules are liberal" > and "potentially allow that DOS attacks are started" ??? I am not getting the reference to bank security admins here. The encrypted packets are between the HA and the MN. So the firewalls that need to handle them are in the home network (housing the HA) and the network to which the MN is attached. > > It is my impression that, to put mobility information so "deep" in the > stack > - as "extension header" with IPPROTO_NONE in the next header field - > implies that security infrastructure will need quite some CPU resources > to work its way through them. > Wouldn't it have been wiser to assign a (UDP ?) portnumber to the Mobility > "application" ? This is how it is done for DSMIPv6 (port 4191) as described in Section 4.1. Thanks Suresh