Re: [Autoconf] Autoconf addressing model

Alexandru Petrescu <alexandru.petrescu@gmail.com> Wed, 04 March 2009 15:02 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 432E128C377 for <autoconf@core3.amsl.com>; Wed, 4 Mar 2009 07:02:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.172
X-Spam-Level:
X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.077, 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 3IHNsit+5n2J for <autoconf@core3.amsl.com>; Wed, 4 Mar 2009 07:02:43 -0800 (PST)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 09A783A67C0 for <autoconf@ietf.org>; Wed, 4 Mar 2009 07:02:39 -0800 (PST)
Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n24F1HCj001648; Wed, 4 Mar 2009 16:01:17 +0100
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n24F33Jk013115; Wed, 4 Mar 2009 16:03:03 +0100 (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 n24F33kq026938; Wed, 4 Mar 2009 16:03:03 +0100
Message-ID: <49AE9827.5090309@gmail.com>
Date: Wed, 04 Mar 2009 16:03:03 +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> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com><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>
In-Reply-To: <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
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: Wed, 04 Mar 2009 15:02:44 -0000

Stan Ratliff (sratliff) a écrit :
[...]
> We've already been over the 25m subnet thing. It's a non-starter. 
> Limiting movement, or mandating that a DHCP or DNS server is always 
> on and available is also a non-starter. 25m subnets with "always on" 
> DNS/DHCP servers sounds to me like a few guys gathering together to 
> play "Doom" at their local coffee shop. I deploy MANET networks for 
> governmental applications. Think disaster recovery, like after 
> Hurricane Katrina, or the last round of wildfires in California. Do 
> you think it appropriate to tell the firefighters "you can't let the 
> trucks get more than 25m apart, or your network breaks"? Or, "if your
>  DNS server should fail, just forget what you're doing and go home"?

No, I don't think it appropriate.

But I didn't mean to imply AUTOCONF networks span only 25meter range - 
they could be made of several such single subnets.

> So, once again, no -- 25m subnets don't make sense and won't work in 
> the environments where I'm deploying networks. Placing this type of 
> limitation on AUTOCONF will, IMO, make the work output useless.

How about a unit being a 25m subnet containing exposed terminals; and a
network growing as a chain of such units, linked by routers.  Would this
make more sense?

The disaster relief scenarios you describe also have certain limits of 
movements.  For example:
-firefighter never gets very far away from truck.
-among all intervening trucks only some are designated as special, for
  example command and control.
-etc.

Expressing this inherent structure in terms of subnet structure can be 
very useful.

Alex

> 
> Stan
> 
> 
>>> Watching your DNS server [(m) or not!] move from place to
>> place in an
>>> ad hoc network, sometimes finding itself partitioned from your 
>>> favorite node, could be an exciting and enlightening adventure.
>> I agree we could find very dynamic ways of Routers and Hosts of an 
>> ad-hoc network moving in and out such that subnet structure is not 
>> maintained, and thus servers not being reachable.  But unless we 
>> describe these movements we can't deal with them.
>> 
>>>>> Who said we had to avoid size limits?
>>>> Well we don't have size limits in the charter proposal, we
>> don't have
>>>> agreement on '25m IPv6 subnets', we don't have limits on
>> the types of
>>>> the link layers involved.
>>> If you are talking about an ad hoc network with 25,000,000 
>>> subnets, then I am basically not on the same page.  And not in 
>>> the
>> same decade.
>> 
>> Sorry I meant 25meters not millions.  A '25m IPv6 subnet' would be 
>> a wireless coverage area of radius 25meter, without obstacles, and 
>> within which there are only exposed terminals, fully transitive and
>>  symmetric communications.
>> 
>> Would you agree such a subnet makes sense?  Does not make sense?
>> 
>>>> However, your question seems to imply you think there may be a
>>>>  limit: AUTOCONF network is small enough to accommodate 
>>>> host-based routes.  Is it this?
>>> I think the network has to accomodate the routes needed for 
>>> connectivity to destinations within the network.
>>> 
>>> Again, just saying "subnet" doesn't buy even one gram of 
>>> additional scalability.  You need more.
>>> 
>>> You need a procedure for enabling aggregation. Such a
>> procedure is not
>>> always available.
>> If by aggregation is meant addressing aggregation (as Teco also 
>> proposes a /60 prefix assigned to several Routers themselves 
>> assigning /64 prefixes to their links) then I think we should not 
>> strive to respect aggregation.  Address aggregation wouldn't make 
>> sense if we talk host-based routes either.
>> 
>>>>> Well, to me it did sound very negative.  Moreover, I think it
>>>>>  is just fine to pass around subnet prefixes, if you have 
>>>>> subnets.
>>>> Charles, yes - the subnets are there first, before IP.
>> Once the link
>>>> is up the subnet is the set of nodes on it.  In this sense
>> I agree it
>>>> is just fine to pass subnet prefixes around.
>>> This is wrong*2.   First, there is IP, which fixes the
>> address format
>>> and address modes.  Then there are subnets. Some people
>> here probably
>>> remember when the word "subnet" starting coming into more
>> active use.
>>> 
>>> Second, just because nodes are reachable over the air as 
>>> neighbors, does not imply they are on the same IP subnet.  Trying
>>>  to maintain otherwise leads to madness.
>>> 
>>> Surely you will agree.  A subnet is an abstraction to support 
>>> more efficient routing.  It is not a wire or a piece of plastic 
>>> or a contiguous region of space.
>> I can live with that.
>> 
>> However, I think the simplest cases we have to deal with have very 
>> simple subnet structure that we should take advantage of.
>> 
>> Alex
>> 
>> _______________________________________________ Autoconf mailing 
>> list Autoconf@ietf.org 
>> https://www.ietf.org/mailman/listinfo/autoconf
>> 
>