[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/
- [MEXT] Comments on "draft-seite-mext-dma-00" Jong-Hyouk Lee
- Re: [MEXT] Comments on "draft-seite-mext-dma-00" pierrick.seite
- Re: [MEXT] Comments on "draft-seite-mext-dma-00" Jong-Hyouk Lee