Re: [nemo] RE: RO between MR and CN

Masafumi Watari <watari@sfc.wide.ad.jp> Wed, 13 October 2004 17:28 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 NAA17656 for <nemo-archive@lists.ietf.org>; Wed, 13 Oct 2004 13:28:05 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHmmY-0005dJ-Mf; Wed, 13 Oct 2004 13:19:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHmey-0003jQ-VP for nemo@megatron.ietf.org; Wed, 13 Oct 2004 13:11:33 -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 NAA16454 for <nemo@ietf.org>; Wed, 13 Oct 2004 13:11:31 -0400 (EDT)
Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHmpx-0000qz-Ku for nemo@ietf.org; Wed, 13 Oct 2004 13:22:54 -0400
Received: from localhost (style.sfc.wide.ad.jp [2001:200:0:8801:202:b3ff:fe87:cb44]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 575DC5D09C; Thu, 14 Oct 2004 02:10:56 +0900 (JST)
Date: Thu, 14 Oct 2004 02:08:45 +0900
Message-Id: <20041014.020845.21897134.watari@sfc.wide.ad.jp>
To: pthubert@cisco.com
Subject: Re: [nemo] RE: RO between MR and CN
From: Masafumi Watari <watari@sfc.wide.ad.jp>
In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC2C093A@xmb-ams-337.emea.cisco.com>
References: <7892795E1A87F04CADFCCF41FADD00FC2C093A@xmb-ams-337.emea.cisco.com>
Organization: Keio University
X-Mailer: Mew version 4.1rc2 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a
Content-Transfer-Encoding: quoted-printable
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
Content-Transfer-Encoding: quoted-printable

Hi,

On Wed, 13 Oct 2004 13:34:06 +0200,
"Pascal Thubert (pthubert)" <pthubert@cisco.com> wrote:

> Hi Tania
> 
> I was thinking things like of snooping. MR might intercept all packets to LFN, recognize a HoT and keep it. I remember discussing that with Alex long ago... Anyway, we try to say "don't take that path" as opposed to describe a solution in details.

I don't think its possible to provide RO while keeping the RR function
of MIPv6 untouched.  It would probably require modification of the
packet at MR to use the HoA opt and the routing header for every
packet, if we want to keep the MIPv6 spec as is.

> It seems preferable, for instance, to establish a MR-CR tunnel and exchange fine grained routes for MNPs over the tunnel (route projection).

I think I agree on this.

Masafumi Watari

> Pascal
> 
> > -----Original Message-----
> > From: Tânia Pinto Calçada [mailto:tcalcada@inescporto.pt]
> > Sent: mercredi 13 octobre 2004 13:16
> > To: nemo@ietf.org
> > Cc: Pascal Thubert (pthubert)
> > Subject: RO between MR and CN
> > 
> > Hello,
> > 
> > 
> > 
> > I am interested in route optimization between the MR and the CN. I read the taxonomy draft
> > (draft-thubert-nemo-ro-taxonomy-02.txt), and several other documents related to RO:
> > 
> > draft-jeong-nemo-ro-ndproxy-02.txt
> > 
> > draft-leekj-nemo-ro-pd-02.txt
> > 
> > draft-na-nemo-gen-ro-model-00.txt
> > 
> > draft-na-nemo-path-control-header-00.txt
> > 
> > draft-wakikawa-nemo-orc-00.txt
> > 
> > ROProblem.txt
> > 
> > 
> > 
> > I also read some threads of the NEMO mailing list http://www1.ietf.org/mail-
> > archive/web/nemo/current/index.html <http://www1.ietf.org/mail-
> > archive/web/nemo/current/index.html> , however I am still looking for a document that
> > describes a solution for the RO between the MR and the CN.
> > 
> > 
> > 
> > The taxonomy draft says at section 2:
> > 
> > "A major issue with this form of optimization is that the end-to-end
> > 
> >    principle of the MIPv6 Reverse Routability (RR) test is broken.  The
> > 
> >    RR test is meant to ensure the care-of address (CoA) and the home
> > 
> >    address (HoA) are collocated. With a mobile network, when the MR
> > 
> >    performs RO on behalf of the MNNs, the CoA in BU will be the MR's
> > 
> >    CoA.  Thus, a MNN is reachable via the CoA, but not at the CoA.
> > 
> > 
> > 
> >    Some tricks may be performed on the fly by the MRs but it seems that
> > 
> >    a clean MR-to-CN optimization for Nemo will impact the CN function."
> > 
> > 
> > 
> > Can somebody point the "tricks" that may be performed, or indicate a document that explores
> > this subject?
> > 
> > 
> > 
> > Regards,
> > 
> > Tania Calcada
> 
> 
>