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

Jong-Hyouk Lee <jong-hyouk.lee@inria.fr> Mon, 05 December 2011 09:50 UTC

Return-Path: <jong-hyouk.lee@inria.fr>
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 EA8B221F8B1D for <mext@ietfa.amsl.com>; Mon, 5 Dec 2011 01:50:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
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 v3t6PlszemCk for <mext@ietfa.amsl.com>; Mon, 5 Dec 2011 01:50:22 -0800 (PST)
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id DD45921F8B1C for <mext@ietf.org>; Mon, 5 Dec 2011 01:50:21 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.71,298,1320620400"; d="scan'208";a="133960130"
Received: from dhcp-rocq-134.inria.fr (HELO [128.93.62.134]) ([128.93.62.134]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 05 Dec 2011 10:50:19 +0100
Message-ID: <4EDC93DA.6030309@inria.fr>
Date: Mon, 05 Dec 2011 10:50:18 +0100
From: Jong-Hyouk Lee <jong-hyouk.lee@inria.fr>
Organization: INRIA
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: pierrick.seite@orange.com, mext <mext@ietf.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [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 09:50:23 -0000

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.

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

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

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.

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/