Re: [MEXT] Comments on "draft-seite-mext-dma-00"

<pierrick.seite@orange.com> Mon, 05 December 2011 11:11 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 B127D21F8AF0 for <mext@ietfa.amsl.com>; Mon, 5 Dec 2011 03:11:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
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 4rnQ1SMKLR2R for <mext@ietfa.amsl.com>; Mon, 5 Dec 2011 03:10:57 -0800 (PST)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB5621F8ACC for <mext@ietf.org>; Mon, 5 Dec 2011 03:10:55 -0800 (PST)
Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9CEE46DC002; Mon, 5 Dec 2011 12:21:32 +0100 (CET)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 96C6E6DC001; Mon, 5 Dec 2011 12:21:32 +0100 (CET)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Dec 2011 12:10:54 +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: Mon, 05 Dec 2011 12:10:52 +0100
Message-ID: <843DA8228A1BA74CA31FB4E111A5C46202127D29@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <4EDC93DA.6030309@inria.fr>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Comments on "draft-seite-mext-dma-00"
Thread-Index: AcyzM0zgRsylgXHyROOOMmXiXvOlJgAAxTbg
References: <4EDC93DA.6030309@inria.fr>
From: pierrick.seite@orange.com
To: jong-hyouk.lee@inria.fr, mext@ietf.org
X-OriginalArrivalTime: 05 Dec 2011 11:10:54.0079 (UTC) FILETIME=[8E2140F0:01CCB33E]
Subject: Re: [MEXT] Comments on "draft-seite-mext-dma-00"
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: Mon, 05 Dec 2011 11:11:10 -0000

Hello,

Thanks for the review. Please see inline.

Pierrick

> -----Message d'origine-----
> De : Jong-Hyouk Lee [mailto:jong-hyouk.lee@inria.fr]
> Envoyé : lundi 5 décembre 2011 10:50
> À : SEITE Pierrick RD-RESA-REN; mext
> Objet : Comments on "draft-seite-mext-dma-00"
> 
> Dear authors,
> 
> I read the draft "draft-seite-mext-dma-00" and have comments/questions:
> 
> 1. The mobility support described in the draft seems for client
> mobility. In other words, it's hard to apply the suggested dynamic
> mobility anchoring scheme into a node dedicated for continuous services
> to clients.

Actually, the solution applies to network based mobility management. The I-D describes the deployment of PMIPv6 in a distributed fashion.

> 
> 2. In the suggested dynamic mobility anchoring scheme, data packets of a
> communication session established in a previous access network (MAR1) is
> forwarded from MAR1 to the current MAR. This data packet forwarding must
> be continuous as the address used in the communication session is
> continuously used. Note that the MN is not only the communication
> session initiator, but the CN could be. 

Right, we have still to address incoming communications.

The data packet forwarding must
> impact the whole network performance as the session duration is longer,
> session is heavier, or mobility is higher.
> 
> 3. Since the suggested dynamic mobility anchoring scheme allows the MN
> to send/receive data packets having different network prefix compared
> with that of the current access network, I'm not sure if the suggested
> one properly works in existing network security mechanisms. For
> instance, authors should address conflicts over ingress filtering
> mechanisms.
> 

Agreed.

> 4. Since the suggested dynamic mobility anchoring scheme allows the MN
> to establish a communication session with its CN via a new address
> obtained in a new network. In other words, 1) the MN establishes its
> communication session with the CN via HoA1 at MAR1; 2) when the MN moves
> to MAR2, it possibly establishes a new communication session with the CN
> via HoA2 at MAR2 in order to avoid the overhead of data packet
> forwarding. This means that even if the MN wants to keep the same
> communication session with the CN, it must be re-establishes, i.e.,
> making a new communication session with the CN. 

No, in that case session continuity is ensures as per PMIP where MAR1 and MAR2 play respectively the LMA and MAG role. 

In addition, making the
> new communication session requires security operations again between the
> MN and CN. Authors should think the cost in handovers: continuous
> communication session maintaining vs. new session establishment.
> 

Actually, I'm not sure to understand your point...

> 5. Could you describe little bit more about the entity storing the
> session DB for all MNs? Hummm...we're talking about DMM, 
but the entity is a centralized entity in an architectural view; all MARs contacts for
> MN's session information.
> 

Here we are going on the separation of the control plane and data plane. The data plane is distributed while a part of the data plane is centralized for localization purpose.  Several approaches are possible and have been described in http://tools.ietf.org/html/draft-yokota-dmm-scenario-00: fully distribution and partially distribution are both possible. With Fully distributed MM, both control and data planes are distributed while partial distribution focuses on distribution on the data plane (arguing that The volume of data traffic is much higher than that of control traffic). MN's localisation is an issue in fully distributed mobility architectures; DHT or flooding are possible solutions but control/data plane separation allows more simple localization scheme. I think it is worth considering control/data plane separation in a first approach, while I agree that the fully distribution is more optimal.

> Thanks.
> 
> --
> IMARA Team, INRIA, France
> Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
> 
> #email: jong-hyouk.lee (at) inria.fr || hurryon (at) gmail.com
> #webpage: http://sites.google.com/site/hurryon/