RE: [nemo] mor comments on TD

"Pascal Thubert \(pthubert\)" <pthubert@cisco.com> Mon, 30 August 2004 10:56 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11568 for <nemo-archive@lists.ietf.org>; Mon, 30 Aug 2004 06:56:10 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1jny-0000MQ-S7; Mon, 30 Aug 2004 06:54:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C1jiM-0008Hg-St for nemo@megatron.ietf.org; Mon, 30 Aug 2004 06:48:42 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11139 for <nemo@ietf.org>; Mon, 30 Aug 2004 06:48:40 -0400 (EDT)
Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C1jk7-0000TR-MI for nemo@ietf.org; Mon, 30 Aug 2004 06:50:32 -0400
Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 30 Aug 2004 13:01:18 +0200
X-BrightmailFiltered: true
Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7UAllTc011178; Mon, 30 Aug 2004 12:48:08 +0200 (MEST)
Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Aug 2004 12:47:53 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [nemo] mor comments on TD
Date: Mon, 30 Aug 2004 12:47:47 +0200
Message-ID: <7892795E1A87F04CADFCCF41FADD00FC1040CF@xmb-ams-337.emea.cisco.com>
Thread-Topic: [nemo] mor comments on TD
Thread-Index: AcSN8avz2FLCFiVWRxKWPBeiD90T1gAisbOA
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Mattias Pettersson <mattias.l.pettersson@ericsson.com>
X-OriginalArrivalTime: 30 Aug 2004 10:47:53.0007 (UTC) FILETIME=[CD07A3F0:01C48E7E]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Content-Transfer-Encoding: quoted-printable
Cc: IETF NEMO WG <nemo@ietf.org>
X-BeenThere: nemo@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NEMO Working Group <nemo.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:nemo@ietf.org>
List-Help: <mailto:nemo-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=subscribe>
Sender: nemo-bounces@ietf.org
Errors-To: nemo-bounces@ietf.org
Content-Transfer-Encoding: quoted-printable

Hi Mattias:

I'm happy that you point this out because it's at the core of the
problem. Note that we started a discussion like this about with John
from 802.21 when came present his work at IETF 59.
> >
> > 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.
> 
> 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.

All of them is a big word. A number of them is closer to the truth. 

The radio world is far from limited to 802.11, and there are radios
around that allow you to get signals from more then one neighbour. Quite
a good thing in my view, if we want all this MANET thing to work at all.

> 
> 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.
> 

Use cases... There's no such a restriction that I know of for NEMO
applicability. I copy Thierry, in case he wishes to provide his view on
this debate.

> 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.

Now I think you are making a dangerous assumption here :) LFNs could be
wired or connected to the MR using short range techno such as Bluetooth.
Allowing LFNs to listen to other MRs simply kills the whole thing. 

> 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.

This is what we do today with 802.11. Basically a blind L2 selects the
AR on behalf of L3. This is very near sighted :(

This is why we asked for a better interface from 802.21. Hopefully,
we'll be able to get all the RAs from all the APs from monitor mode, and
then let L3 (and above) sort out which router it needs to connect to;
and then associate, under L3 control. This is not only good for NEMO/TD.
It applies to draft-ietf-ipv6-router-selection-05.txt for instance.

Pascal