Re: [nemo] RO: what have we learnt so far?

Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Tue, 09 November 2004 12:15 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 HAA17424 for <nemo-archive@lists.ietf.org>; Tue, 9 Nov 2004 07:15:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRUrp-0000aB-3U; Tue, 09 Nov 2004 07:12:57 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRUod-0008LU-6n for nemo@megatron.ietf.org; Tue, 09 Nov 2004 07:09:40 -0500
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 HAA16844 for <nemo@ietf.org>; Tue, 9 Nov 2004 07:09:35 -0500 (EST)
Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRUpM-00013k-8r for nemo@ietf.org; Tue, 09 Nov 2004 07:10:25 -0500
Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id CDCE73018B; Tue, 9 Nov 2004 13:09:05 +0100 (CET)
Received: from localhost (luciernaga.it.uc3m.es [163.117.140.159]) by smtp03.uc3m.es (Postfix) with ESMTP id 6DC76301F7; Tue, 9 Nov 2004 13:09:05 +0100 (CET)
Subject: Re: [nemo] RO: what have we learnt so far?
From: Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, cwng@psl.com.sg
In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC413C2A@xmb-ams-337.emea.cisco.com>
References: <7892795E1A87F04CADFCCF41FADD00FC413C2A@xmb-ams-337.emea.cisco.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-LJ/pHCU/VFsBnpHx4utA"
Organization: Universidad Carlos III de Madrid
Message-Id: <1100002144.2453.58.camel@acorde>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6
Date: Tue, 09 Nov 2004 13:09:05 +0100
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86
Cc: IETF NEMO WG <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

Dear Pascal,

	I've read the draft and I've some comments.

	First, thanks for the new version of the draft. I think that this new
version is much better than the previous one and it's closer to the
charter requirements.

	Here they are my comments (I also include some minor typos I've found):

	- Section 2.2. It says "effects of sub-optimal routing with NEMO Basic
Support is amplified" I think it should be "effects of
   sub-optimal routing with NEMO Basic Support are amplified"
	- Section 2.4. The title is "Communications within a Mobile Networks".
I think it should be "Communications within a Mobile Network"
	- Section 3.2. I'd remove any reference to a specific proposed solution
in the text, like [10] or [11], as IMHO in this section you are
describing the solution space, but without referring to any specific
proposed solution. IMHO, the actual structure of the draft is fine, it
first presents the problem space, then the solution space and finally,
in the annex, proposed solutions are presented, mapped to the taxonomy
presented in the solution space.
	- Section 3.2. It says "through dome". I think it should be "through
some"
	- Section 3.3. I'd would add a bullet with solutions based on Ad-Hoc
routing in the nested NEMO (e.g. something similar to the solution
described in draft-clausen-nemo-ro-problem-statement-00.txt). IMHO,
providing a globally reachable IPv6 address to every MR in the nested
topology (to be used as MR's CoA) and then using an Ad-Hoc routing
protocol to route the packets within the nested NEMO would be a possible
solution to avoid the encapsulation due nesting.
	- Section 4.1.4. It says "In general, it is desirable to keep the
number of nodes that require new functionalities to be kept as small as
possible". I think it should be "In general, it is desirable to keep the
number of nodes that require new functionalities as small as possible"

	And a last comment/question: you said in the mail, that MIRON reference
is still missing... what do you mean? Because in your draft is reference
[15]

	Kind Regards,

	Carlos J.

El lun, 08-11-2004 a las 12:52, Pascal Thubert (pthubert) escribió:
> Hi:
> 
> As you know, the RO problem has been around since NEMO stated, and so
> have been related drafts. 
> 
> As a group, we have focussed on delivering basic support, but still
> people could not help working on RO. And we learnt quite a few things
> overtime.
> 
> - We have distinguished various problems to be addressed, and
> categorized the (tenths of) solutions that were proposed. We also have
> clues about the specific pro/cons of those numerous solutions.
> 
> - We have found that before optimizing the tunnels and data path of a
> nested tree of MRs, we should make sure that we build the tree and that
> the tree is optimized in shape in the first place. We also know that a
> MR might not want to attach anywhere and that some clues might be
> needed.
> 
> We can not just make as if we were 3 years ago, can we? I believe that
> we can and we should give more food for thought then just "what's the
> problem here?".
> 
> This is why the taxonomy is now built in 3 major parts, plus appendix.
> The problem statement is obviously the 1st of the 3 major parts. The
> bestiary of the solutions types comes next, and finally the pro/cons.
> The specific solutions are introduced only in appendix. Some refs are
> still missing (like MIRON, sorry), but then again, it's a work in
> progress.
> 
> Pascal
-- 
Carlos Jesús Bernardos Cano - http://www.netcoms.net
GPG FP: 58C3 4227 AF8D 01D4 5A09  A617 E6F2 B23E DAD6 AA40