Re: [MEXT] The first proposal for the DMM charter

jouni korhonen <jouni.nospam@gmail.com> Thu, 22 December 2011 06:54 UTC

Return-Path: <jouni.nospam@gmail.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 127ED21F8BB3 for <mext@ietfa.amsl.com>; Wed, 21 Dec 2011 22:54:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.98
X-Spam-Level:
X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 xVLtXoXJIZNz for <mext@ietfa.amsl.com>; Wed, 21 Dec 2011 22:54:14 -0800 (PST)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id F395221F8B8F for <mext@ietf.org>; Wed, 21 Dec 2011 22:54:13 -0800 (PST)
Received: by werb14 with SMTP id b14so3680840wer.31 for <mext@ietf.org>; Wed, 21 Dec 2011 22:54:08 -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=Lg4NwgDvVvjSbnr/JR1WgvoK1vCpU70IEci8eCwWk3A=; b=rkiSKcq1eDp7qAoITEBn91cvDPhVhRZmgDVCwIsCUSjlrdWhuvXe+zDCXx4uY6asxh 9rMUy+VMHlPfhm9LtJAjz7afcw226v6aqHevrqxBE/iB8FvUyyOB+5cLhUakXsORHlL/ t483yh2OTR4YSTSPVo+E2QgVGxG6qfYza4yNA=
Received: by 10.216.136.204 with SMTP id w54mr10658688wei.44.1324536848790; Wed, 21 Dec 2011 22:54:08 -0800 (PST)
Received: from [10.255.137.69] ([192.100.123.77]) by mx.google.com with ESMTPS id ep16sm8519283wbb.21.2011.12.21.22.54.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Dec 2011 22:54:06 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: jouni korhonen <jouni.nospam@gmail.com>
In-Reply-To: <4EF0D9D5.2070609@ericsson.com>
Date: Thu, 22 Dec 2011 08:54:03 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <C1D260D7-AEC0-4A69-B5AD-1D389BF53A74@gmail.com>
References: <8CAD2158-A0AC-4767-9DDC-857536E26DC6@gmail.com> <4EF0D9D5.2070609@ericsson.com>
To: Conny Larsson <conny.larsson@ericsson.com>
X-Mailer: Apple Mail (2.1084)
Cc: "julien.ietf@gmail.com Laganier" <julien.ietf@gmail.com>, Jari Arkko <jari.arkko@piuha.net>, "mext@ietf.org" <mext@ietf.org>
Subject: Re: [MEXT] The first proposal for the DMM charter
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: Thu, 22 Dec 2011 06:54:15 -0000

Conny,

On Dec 20, 2011, at 8:54 PM, Conny Larsson wrote:

> Hi Jouni, Julien
> 
> I believe the charter looks good but I would like to ask you if deployment scenarios are covered by the charter or not (I'm thinking of a Informational RFC)?

Not a bad idea but I am a bit reluctant to expand milestones at the moment. Deployment scenarios that are doable using existing technologies deployment scenarios could be documented as part of the best current practices. Obvious deployment scenarios that are seen essential but not doable using existing machinery could go into the gap analysis.

> Let me be a bit more specific. When discussing DMM (in a 3GPP perspective) with people I  get the impression that many operators are interested in the topic but that they have very few peering points. They are not always interested (or they do not see the need) in deploying more peering points since they are expensive. Perhaps the reason for this is related to the current hierarchical architecture and will change with a more distributed architecture.

Distributing mobility and more aggressive use of CoAs does not necessarily imply new peering points. Just being able to avoid few central aggregating gateways (i.e. those nodes that do far more than just packet forwarding) or make use of possible local resources (e.g. some local content caches) could be of significant help already.

> So what do you think? Is there a need for this kind of document?

We could consider that when we actually know more of our current state of the art and possible new enhancements. That would be around rechartering..? Before that I encourage to contribute relevant deployment scenarios to the best current practices and gap analysis documents.

- Jouni

> 
> Best Regards
> Conny
> 
> 
> On 2011-12-14 09:54, jouni korhonen wrote:
>> Folks,
>> 
>> We have been working on a charter text from DMM based on the initial goal setting and the input we received during the Taipei meeting. Note that this is the first draft and now we are soliciting for input.
>> 
>> - Jouni&  Julien
>> 
>> 
>> -------------------------------------------------------------------------
>> 
>> Distributed Mobility Management (DMM)
>> -------------------------------------
>> 
>> Charter
>> 
>>  Current Status: Active
>> 
>>  Chairs:
>>      Julien Laganier<julien.ietf@gmail.com>
>>      Jouni Korhonen<jouni.nospam@gmail.com>
>> 
>>  Internet Area Directors:
>>      Ralph Droms<rdroms.ietf@gmail.com>
>>      Jari Arkko<jari.arkko@piuha.net>
>> 
>>  Internet Area Advisor:
>>      Jari Arkko<jari.arkko@piuha.net>
>> 
>>  Mailing Lists:
>>      General Discussion: mext@ietf.org
>>      To Subscribe:       https://www.ietf.org/mailman/listinfo/mext
>>      Archive:            http://www.ietf.org/mail-archive/web/mext
>> 
>> Description of Working Group:
>> 
>>   The Distributed Mobility Management (DMM) working group specifies IP
>>   mobility, access network and routing solutions, which allow for
>>   setting up IP networks so that traffic is distributed in an
>>   optimal way and does not rely on centrally deployed anchors to manage
>>   IP mobility sessions. The distributed mobility management solutions
>>   aim for transparency above the IP layer, including maintenance of
>>   active transport level sessions as mobile hosts or entire mobile
>>   networks change their point of attachment to the Internet.
>> 
>>   The protocol solutions should be enhancements to existing IP mobility
>>   protocols, either host- or network-based, such as Mobile IPv6
>>   [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and
>>   NEMO [RFC3963]. Alternatively, the distributed mobility management
>>   solution can be transparent to any underlying IP mobility protocol.
>>   Although the maintenance of stable home address(es) and/or prefix(es)
>>   and upper level sessions is a desirable goal when mobile hosts/routers
>>   change their point of attachment to the Internet, it is not a strict
>>   requirement. Mobile hosts/routers should not assume that IP
>>   addressing including home address(es) and/or home network prefix(es)
>>   remain the same throughout the entire upper level session lifetime.
>> 
>>   The distributed mobility management solutions primarily target IPv6
>>   Deployment and should not be tailored specifically to support IPv4,
>>   in particular in situations where private IPv4 addresses and/or NATs
>>   are used. At least IPv6 is assumed to be present in both the mobile
>>   host/router and the access networks. Independent of the distributed
>>   mobility management solution, backward compatibility must be
>>   maintained. If the network or the mobile host/router do not support
>>   the distributed mobility management enabling protocol, nothing should
>>   break.
>> 
>> Work items related to the distributed mobility management include:
>> 
>>   o Solution Requirements: Define precisely the problem of distributed
>>     mobility management and identity the requirements for a distributed
>>     mobility management solution.
>> 
>>   o Best practices and Gap Analysis: Document best practices for the
>>     deployment of existing mobility protocols in a distributed mobility
>>     management environment and identify the limitations of each such
>>     approach with respect to fulfillment of the solution requirements.
>> 
>>   o If limitations are identified as part of the above deliverable,
>>     specify extensions to existing protocols that removes these
>>     limitations within a distributed mobility management environment.
>> 
>> Goals and Milestones:
>> 
>>   Aug 2012 - Submit I-D 'Solution Requirements' as a working
>>              group document. To be Informational RFC.
>>   Aug 2012 - Submit I-D 'Best practices and Gap Analysis' as a working
>>              group document. To be Informational RFC.
>>   Nov 2012 - Evaluate the need for additional working group document(s)
>>              for extensions to fill the identified gaps.
>>   Jan 2013 - Submit I-D 'Solution Requirements' to the IESG for
>>              consideration as an Informational RFC.
>>   Jan 2013 - Submit I-D 'Best practices and Gap Analysis' to the IESG for
>>              consideration as an Informational RFC.
>>   Mar 2013 - Conclude the working group or re-charter.
>> 
>> 
>> _______________________________________________
>> MEXT mailing list
>> MEXT@ietf.org
>> https://www.ietf.org/mailman/listinfo/mext
>> 
> 
>