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

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 5 Nov 2003 15:01:33 +0900

Hi,

> Chairs: do we need to recharter?

I will give my own point of view.

First thing first, we have important milestones where no contribution
has been performed so far (MIB) or almost not (threat analysis). I would
like to see these been taken of first, prior to opening the RO debate.

Second, the charter says:

The WG will work on:
- An informational document which specifies a detailed problem
statement for route optimization and looks at various approaches to
solving this problem. This document will look into the issues and
tradeoffs involved in making the network's movement visible to some
nodes, by optionally making them "NEMO aware". The interaction between
route optimization and IP routing will also be described in this
document. Furthermore, security considerations for the various
approaches will also be considered.

Milestones:
Jun 04    Shut down or recharter the WG to solve the route optimization.

Which means we need to work on the problem statement first (including
analysis of the solution space), not on the solutions. So far, I only
saw solutions.

I wish people would commit to the tasks of the WG. I personnaly don't
mind other issues being investigated as long as the agreed objectives
are being taken care of.

Thierry.

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 5 Nov 2003 15:01:33 +0900

Hi,

The WG will work on:

Milestones:

Thierry.

---

From: Chan-Wah NG <[email-masked]>
Date: Wed, 05 Nov 2003 14:58:32 +0800

Hello, Thierry, Pascal,

> analysis of the solution space), not on the solutions. So far, I only

Not really.  Pascal and myself has submitted the RO-taxonomy draft which
is not meant to be solution, but more of a problem-space or
solution-space thingy.  An update would most likely be necessary to
further tune it to the current charter (especially to be in sync with
basic NEMO solution), but as an co-author, I don't foresee the document
to become solution-oriented.  It should stay on the path of describing
the problem space.

Of-course, the focus needs to be on the more eminent work items, which
is why I have not updated the ARO draft after it has expired for so long
;)

/rgds
/cwng

---

From: Chan-Wah NG <[email-masked]>
Date: Wed, 05 Nov 2003 14:58:32 +0800

Hello, Thierry, Pascal,

/rgds
/cwng

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 5 Nov 2003 16:06:46 +0900

Hi ChanWah,

> to become solution-oriented.  It should stay on the path of describing

OK, I haven't had a chance to read the document yet, and I missed the
point it was not a solution document. The analysis of the solution space
will have to cover not only MIP-like solutions as this was aknowledged
during the charter set up.

I wish the discussion could start after Minneapolis.

> is why I have not updated the ARO draft after it has expired for so long

Thanks for your approval in this !

Thierry.

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 5 Nov 2003 16:06:46 +0900

Hi ChanWah,

Thierry.

---

From: Hiroyuki OHNISHI <[email-masked]>
Date: Fri, 07 Nov 2003 18:18:55 +0900

Hi Pascal-san,

Thank you for your comments.

On Tue, 4 Nov 2003 15:24:27 -0000

> is the logical application of HMIP to Nemo. Did you start a discussion
Yes, he is now reviewing this draft.

> The 2 solutions are not opposed, and there's a great value to actually

If I understand "recursive complexity" correctly, this problem will
occur in MAP or root-MR in my solution. I think this problem is not so
heavy compared with that for HA or CN.

As you suggested, "combination" is an interesting approach.  I will
think about that.

> 3) The MAP option should be changed in order to advertise the Nemo
Yes.  To support multi-homing case, this option has to carry multiple
CoAs.  I want to extend capability in next draft.

> be nice to expand 'Data' in fig 9 to show that it can be an actual

This solution can also work for LFN.  I will add the figure that
explaind the data flow from LFN to CN.  

> overloading the MAP option.

I am sorry that fig 6 and the text in 5.1 lead some misunderstanding.
I also assume the case in which MAP is not deployed in the network
because whether MAP is deployed or not depends on the network's services.

"If the MR receives an RA without a MAP option, it recognizes that it is
the root-MR." assumes that situation.

> confirm. So you need to start snooping and it's pretty unclean.
I understand your points.  But if LFN and MR have some security
relationship, I think this method is not so tricky.
When LFN join the mobile network(in this case LFN does not care the
network is mobile network or fixed network), LFN is authenticated by
network.  If the authentication is done by MR, LFN and MR can have some
security association.  This MR is something like FA in Mobile IPv4.

> RRHs (see RRH appendix 1) in the COTi, and then with the packets if the

 Yes. Route optimization has many situations and there are many
solutions
for each cases. But I think we do not need to create the solution which
solves all the situations. Maybe that kind of work takes more time.
 I want to discuss what kind of situations people are thinking about
route optimization. That is also helpful for my clarification.
 As Thierry suggested in his e-mail, I want to contribute to your
RO-taxonomy draft.

-- 
Hiroyuki OHNISHI
NTT Network Service Systems Laboratories
Phone: +81-422-59-4132, Fax: +81-422-60-7460
mailto: [email-masked]

---

From: Hiroyuki OHNISHI <[email-masked]>
Date: Fri, 07 Nov 2003 18:18:55 +0900

Hi Pascal-san,

---

From: "T.J. Kniveton" <[email-masked]>
Date: Sun, 09 Nov 2003 15:15:22 -0800

>like to see these been taken of first, prior to opening the RO debate.
It's fine to talk about RO.. but it MUST not distract from getting the 
working group work done. Thierry points out that the milestones of the 
group that we have committed to, are not getting addressed. If this 
continues, we will have to cut off RO conversation at all on the ML. If 
there is no basic solution and its corresponding support drafts, MIBs, 
etc., there will be nothing to Optimize. This is probably obvious to 
everyone already..

>analysis of the solution space), not on the solutions. So far, I only
There is an analysis of the solution space as pointed out.. But not a 
very good understanding of the requirements..

>mind other issues being investigated as long as the agreed objectives

I agree 100%... of course we are a bit biased toward getting the work 
done. Hopefully others are too!! :)

TJ

---

From: "T.J. Kniveton" <[email-masked]>
Date: Sun, 09 Nov 2003 15:15:22 -0800

TJ