Re: [Autoconf] Autoconf addressing model

Alexandru Petrescu <alexandru.petrescu@gmail.com> Thu, 05 March 2009 09:14 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 C720828C1C3 for <autoconf@core3.amsl.com>; Thu, 5 Mar 2009 01:14:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=0.142, 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 0k88sUg6AEH8 for <autoconf@core3.amsl.com>; Thu, 5 Mar 2009 01:14:22 -0800 (PST)
Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 7D7F628C132 for <autoconf@ietf.org>; Thu, 5 Mar 2009 01:14:20 -0800 (PST)
Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id 7A53B9401E3; Thu, 5 Mar 2009 10:14:44 +0100 (CET)
Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 90A6094001B; Thu, 5 Mar 2009 10:14:41 +0100 (CET)
Message-ID: <49AF97FA.7020007@gmail.com>
Date: Thu, 05 Mar 2009 10:14:34 +0100
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: "Stan Ratliff (sratliff)" <sratliff@cisco.com>
References: <499F0BA7.90501@piuha.net> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com><1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl><49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl><49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl><49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl><49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com> <49AEBA6D.7030903@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com>
In-Reply-To: <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 090305-0, 05/03/2009), Outbound message
X-Antivirus-Status: Clean
Cc: autoconf@ietf.org
Subject: Re: [Autoconf] Autoconf addressing model
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: Thu, 05 Mar 2009 09:14:23 -0000

I wanted to clarify better myself because I think I'm misunderstood,
sorry for insisting on what may appear as circles but I don't want to be
understood so.

Stan Ratliff (sratliff) a écrit :
>> Stan Ratliff (sratliff) a écrit :
>>> First off, you *can't* arbitrarily limit subnets to 25m. 25m from
>>>  what? The center?
>> Yes, an area of 25meters with a wifi access point in the center.
> 
> *By definition*, what you describe is not a MANET. As you state, 
> that's just a WiFi access point.

Ok, I said AP because in a hurry.  I also meant AP-free wifi adhoc mode
gatherings of ad-hoc interfaces.  The coverage is also about 25meter.
This is dictated by the max power levels (a number of milliwatts) which
says how strong can 2.5GHz emit in unlicensed spectrum.

If all such ad-hoc interfaces of that IPv6 subnet stay within 25meter
range then they're all fully exposed (no hidden terminals).

And I also mean that larger networks could be made out of building
blocks of 25m (because of powerlevel-limited because
unlicensed-spectrum), by using Routers.  And still keeping the IPv6
subnet to be as small at the safe area in which there are all exposed
terminals, no hidden terminals.

I hope I'm clearer.

> That's already solved -- 802.11 clients can roam from access point to
>  access point.

Well yes and no, depends how it's deployed.  If the APs are bridging
into a backbone then yes, terminals keep their addresses.  But if the
APs route then it's not solved.  (Proxy) Mobile IP may be a solution for
it, but it has its inconvenients in path lengths (RO) and tunnels.

> But again, this should not be an 802.11-centric discussion.

I agree to have it on more than 802.11.

I've been told recently it's not good for link layer characteristics to
  control the link-layers to IP addressing.  Yes, put that way I agree
with it - I don't want link-layers to control IP, rather vice-versa.

But it's also  true that an IPv6 link-local address on Ethernet depends
directly on the MAC addres (a link-layer ID), that an  IPv6 subnet on
802.16 is a prefix-per-mobile model, and that IPv6 auto-configuration on
802.15.4 may use a form of address assigned in RA.

That's what I wanted to say about AUTOCONF addressing architecture and
specific link-layers.

I hope I'm clearer.

Alex

>>> And, how do you designate the center? Do you constantly
>> re-calculate
>>> the center based on movement?
>> No, not constantly re-computed.  But have a fixed view at a point 
>> in time.  Saying everything varies isn't helpful either.
>> 
> 
> It may not be helpful, but it's reality. You can't rely on a fixed 
> view of a dynamic network; again, by definition, there's movement in
>  a MANET. Links come and go, and link quality varies from moment to 
> moment.
> 
> 
>>> Also, from a radio perspective, how do you tell how far
>> apart you are
>>> in the first place? Do you suppose that all radios have
>> GPS? That's a
>>> non-starter, because GPS signals aren't always available.
>> No I didn't suppose GPS is available on each device, it wouldn't 
>> work well under foliage.  Just a rough evaluation of a specific 
>> link-layer radio range, correspondign to widely used networks.
>> 
>>> And what about the wired MANET case brought up by Christopher 
>>> Dearlove? Should we limit the cable runs?
>> YEs, certainly.  All cabled link-layers have specific limitations 
>> on their lengths: 2m USB, 50m Ethernet Category6 (IIRC) and so on.
>> 
>>> I could understand (but wouldn't really like) the notion of 
>>> limiting the discussion
>> to links
>>> that are transitive; but placing some arbitrary distance
>> limit that's
>>> based on 802.11 just doesn't cut it for me.
>> 802.11 is being used widely, no reason to ignore.
> 
> I'm not advocating we "ignore" 802.11, or any other L2 technology, 
> for that matter. I'm advocating that we remain Layer 2 agnostic. As 
> Teco mentioned in another email, there are people in this WG that 
> don't deploy MANET networks based on 802.11, or 802.16, or 802.15.4.
> 
>> I'd happily accept to add another specific limitation, from the 
>> link-layer of your choice.  And be speecifically addressing these 
>> two link layers.  And maybe three.  No more than three.
>> 
>> I find addressing them all to be difficult for me.
> 
> I don't understand why the Layer 3 addressing scheme needs to be 
> predicated on a specific Layer 2 technology, or set of technologies.
>  The Layer 3 addressing scheme should be totally independent of Layer
>  2 -- isn't that what layering is all about?
> 
>> (about single point of failure being destroyed by a falling tree: 
>> problem could be addressed at its layer: don't move the command 
>> center under trees risking falling); or maybe have two command 
>> centers, but specificllay two, not an arbitrary large unknown 
>> number.
>> 
> 
> That essentially boils down to "if it hurts, don't do it", and it 
> doesn't work for my customers. Their environments are dynamic, and 
> they need the ability to respond to ever-changing realities on the 
> ground.
> 
> At this point, I feel that we're in a discussion that is becoming 
> more and more circular, and therefore, dysfunctional. And that, IMO,
>  has been the unfortunate reality of this WG since its inception.
> 
> Regards, Stan
> 
> 
>> Alex
>> 
>