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

Romain KUNTZ <rkuntz@us.toyota-itc.com> Tue, 17 May 2011 00:32 UTC

Return-Path: <rkuntz@us.toyota-itc.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 1920DE06A4 for <mext@ietfa.amsl.com>; Mon, 16 May 2011 17:32:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 jMNk4UlKD8Cp for <mext@ietfa.amsl.com>; Mon, 16 May 2011 17:32:45 -0700 (PDT)
Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by ietfa.amsl.com (Postfix) with SMTP id A1012E0686 for <mext@ietf.org>; Mon, 16 May 2011 17:32:43 -0700 (PDT)
Received: from mail-pv0-f171.google.com ([74.125.83.171]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKTdHCKoQDQ+ZbXotkY/RxKQwNliQx7jnK@postini.com; Mon, 16 May 2011 17:32:44 PDT
Received: by mail-pv0-f171.google.com with SMTP id 4so2720pva.16 for <mext@ietf.org>; Mon, 16 May 2011 17:32:42 -0700 (PDT)
Received: by 10.68.30.226 with SMTP id v2mr60883pbh.186.1305592362527; Mon, 16 May 2011 17:32:42 -0700 (PDT)
Received: from saby-lt.paloalto.toyota-itc.com ([206.132.173.18]) by mx.google.com with ESMTPS id j2sm2208pbg.60.2011.05.16.17.32.39 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 May 2011 17:32:41 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: Romain KUNTZ <rkuntz@us.toyota-itc.com>
In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF0258CF9A@ftrdmel0.rd.francetelecom.fr>
Date: Mon, 16 May 2011 17:32:27 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <88AC887C-3529-4945-9EC8-10E2B14E5FB5@us.toyota-itc.com>
References: <843DA8228A1BA74CA31FB4E111A5C46201ADE435@ftrdmel0.rd.francetelecom.fr> <8E09C72DBC577D489F13A71228C0B7BF0258CF9A@ftrdmel0.rd.francetelecom.fr>
To: philippe.bertin@orange-ftgroup.com
X-Mailer: Apple Mail (2.1084)
Cc: 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, 17 May 2011 00:32:46 -0000

Dear Philippe and Pierrick,

On May 10, 2011, at 2:13, <philippe.bertin@orange-ftgroup.com> <philippe.bertin@orange-ftgroup.com> wrote:
> 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.

Thank you for your comments. Some answers below:

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

Whether it represents a huge percentage of the MN communications depends on the deployment scenario & the type of application, but in any case it is true that the systematic use of the tunnel should be pointed in that section. We will add it for the next version. 

> 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"

True, sorry for the confusion. We will correct that. 

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

Right, we will add these potential solutions in the conclusion. 

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

Yes, actually DMI and FAMA explains how to apply this principle to MIPv6, which is why we only focused on PMIPv6 for DMA. 

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

We have scored the dynamic mobility support as "partial" because none of the protocols consider how applications could effectively use such mechanism. Is it a protocol matter? Or an application API matter?

Mobile IPv6 already proposes such dynamic mobility through RFC5014 by allowing to bind a socket to the HoA or the CoA. The DMM solutions makes the problem a little bit more complex because more than 1 HoA is used, but they do not explain whether they should extend RFC5014, or have some specific source address selection mechanism (such as the one you explain below). 

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

Do you have any pointer (draft/paper) where this is explained and that we could reference in our draft?

> Hope this helps ;-)

Yes, thanks again for the input! We will update the draft accordingly.

romain

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