Re: [nemo] NEMO RO problem draft submit

Alexandru Petrescu <Alexandru.Petrescu@motorola.com> Mon, 18 October 2004 17:35 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04885 for <nemo-archive@lists.ietf.org>; Mon, 18 Oct 2004 13:35:25 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJb0j-0000na-FI; Mon, 18 Oct 2004 13:09:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJabi-0005tl-Vk for nemo@megatron.ietf.org; Mon, 18 Oct 2004 12:43:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26371 for <nemo@ietf.org>; Mon, 18 Oct 2004 11:44:27 -0400 (EDT)
Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJZsT-0002wm-SR for nemo@ietf.org; Mon, 18 Oct 2004 11:56:55 -0400
Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i9IFiAMO023237; Mon, 18 Oct 2004 08:44:10 -0700 (MST)
Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i9IFhp6I022475; Mon, 18 Oct 2004 10:43:52 -0500
Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id C243388CF7E; Mon, 18 Oct 2004 17:44:07 +0200 (CEST)
Message-ID: <4173E4C2.2090609@motorola.com>
Date: Mon, 18 Oct 2004 17:44:02 +0200
From: Alexandru Petrescu <Alexandru.Petrescu@motorola.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: 박기용_건국대 <kypark@cclab.konkuk.ac.kr>
Subject: Re: [nemo] NEMO RO problem draft submit
References: <200410180717.i9I7H1pY001536@phaenicia.ucdavis.edu> <001e01c4b50e$f230cab0$a486fccb@nbclearsky>
In-Reply-To: <001e01c4b50e$f230cab0$a486fccb@nbclearsky>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enigADB408C39E59F79F4FB3DA5F"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Content-Transfer-Encoding: 8bit
Cc: nemo@ietf.org
X-BeenThere: nemo@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NEMO Working Group <nemo.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:nemo@ietf.org>
List-Help: <mailto:nemo-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=subscribe>
Sender: nemo-bounces@ietf.org
Errors-To: nemo-bounces@ietf.org

박기용_건국대 wrote:
> I already read a draft about the solution of NEMO RO problem using 
> Prefix Delegation Mechanism in IPv6 You can access it at : 
> http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/draft-leekj-nemo-ro-pd-01.txt
> 
> I think it is abolutely correct solution of NEMO RO problem. Any 
> other opinion, it will be great to me.

Hello Kiyong Park.

IMHO it is debatable whether that PD with Neighbour Discovery solution
is a correct solution for the NEMO RO problem since we don't know
exactly what the RO problem is.

If the RO problem is that MN-behind-MR communication to CN goes through
HA (instead of directly) then yes, that PD solution is solving it.  If
on the other hand the problem is that LFN-behind-MR communication to CN
goes through HA (instead of directly) then no, that PD solution is not
solving it, because that draft does not describe how MR performs RO on
behalf of LFN (LFN does not do Mobile IPv6).  In my understanding.

Alex