Subject: [nemo] RE: ro draft

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 4 Nov 2003 15:24:27 -0000

Hi Hiroyuki-san:

I believe this draft is important, and it reflects base thoughts that
should be built upon. A solution like this improves the nemo basic
support dramatically. We really need to open the RO discussion(s) ASAP.
Chairs: do we need to recharter?

One high level comment: there are to forms of RO addressed here, the
"HMIP for Nemo" part, which addresses the pinball routing, and the RO
for CN to LFN. I believe that they are orthogonal and should be in
separate drafts.

On HMIP for Nemo:

1) I hope this mechanism gets finally merged into HMIP draft. IMHO, it
is the logical application of HMIP to Nemo. Did you start a discussion
with Hesham?

2) The relation between the MR and the MAP is still a classical MRHA
relationship. Pinball routing is avoided because the MAP is the HA for
all the nested structure. But for the rest, most of the comments in RRH
draft chapter "1.1 Recursive complexity" still apply. In other words,
RRH is still very useful to simplify the HA operation, mostly for the
nesting of tunnels and the computation of the recursive path (5.4.2).
The 2 solutions are not opposed, and there's a great value to actually
combine them.

3) The MAP option should be changed in order to advertise the Nemo
capability

4) The solution should work for LFN since Basic Nemo is used. It would
be nice to expand 'Data' in fig 9 to show that it can be an actual
packet from LFN to CN.

5) I like fig 6, and I believe the MAP should be placed that way (fixed)
as opposed to mobile. So I disagree with some text in 5.1. The MAP
option should be always there in the tree, and it is not the way to
detect that a MR is root. I suggest that you inherit that feature from
the TIO option in RRH draft, which is meant for that, as opposed to
overloading the MAP option.

ON the RO to LFN

We discussed that model on the ML. I mentioned that I do not like it too
much because the RR test is tricked, since the CoA (the MR) is not
collocated with the HoA (the LFN), which is what the test is supposed to
confirm. So you need to start snooping and it's pretty unclean.

Alternates were already discussed, like in Ryuji's initial basic nemo
draft, and the correspondent router model which is an evolution of your
MBG. Maybe we should write that draft :) There are also alternatives
based on nemo aware nodes, for instance having the node send zeroed out
RRHs (see RRH appendix 1) in the COTi, and then with the packets if the
test flies. 

Pascal