Subject: [nemo] mor comments on TD

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 26 Aug 2004 18:27:09 +0200

Hi Pascal, here are more comments on TD.  I hope I'm not missing
something obvious...

> When several MRs attach to each other to form a nested Nemo, loops 
> can be created if they are not explicitely avoided. In the simplest 
> case, when egress and ingress interfaces of an MR are all wireless, a
>  mobile router may be listening to Router Advertisement from its own
>  ingress interface, creating a confliction problem.

This is bad configuration.  This is something that an administrator
should avoid.  When a machine has several wireless interfaces each
intended to belong to different IP subnets (the case of a typical
router) then administrator should enforce this.  With 802.11b, it is at
least necessary to set up different ESSID's.  This is not a NEMO problem.

> In the general case, arbitrary attachment of MRs will form graphs 
> that are not exempt of loops. For instance: Assume a nested Nemo 
> where MR1 is connected to the infrastructure, and MR3 is attached to 
> MR2. Say that MR2 can hear both MR3 and MR1 over its wireless egress 
> interface. If MR2 select MR1, the connectivity to the infrastruture 
> is provided for all. But if MR2 selects MR3, MR2 and MR3 end up 
> forming a loop and are disconnected from their Home Agents.

See same remark as above.

Administrator of MR2 should decide to attach to either MR1 or MR3 based
on out-of-band data, that is having some outside knowledge about which
of the two MR's actually provides access to the Internet and not to some
local loophole.

You have this problem with a single laptop (not several) if you walk
around your favorite downtown and see a bunch of available AP's and
don't know which is actually leading to the Internet.  You have the same
problem when you're using a PDA getting in a train stopped at the
railway station and you don't know which ESSID to use, the train's or
the railway station's.  Both these cases have been experienced in
practice (ask for details).  None is NEMO related.

If one ever needs options in RA's that say "I'm a better lead to the
Internet" then maybe one would use Router Lifetimes such as to use the
Default Router stuff.  For example, in your above case, when MR3 knows
it does not yet have Internet access (because no BAck received) then it
should not put Router Lifetime 0 in its RA's.  In this way, MR2 will be
constrained to automatically choose MR1 as a default route.  This may
help and no need of TIO.  I'll make a separate message with this.

> Each MR should be able to make its own attachment router selection 
> based on its own condition (eg battery level), its own set of 
> constraints that may not apply to other MRs in the tree, and in 
> general its own algorithm. As a result, the standardization effort 
> should concentrate on a common minimum set of rules that must be 
> common to all MRs in order to prevent routing loops in the nested 
> NEMO while leaving MRs independent in their AR selection algorithms.

On the contrary, I think a standardization effort should look first at
the problem to be solved instead of standardizing a proposal whose need
is not yet clear.

Alex

---

From: Mattias Pettersson <[email-masked]>
Date: Fri, 27 Aug 2004 10:42:34 +0200

> least necessary to set up different ESSID's.  This is not a NEMO

I completely agree. This is what I pointed out in San Diego. An 
administrator wouldn't randomly connect an Ethernet cable to any socket 
he finds. He needs to have a clear picture of the wiring. Wireless isn't 
any different. You don't just connect to APs without knowing where they 
fit in the topology.

/Mattias