Subject: RE: [nemo] mor comments on TD

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Fri, 27 Aug 2004 17:12:01 +0200

> 
> That's a nice thought and you have good intentions.
> 
> I just don't agree with the assumptions you make;
>   - no organisation, complete automation, no human decisions
>   - lots of MRs
>   - many levels of nesting

I gave an example of 10 MRs. That's not a lot. But in a daisy chain,
that's 10 levels of nesting - a lot. This is not a network design
problem, though - this may be totally ad hoc. It's a lack of capability
of the system. We want to avoid that. That's why we need TD.
 
> Of course we should not design a protocol (basic support) that only
> supports a limited number of MRs or a limited number of nesting
levels,
> for instance. But a good estimation of likely figures helps when
making
> design trade-offs. 

Right, that was discussed at the beginning of the WG:

We have scenarios with 3 or more level of nesting. But nothing says how
we get there. One such example is: 
 ferry boat <- car <- pan. 
NEMO does not provide for the PAN to attach to a car (mine in
particular), for the car to attach to a ferry etc... We could end up
having a car joining the ferry and then the hundred other in a daisy
chain till the overhead of tunnels is so huge that it does not work at
all.

We have been asked to look at realistic scenarios such as traffic jams.
That's 2000 cars. I did not make up the numbers. 

> Unfortunately, in my experience, adding more
> autoconfiguration in one place in the system or on one layer in the
> stack doesn't eradicate the problem in question, it just pushes it to
> another place or to another layer.

That can be true but I fail to understand what exactly you want to
express here. Sorry.

> I want this WG to work on the problem and requirements stated in the
WG
> docs. We want basic support to provide connectivity. Optimisations of
> various kinds will come in a later stage. Why not make this a part of
> the problem statement for the continuation of the WG where we talk
about RO?

True... TD is somewhere in a twilight zone between nemo basic and RO. I
asked that same question to the WG, but did not get a clear response.
I'd say that it may be covered by the charter (just to be able to do the
ferry stuff) but then it would not be a priority compared to, say prefix
delegation. 

Also, it's not 100% sure we ever recharter for RO. I hope we do.

Pascal

---

From: Mattias Pettersson <[email-masked]>
Date: Sun, 29 Aug 2004 19:57:18 +0200

> That's 2000 cars. I did not make up the numbers. 

Now I think you are making a dangerous assumption here. You seem to say 
that an MR can hear any number of access points (ARs, other MRs' ingress 
interfaces etc.) _and that it connects to them all on the IP layer_, so 
that it can hear each and everybody's RA.

This seem to indicate that there are no distinct logical links on top of 
802.11 or whatever we run, but rather that there is basically only one 
single logical link where everybody can hear everybody else. This is 
really bad. This is what ad hoc assumes, but I would like to see NEMO 
assuming a bit more _structured_ and _managed_ networks.

If an MR can hear all APs, I guess all MNNs can do the same. They all 
listen to the same channel. An MNN would find itself hearing 2000 
prefixes then and maybe configure addresses from of them all, as long as 
is it within range.

I say that an MR must first look for APs, then attach to one of them on 
L2, and finally listen to the RAs on L3.

And while this is interesting to study, it is not related to NEMO. NEMO 
comes in after the third step.

Vaguely defined L2 links are dangerous. They introduce so many problems. 
TD is just a small part of a solution.

Think of whether this is a problem with wire NEMOs. I think we need to 
see wireless as a cable replacement rather than magic.

/Mattias