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

jouni korhonen <> Tue, 20 December 2011 08:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0324121F84A2 for <>; Tue, 20 Dec 2011 00:52:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HmsXq0IZ6tCO for <>; Tue, 20 Dec 2011 00:52:23 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8C6ED21F84A1 for <>; Tue, 20 Dec 2011 00:52:22 -0800 (PST)
Received: by laah2 with SMTP id h2so2736984laa.31 for <>; Tue, 20 Dec 2011 00:52:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=8b+RIdemcJ7HxDCKLHG3FfAGch59sA9ezBpMhV6a5nE=; b=szHbl9dg7025ETR+5wRG27dD8uY2P+G/zP7/cZBf7cODBaZdxgcIjG2tl5nw0rFvzF 4XLU4vXmZoedl7d/zS6Npu1qwf5CUIioagVneliSLe8i1UbJpJTUzkwysAUU5ruIaVqb LodSXREHYK1m6FaRAbdeZcq1nhuD+4bZTmonI=
Received: by with SMTP id pu3mr843149lab.17.1324371140071; Tue, 20 Dec 2011 00:52:20 -0800 (PST)
Received: from ( []) by with ESMTPS id pf2sm913934lab.1.2011. (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Dec 2011 00:52:18 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen <>
In-Reply-To: <>
Date: Tue, 20 Dec 2011 10:52:15 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Jari Arkko <>
X-Mailer: Apple Mail (2.1084)
Cc: " Laganier" <>,
Subject: Re: [MEXT] The first proposal for the DMM charter
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, 20 Dec 2011 08:52:24 -0000


On Dec 20, 2011, at 10:29 AM, Jari Arkko wrote:

> I think this looks very good, but I would still take into account Pierrick's suggested edits, and I think we have to be far more specific about that "can be transparent to any underlying mobility protocol part", because it confuses me. And per questions on the list, it seems to confuse other people too.

Thanks for the edit. The "transparent" part was definitely poorly worded as it was meant for bettering the use of CoAs.. But wording ended up far too open ended. The new text expresses the original intent clearly.

I also agree with Pierrick's comments that are now also included.

- Jouni

> Suggested edits below. I have sent this version to the IESG and IAB, but I expect that the chairs may produce additional refined versions.
> Distributed Mobility Management (DMM)
> -------------------------------------
> Charter
> Current Status: Active
> Chairs:
>     Julien Laganier <>
>     Jouni Korhonen <>
> Internet Area Directors:
>     Ralph Droms <>
>     Jari Arkko <>
> Internet Area Advisor:
>     Jari Arkko <>
> Mailing Lists:
>     General Discussion:
>     To Subscribe:
>     Archive:  
> 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 based on existing IP mobility
>  protocols, either host- or network-based, such as Mobile IPv6
>  [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and
>  NEMO [RFC3963]. Solutions may also focus specifically
>  on managing the use of care-of versus home addresses in an
>  efficient manner for different types of communications.
>  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,
>  or that support for mobility functions is provided on the network side
>  in all conditions.
>  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: Document best practices for the
>     deployment of existing mobility protocols in a distributed mobility
>     management environment.
> o  Gap Analysis and extensions: identify the limitations in the best current
>     practices with respect to providing the expected functionality.
>  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 ' to the IESG for
>             consideration as an Informational RFC.
>  Mar 2013 - Submit I-D 'Gap Analysis' to the IESG for
>             consideration as an Informational RFC.
>  Mar 2013 - Evaluate the need for further work based on the identified gaps
>             and revise the milestones and/or the charter of the group