Subject: RE: Multiple address in RH type 2 (was Re: [nemo] RO taxonomy)

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 11 Nov 2004 14:17:30 +0100

> 
> Pascal Thubert (pthubert) wrote:
> 
> > Well, there is a difference: we can (and must) put a restriction in
the
> > usage of the extended RH2. And that restriction is to go down the
nested
> > tree only. In particular if the source routed path in the RH2 is
strict
> > (not loose), we can force that the next entry in the RH is actually
part
> > of an MNP of the MR that processes the RH2. This is explicitly what
the
> > RRH draft says.
> 
> How would the strict restriction work when the mobile network (imagine
a
> large cruise ship) has one or more layers of regular routers, and then
> the passangers arrive with their PANs that have their MRs?
> 
> A strict routing check assumes that all the routers are listed.
> 

Oups, sorry Erik I realize I never answered that. The way we have done
it for strict is exactly following the pseudo code in the RRH draft (we
need a connected route to the next hop, and that requires a chain of RRH
compliant hops). In loose mode, we use a route lookup. Like, we must
have a route to the next entry in the RH2 that is not a NEMO (default?)
route.

I could write book ;) but since RRH is not being considered by the GW
for the time being, there's no point wasting people's time. But if you
wish, I'd be glad to discuss that. There's a lot more to RRH then meets
the eye.

The world did not freeze the day NEMO as a WG decided to focus on basic.
We as a WG could afford some catching now. In fact, that is one goal if
the taxonomy draft, and dismissing that could be a huge waste.

Pascal

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Nov 2004 16:56:34 +0100

> The world did not freeze the day NEMO as a WG decided to focus on

Oh didn't it :-)

> We as a WG could afford some catching now. In fact, that is one goal
> if the taxonomy draft, and dismissing that could be a huge waste.

Pascal, the taxonomy draft-03 is a nice piece of work.  I had a detalied
look over it yesterday and wanted to make a detalied review later, but
since you talk about it now, may I give high-level remarks.

The WG item on problem statement is good to be short 3-5 pages IMHO.
How about deciding in advance about the max number of pages and stick
to that.

The current draft could be shortened by removing entirely the
comparative analysis of the various solutions, maybe that could be a
separate draft.  IMHO only the abstract and the 1st section are exactly
problem statement.

If this is done, then it is no longer a "taxonomy" draft, it becomes
more of a "problem statement" draft.

The draft could be further shortened by reducing the big
encapsulation/long path illustrations from 3 MR's to 2.  IT is enough
for a reader to interpret the meaning of it by just using 1 and 2
example MR's.   The logical extension from one and two to $n$ happens in
the reader's mind as easy as the extension from one and two and three to
$n$ and the description is shorter if only two MR's.  This reduction
also reduces the risk of introducing spec errors.  Such an error is
already there: HAofMR5 is talked about but not pictured; instead MR6 is
pictured but not talked about.

Second, there is a specific problem of NEMO Basic Support named
"cross-over" tunnels, mentioned at http://tinyurl.com/4z4kc see Section
B.6; there it is shown how a specific mobility configuration (HA in the
moving network and moving networks exchanging their positions) is not
supported by NEMO BAsic Support.  I see this mobility configuration
problem as an important problem on the protocol itself, I mean the
protocol does not support such a configuration.  In addition, there may
be other similar mobility configurations that are not supported by NEMO
Basic Support.

Finally, about the current draft taxonomy 03 and Security
Considerations.  There are important Security problems when discussing
RO for NEMO; at the same time many security aspects of various solutions
have been discussed, but I'd keep these out of this document.  In the WG
RO item I'd only mention a unique Security Considerations section that
only says what are the security risks of having a prefix at CN.  Not to
say the draft does not do it, but that the draft has too many security
risks described, each attach to a single solution; it's too scattered.

Alex

---

From: Chan-Wah NG <[email-masked]>
Date: Fri, 12 Nov 2004 06:51:37 +0800

Hello Alex,

Thank you for reading the draft immediately after the WG session, and I
appreciate you comments.  It is these comments that allow us to improve
our work.

If I recall, you were the one who referred us to the WG charter. 
Contents of version -03 of the ro-taxonomy draft is exactly tailored
according to what is spelt out in the WG charter. (Unless the WG charter
is once again changed and I wasn't aware of ....) 

Now people are complaining the draft is too long.

>From the WG charter, we are not required to come up with a *short*
problem statement draft.  We are, however, required to come up with a
*detailed* problem statement *and* looks at various approaches to
solving the problem. 

I am not against a concise problem statement draft that is short and
sweet.  I like that too.  In fact, I would say that the problem
statement section of the draft-ro-taxonomy is quite short (3-5 pages, as
you and Hesham suggested).  If the WG changes the charter to reflect
that, I will gladly copy and paste the appropriate sections from
ro-taxonomy-03.txt to a new short problem statement draft.

However, IMHO, we should not remove the WG charter on coming up with an
informational document on ro solution space analysis.  It is a useful
document that records the WG experiences on the route optimization
solution space.  If the WG wants a short problem statement draft, then
let's have a WG problem statement draft *and* a WG
solution-space-analysis draft.

About your last comment on secuirty risks, I agree we should have a
general security consdierations text that is not solution-space
specific.  I will add this in -04.  But, I will not remove the security
risks discussions specific to each approach.  Again, as pointed out by
the WG charter (the charter that I know of, anyway): "security
considerations for the various approaches will also be considered".

/rgds
/cwng

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Nov 2004 06:51:28 +0100

Chan-Wah NG wrote:
> according to what is spelt out in the WG charter. (Unless the WG
> charter is once again changed and I wasn't aware of ....)
> 

I agree.  The Charter says too about discussing analysis of solution
space in the Problem draft.  I realize that is hard to do though.

>  *detailed* problem statement *and* looks at various approaches to 

I agree.

> statement section of the draft-ro-taxonomy is quite short (3-5 pages,
> as you and Hesham suggested).  If the WG changes the charter to
> reflect that, I will gladly copy and paste the appropriate sections
> from ro-taxonomy-03.txt to a new short problem statement draft.
> 
> However, IMHO, we should not remove the WG charter on coming up with
> an informational document on ro solution space analysis.  It is a
> useful document that records the WG experiences on the route
> optimization solution space.  If the WG wants a short problem
> statement draft, then let's have a WG problem statement draft *and* a
> WG solution-space-analysis draft.

I agree.

> specific.  I will add this in -04.  But, I will not remove the
> security risks discussions specific to each approach.  Again, as
> pointed out by the WG charter (the charter that I know of, anyway):
> "security considerations for the various approaches will also be
> considered".

I agree.

Alex