Re: [MEXT] Fwd: New Version Notification fordraft-kuntz-dmm-summary-00.txt

<philippe.bertin@orange-ftgroup.com> Tue, 10 May 2011 09:13 UTC

Return-Path: <philippe.bertin@orange-ftgroup.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 74431E07D1 for <mext@ietfa.amsl.com>; Tue, 10 May 2011 02:13:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level:
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewhxeEQjcmgg for <mext@ietfa.amsl.com>; Tue, 10 May 2011 02:13:30 -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 48367E06EE for <mext@ietf.org>; Tue, 10 May 2011 02:13:29 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 35A618B800F; Tue, 10 May 2011 11:14:05 +0200 (CEST)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 2EE308B800B; Tue, 10 May 2011 11:14:05 +0200 (CEST)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 May 2011 11:13:27 +0200
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: Tue, 10 May 2011 11:13:25 +0200
Message-ID: <8E09C72DBC577D489F13A71228C0B7BF0258CF9A@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46201ADE435@ftrdmel0.rd.francetelecom.fr>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [MEXT] Fwd: New Version Notification fordraft-kuntz-dmm-summary-00.txt
Thread-Index: AcwLi+EdN/RJwfyfR++mXiC1KOM+vAC0lOeQACLsqZA=
References: <843DA8228A1BA74CA31FB4E111A5C46201ADE435@ftrdmel0.rd.francetelecom.fr>
From: philippe.bertin@orange-ftgroup.com
To: rkuntz@us.toyota-itc.com
X-OriginalArrivalTime: 10 May 2011 09:13:27.0539 (UTC) FILETIME=[85BAD430:01CC0EF2]
Cc: philippe.bertin@orange-ftgroup.com, mext@ietf.org
Subject: Re: [MEXT] Fwd: New Version Notification fordraft-kuntz-dmm-summary-00.txt
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: Tue, 10 May 2011 09:13:31 -0000

Dear Romain,

Thank you for this draft which synthesizes well the different requirements/proposals for DMM and help to further analyze/compare them.
Please find below some comments we shared with Pierrick when reviewing the draft, most of them being related to DMA.


1) section 2.1 Issues of centralized mobility solutions: it may be also stated that a huge percentage of MN communications are made in a fixed/nomadic situation and that existing mobility solutions systematically rely on HA/tunnels mgt, whithout considering if the MN is really moving or not (except when it is on its Home link, which in fact is very rarely happening). This statement is further described in http://tools.ietf.org/html/draft-chan-distributed-mobility-ps-00, section "4.4. Need versus no need for mobility support". 

2) the following sentence sounds like if DMA would have combined FAMA and DMI, whereas it was designed prior to FAMA: "In Dynamic Mobility Anchoring (DMA) proposed in [I-D.seite-netext-dma], the best ideas of FAMA and DMI are combined"

3) current DMA does not address the reachability issue but, as Pierrick indicated in a previous discussion on the ML, DMA allows the MN to manage multiple addresses (or prefixes) simultaneously, which can be anchored in different MAR; thus nothing prevent DMA to maintain one address (or prefix) in a given MAR dedicated to anchor incoming communications, like it would be done in a centralized HA maintaining global Home addresses. E.g., DNS resolution will provide this "global home address" whereas MN initiated communication flows will be anchored on different prefixes/addresses. We should update the draft with such a feature.

Additionally, other solutions to answer reachability issue are given in http://tools.ietf.org/html/draft-yokota-dmm-scenario: 1) use Distributed Hash Table (DHT) to select the correct HA or 2) multiple delivery to the Has.
Their application to DMA may be analysed.

4) As you pointed out, current draft-seite-netext-dma reuse PMIP. However, DMA is meant to describe the principle of dynamic and distributed mobility anchoring, and, as such, is not tied to the mobility protocol (providing that it is an anchor based mobility protocol). Actually, the same principle of dynamic and distributed mobility can leverage on MIP. We give clues for such a deployment in http://tools.ietf.org/html/draft-liu-distributed-mobility (section 6.1). 

5) In the conclusion it is not clear what you mean by "partial" dynamic mobility support. The basic idea of DMA, is to provide a fully dynamic mechanism in order to forward/tunnel only flows requiring such a mobility support in the network. 
I am convinced that the dynamic property is more important than the distributed one. 

6) The conclusion states that "it is still unclear how applications could select the desired source address for their sessions". For this issue we consider the use of IPv6 address states by automatically adapt their relative lifetime: when in the "Active/Preferred state", the address can be used for any new flow/transport connection; when in the "Active/Deprecated" state, the address shall be used only to maintain existing communication sessions. Then, prefix/addresses allocated in previous MAR shall be kept "active/deprecated" in order to avoid their use for new communications/flows.


Hope this helps ;-)

Philippe and Pierrick

> -----Message d'origine-----
> De : mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] De la part de
> Romain KUNTZ
> Envoyé : vendredi 6 mai 2011 03:20
> À : mext@ietf.org
> Cc : Ryuji WAKIKAWA; Divya Sudhakar; Lixia Zhang
> Objet : [MEXT] Fwd: New Version Notification fordraft-kuntz-dmm-summary-
> 00.txt
> 
> Dear all,
> 
> We have submitted a summary draft of the DMM activities in MEXT. I  hope
> you will find it useful and that it will trigger some more discussions on
> that topic. The draft is available here:
> 
> http://tools.ietf.org/html/draft-kuntz-dmm-summary-00
> 
> Thank you,
> Romain Kuntz
> 
> 
> Begin forwarded message:
> 
> > From: internet-drafts@ietf.org
> > Date: May 5, 2011 18:15:37 PDT
> > To: rkuntz@us.toyota-itc.com
> > Cc: lixia@cs.ucla.edu, ryuji@us.toyota-itc.com, rkuntz@us.toyota-itc.com,
> divyasudhakar@ucla.edu
> > Subject: New Version Notification for draft-kuntz-dmm-summary-00.txt
> >
> > A new version of I-D, draft-kuntz-dmm-summary-00.txt has been
> successfully submitted by Romain Kuntz and posted to the IETF repository.
> >
> > Filename:	 draft-kuntz-dmm-summary
> > Revision:	 00
> > Title:		 A Summary of Distributed Mobility Management
> > Creation date:	 2011-05-05
> > WG ID:		 Individual Submission
> > Number of pages: 20
> >
> > Abstract:
> >   As stated in the MEXT charter, the working group will "work on
> >   operational considerations on setting up Mobile IPv6 networks so that
> >   traffic is distributed in an optimal way".  This topic, referred to
> >   as Distributed Mobility Management (DMM), has motivated the
> >   submission of multiple problem statement and solution drafts.  This
> >   document aims at summarizing the current status of the DMM effort, in
> >   order to initiate more discussions within the working group.
> >
> >
> >
> >
> > The IETF Secretariat
> 
> 
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext