Re: [MEXT] the future of the MEXT working group

<Basavaraj.Patil@nokia.com> Mon, 31 October 2011 20:35 UTC

Return-Path: <Basavaraj.Patil@nokia.com>
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 D763111E8247 for <mext@ietfa.amsl.com>; Mon, 31 Oct 2011 13:35:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.54
X-Spam-Level:
X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=-0.256, 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 9ZfKCYPNgiwY for <mext@ietfa.amsl.com>; Mon, 31 Oct 2011 13:35:16 -0700 (PDT)
Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id A622B11E8246 for <mext@ietf.org>; Mon, 31 Oct 2011 13:35:15 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9VKZDlj012658; Mon, 31 Oct 2011 22:35:13 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 22:35:12 +0200
Received: from 008-AM1MMR1-007.mgdnok.nokia.com (65.54.30.23) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 31 Oct 2011 21:35:12 +0100
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; Mon, 31 Oct 2011 21:35:11 +0100
From: Basavaraj.Patil@nokia.com
To: julien.ietf@gmail.com
Thread-Topic: [MEXT] the future of the MEXT working group
Thread-Index: AQHMlWpmfRWG/cEPIEyACm1+ri2dNZWRi8gAgADD+FCABI0+AIAAEQUw
Date: Mon, 31 Oct 2011 20:35:11 +0000
Message-ID: <21E7D9BD69CC7241AAE00F4EA183B719014CEC85@008-AM1MPN1-071.mgdnok.nokia.com>
References: <4EAA9B4A.3020208@piuha.net> <4EAA9E34.2080903@piuha.net> <21E7D9BD69CC7241AAE00F4EA183B719014CE67F@008-AM1MPN1-071.mgdnok.nokia.com> <CAE_dhjvyKdwNbHyOy5dJUdS3NgP5u1pNqK32EZUcPnGSm-suxg@mail.gmail.com>
In-Reply-To: <CAE_dhjvyKdwNbHyOy5dJUdS3NgP5u1pNqK32EZUcPnGSm-suxg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tituslabs-classifications-30: TLPropertyRoot=Nokia; Confidentiality=Company Confidential; Project=None;
x-titus-version: 3.3.8.1
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IjQCNpuwNus9ut70eVa/NdKHRZFgdySinxYJu3y3D1U4nE3lPYIuSMwHG9a/XFxQj98oVjMe94TVxZpWS6Yg5Nt4XE2p2VDl4Foyl8CnNlpH5rIyYlGUk6yJPPAfLkB+nQy0tFePtVqQYbiaxn4XdxRjwz2nGF3Qjl2wyWgXRafGjqYhboQAymYT1nge4M/qJnD6KTyE43W6LRP6nEpIDabn6FYOIO7rQAkk2l8z5m5g
x-originating-ip: [172.19.59.32]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 31 Oct 2011 20:35:12.0908 (UTC) FILETIME=[971B4CC0:01CC980C]
X-Nokia-AV: Clean
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 <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Oct 2011 20:35:17 -0000

Okay..
Then I would hope that the rechartering does not throw out "the baby with the bathwater" and keep MIP6/DSMIP6 related extensions and features still in scope.

-Raj

-----Original Message-----
From: ext Julien Laganier [mailto:julien.ietf@gmail.com] 
Sent: Monday, October 31, 2011 3:33 PM
To: Patil Basavaraj (Nokia-CIC/Dallas)
Cc: jari.arkko@piuha.net; mext@ietf.org
Subject: Re: [MEXT] the future of the MEXT working group

Hi Raj,

This is a rechartering of the WG.

--julien

On Mon, Oct 31, 2011 at 7:47 AM,  <Basavaraj.Patil@nokia.com> wrote:
>
>
> Hi Jari,
>
>
>
> A couple of quick questions:
>
>
>
> 1.       Is this a recharter of the MEXT WG or the formation of a new 
> WG to deal with DMM? If it is the latter I would be concerned that a 
> WG is being formed without going through the IETF BoF process. I 
> realize that DMM was in the scope of the MEXT WG. But proposed new 
> charter pretty much throws everything else w.r.t MIP6/DSMIP6 out of this new WG.
>
> 2.       There needs to be a WG and home for continued work w.r.t 
> improvements to MIP6/DSMIP6 protocol in terms of extensions, 
> deployability improvements etc. The proposed charter does not consider this at all.
>
>
>
> -Basavaraj
>
>
>
> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf 
> Of ext Jari Arkko
> Sent: Friday, October 28, 2011 7:21 AM
> 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
>
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
>
>