[nemo] Comments on draft-ietf-nemo-ro-space-analysis-00.txt and MIRON

Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Tue, 06 September 2005 13:27 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECdUF-00089q-T2; Tue, 06 Sep 2005 09:27:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECdUE-00089i-Si for nemo@megatron.ietf.org; Tue, 06 Sep 2005 09:27:43 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27053 for <nemo@ietf.org>; Tue, 6 Sep 2005 09:27:39 -0400 (EDT)
Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECdX9-0005DB-33 for nemo@ietf.org; Tue, 06 Sep 2005 09:30:45 -0400
Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id B227B88DDE; Tue, 6 Sep 2005 15:27:28 +0200 (CEST)
Received: from acorde (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 1168988DDE; Tue, 6 Sep 2005 15:27:28 +0200 (CEST)
From: Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
To: Chan-Wah Ng <chanwah.ng@sg.panasonic.com>, Fan Zhao <fanzhao@ucdavis.edu>, Masafumi Watari <watari@kddilabs.jp>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-XwlleIa3hChRw+RLlnu/"
Organization: UC3M
Date: Tue, 06 Sep 2005 15:27:27 +0200
Message-Id: <1126013247.7897.115.camel@acorde>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.2
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: IETF NEMO WG <nemo@ietf.org>, María Calderón <maria@it.uc3m.es>, Ignacio Soto Campos <isoto@it.uc3m.es>, Marcelo Bagnulo <marcelo@it.uc3m.es>
Subject: [nemo] Comments on draft-ietf-nemo-ro-space-analysis-00.txt and MIRON
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

Hi draft authors and all,

I've read the draft and I have some comments regarding MIRON (an
specific solution I'm co-author of). I prefer to send them in a
different e-mail, to keep them separated from the general ones I've
already sent.

In the section 3.2.1, MIRON is cited for the first time, as a mechanism
that decreases the number of Home Agents in the path in a nested
scenario. This is not completely true, since MIRON, as it's currently
specified in draft-bernardos-nemo-miron-00.txt, does not deal with
nested mobile networks. The main aim of MIRON is to provide a RO
mechanisms for LFNs of a NEMO, when they are communicating with CNs,
avoiding the MRHA tunnel with the MR's HA. This is done, by the MR
performing the MIPv6 RO tasks on behalf of the LFNs of its NEMO.

However, nothing prevents this solution to be applied also in a nested
NEMO, avoiding the last tunnel, or even all the tunnels if the MR is
provided somehow with a topologically valid IPv6 address that is
reachable without traversing any HA. This can be done, for example, by
providing to every MR in the nested topology with an IPv6 address that
belongs to the foreign network that the root-MR is visiting (for
example, by using DHCPv6), and enabling (with routing among the MRs and
proxy ND) these address to be directly reachable anywhere in the
Internet (without needing any special node, such a HA, to be deployed in
the infrastructure).

In the section 5.5.1, as far as I've understood, MIRON is classified as
a NEMO RO solution in which the "Mobile Router acts as a Transparent
Proxy". Firstly, for me it is not clear the distinction between "Mobile
Router as a Proxy" and "Mobile Router as a Transparent Proxy", since it
is said that - in the "Mobile Router as a Proxy" - the Mobile Router
uses standard Mobile IPv6 Route Optimisation procedure to bind the
address of a Mobile Network Node to the MR's CoA, and that's exactly
which MIRON does. Nevertheless, this "proxy" functionality requires the
MR to generate also the Return Routability signalling on behalf of the
LFNs, not only the Binding Updates messages. Besides, the packets
sent/received by the LFNs have to be modified, since they would be sent
by the CN addressed to the MR's CoA (carrying a type 2 RH), and the
packets sent by the LFN have to have the MR's CoA as their source
address (carrying a Home Address Destination Option).

OTOH, it is said that the "Mobile Router as a Transparent Proxy" works
by modifying MIPv6 RO packets sent to VMNs. This is not possible (at
least easily), since the HoTI and HoT messages sent by the VMNs have to
be sent using IPsec ESP, so the MR cannot modify these packets to set
its CoA as the VMN's CoA.

I'd suggest to remove the "Mobile Router as a Transparent Proxy" section
and rewrite the "Mobile Router as a Proxy" section (I can provide some
text for discussion if you want).

The main aim and advantage of MIRON is providing a NEMO RO mechanism
suited for LFNs (that is, IPv6 nodes that do not have/use any mobility
support), by using the Mobile IPv6 RO already defined mechanism and,
therefore, not requiring any change on the operation of LFNs and CNs.

Thanks a lot.

Kind Regards,

Carlos J.

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: BFF1 7C7A 6AA7 BCE3 885A  4DF1 ED0C 5952 BF89 B974