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

<pierrick.seite@orange.com> Fri, 04 November 2011 14:46 UTC

Return-Path: <pierrick.seite@orange.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 0F7B821F8B7D for <mext@ietfa.amsl.com>; 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 <mext@ietfa.amsl.com>; 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 <mext@ietf.org>; 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, 04 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: pierrick.seite@orange.com
To: jouni.nospam@gmail.com
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 <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: Fri, 04 Nov 2011 14:46:27 -0000

> -----Message d'origine-----
> De : jouni korhonen [mailto:jouni.nospam@gmail.com]
> Envoyé : vendredi 4 novembre 2011 13:38
> À : SEITE Pierrick RD-RESA-REN
> Cc : jari.arkko@piuha.net; mext@ietf.org
> Objet : Re: [MEXT] the future of the MEXT working group
> 
> Pierrick,
> 
> On Nov 4, 2011, at 11:28 AM, <pierrick.seite@orange.com>
> <pierrick.seite@orange.com> 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.
> >>
> >
> > 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
> 
> 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. 

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