Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal)

Alexandru Petrescu <alexandru.petrescu@gmail.com> Fri, 23 July 2010 08:53 UTC

Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: autoconf@core3.amsl.com
Delivered-To: autoconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF4E73A69EC for <autoconf@core3.amsl.com>; Fri, 23 Jul 2010 01:53:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xECExrD6Hwsc for <autoconf@core3.amsl.com>; Fri, 23 Jul 2010 01:53:07 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 7D24D3A69E1 for <autoconf@ietf.org>; Fri, 23 Jul 2010 01:53:07 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o6N8rKb5024867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jul 2010 10:53:20 +0200
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6N8rKpB019794; Fri, 23 Jul 2010 10:53:20 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o6N8rJCG014307; Fri, 23 Jul 2010 10:53:19 +0200
Message-ID: <4C49587F.4040605@gmail.com>
Date: Fri, 23 Jul 2010 10:53:19 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1
MIME-Version: 1.0
To: Thomas Heide Clausen <thomas@thomasclausen.org>
References: <4C2A6BB7.1000900@piuha.net> <201007230723.58638.henning.rogge@fkie.fraunhofer.de> <4C494806.5060609@gmail.com> <201007230951.51192.henning.rogge@fkie.fraunhofer.de> <4C494EAE.9000600@gmail.com> <01937057-07D5-44BF-BB89-CF86EB08858C@thomasclausen.org>
In-Reply-To: <01937057-07D5-44BF-BB89-CF86EB08858C@thomasclausen.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" <Chris.Dearlove@baesystems.com>
Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal)
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/autoconf>
List-Post: <mailto:autoconf@ietf.org>
List-Help: <mailto:autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Jul 2010 08:53:12 -0000

Le 23/07/2010 10:15, Thomas Heide Clausen a écrit :
>
> On Jul 23, 2010, at 10:11 , Alexandru Petrescu wrote:
>
>> Le 23/07/2010 09:51, Henning Rogge a écrit :
>>> On Fri July 23 2010 09:43:02 Alexandru Petrescu wrote:
>>>>> if each of the MRs use a wireless interface, the linklocals WILL
>>>>> BE VISIBLE outside their direct link.
>>>>
>>>> Well, the link local addresses will not be visible outside their
>>>> direct link, because the different links are on different ESSIDs
>>>> and moreover on different channels.  Using wireshark on IP packets
>>>> on these different links shows that the link local addressess are
>>>> not visible from one link to another.
>>>
>>> This would only work with preplanned links,
>>
>> Most deployments have a high degree of planning.
>
> Then, they're (by definition) not ad-hoc networks.
>
>>> because otherwise you would have trouble to do neighborhood
>>> detection. How do you detect new nodes coming into range if they
>>> cannot announce their presence with a broadcast, because they got no
>>> unique ESSID to their neighbors ?
>>
>> Well good question - and I have tried.  The difficult thing is the first
>> detection - the "wifi scan" phase; once the drivers have their data set
>> up then re-detection is very fast, in the order of tens of milliseconds.
>> We could use that to signal between two approaching vehicles.
>>
>> More specifically, on WiFi, a beacon is sent periodically, but there are
>> also periodic requests replied with a beacon.  These help a lot to
>> detect presence of a neighbor previously learned, and fast.
>>
>>> MANET routing protocols are specially designed for the case of
>>> unplanned networks. You have a single shared medium which the routing
>>> protocol use for it's work, to do neighborhood/link detection.
>>
>> Well very good.  Is there a case where wireless multi-hop networks are
>> possible _without_ MANET routing protocols?  I believe yes, and I
>> prototyped and demo.
>
> Very well, but then that's not a MANET.
>
>> Besides, there exist deployments where even though the MRs are mobile
>> they stay relatively fixed with respect to each other, in some very
>> simple topology: truck convoy, wagons in a train, etc.  These things
>> stay formed for long hours and reform right after.  These things don't
>> need the power of MANET routing protocols because there are never loops
>> formed at link layer, the topology is really simple.
>
> Very well, but then that's not a MANET.
>
> Alex, can we agree that things that are not MANETs tautologically are not MANETs?

Sure!

Make the Charter tautologically MANET and then we're all clear.

Alex

>
> Thomas
>
>
>>> If you push this down to link layer, you just move the whole problem
>>> down one layer, because you need unique addresses on the link layer
>>> to do neighborhood detection and link establishment.
>>
>> WEll yes... I tend to agree.
>>
>> However, one would avoid to bring existing link layer mechanisms up to
>> the IP stack too.  These link layer mechanisms are there and work very
>> well in their domain.
>>
>> The IP stack is not fast enough on the CPU to work at vehicular speeds,
>> interruptable by some GUI or heavy TCP.
>>
>> The link layer driver executing on a dedicated chipset is much more
>> reliable for these kinds of movements.
>>
>>> If you already have a unique link-layer address, just use it to
>>> generate a unique linklocal-IP.
>>
>> Hmmm... right, that's how link local addresses are generated.
>>
>> Alex
>>
>>>
>>> Henning Rogge
>>>
>>
>>
>
>