Re: [Autoconf] Autoconf addressing model

"Stan Ratliff (sratliff)" <sratliff@cisco.com> Wed, 04 March 2009 15:30 UTC

Return-Path: <sratliff@cisco.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 ADAF43A679F for <autoconf@core3.amsl.com>; Wed, 4 Mar 2009 07:30:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 nZlbFD2xD1ZS for <autoconf@core3.amsl.com>; Wed, 4 Mar 2009 07:30:25 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id EC8B63A6CAA for <autoconf@ietf.org>; Wed, 4 Mar 2009 07:30:22 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.38,301,1233532800"; d="scan'208";a="150716455"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 04 Mar 2009 15:30:51 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n24FUpIS025705; Wed, 4 Mar 2009 07:30:51 -0800
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n24FUndT027203; Wed, 4 Mar 2009 15:30:51 GMT
Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Mar 2009 10:30:50 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 04 Mar 2009 10:30:49 -0500
Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com>
In-Reply-To: <49AE9827.5090309@gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Autoconf] Autoconf addressing model
Thread-Index: Acmc2lRFwPYuEwx1R1mROqaucljYQQAAQPKA
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> <49AE9827.5090309@gmail.com>
From: "Stan Ratliff (sratliff)" <sratliff@cisco.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
X-OriginalArrivalTime: 04 Mar 2009 15:30:50.0488 (UTC) FILETIME=[32BFE780:01C99CDE]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7098; t=1236180651; x=1237044651; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20=22Stan=20Ratliff=20(sratliff)=22=20<sratliff@cisc o.com> |Subject:=20RE=3A=20[Autoconf]=20Autoconf=20addressing=20mo del |Sender:=20; bh=c8SlZ27aJkisB1ND2FyV1oczIjnuXildiGbVWjwyhjw=; b=UZme4MFq6urN6cEJwzkL2gpCGXx/uPIhgaHVEXN0wpd/Ppvw2XlDzZT9Z/ 2RZL1fDV4uEImi/R2OFwLD9D4rcnNpUVdUUpNds1QqMVhe/IJK+L0lx3+VXV O3UfS+xhbF;
Authentication-Results: sj-dkim-3; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; );
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:30:26 -0000

Inline. 

> -----Original Message-----
> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] 
> Sent: Wednesday, March 04, 2009 10:03 AM
> To: Stan Ratliff (sratliff)
> Cc: Charles E. Perkins; autoconf@ietf.org
> Subject: Re: [Autoconf] Autoconf addressing model
> 
> 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?
> 

First off, you *can't* arbitrarily limit subnets to 25m. 25m from what? The center? And, how do you designate the center? Do you constantly re-calculate the center based on movement? 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. And what about the wired MANET case brought up by Christopher Dearlove? Should we limit the cable runs? 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. 

Regards,
Stan



> The disaster relief scenarios you describe also have certain 
> limits of movements.  For example:
> -firefighter never gets very far away from truck.

- Not really. Firefighters regularly deploy at "some distance" from the truck. They go where they're needed, regardless of distance from the truck. Especially true in the case of people fighting wildfires in a forest.  

> -among all intervening trucks only some are designated as special, for
>   example command and control.

- If you designate some trucks as "special", then you limit the possible network deployments, and/or create single points of failure. The overall network isn't as resilient as it needs to be -- for instance, if you designate a truck as "special", and a burning tree falls on it, what now?

Stan



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