Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd:Forgotone [Was: RFC 5889)

Thomas Heide Clausen <thomas@thomasclausen.org> Fri, 06 August 2010 17:22 UTC

Return-Path: <thomas@thomasclausen.org>
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 932533A6892 for <autoconf@core3.amsl.com>; Fri, 6 Aug 2010 10:22:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.376
X-Spam-Level: *
X-Spam-Status: No, score=1.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619]
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 bQEmzCmK+doj for <autoconf@core3.amsl.com>; Fri, 6 Aug 2010 10:22:57 -0700 (PDT)
Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 435003A6879 for <autoconf@ietf.org>; Fri, 6 Aug 2010 10:22:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 13B5B3236DB7; Fri, 6 Aug 2010 10:23:29 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net
Received: from [10.225.71.210] (unknown [90.84.146.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id DE5783236DB8; Fri, 6 Aug 2010 10:23:27 -0700 (PDT)
References: <4C528979.7010006@oracle.com> <201008040756.04650.henning.rogge@fkie.fraunhofer.de> <4C596602.1060308@earthlink.net> <201008051039.03011.henning.rogge@fkie.fraunhofer.de> <AANLkTikWgoUHeJsZwWDViVyavWXjvtLfffrosHPcCPya@mail.gmail.com> <4C5B3854.3050706@earthlink.net> <E2946D37-14F1-4DC0-94C3-DC4FE6A3BE79@thomasclausen.org> <4C5C3EC8.50009@earthlink.net>
In-Reply-To: <4C5C3EC8.50009@earthlink.net>
Mime-Version: 1.0 (iPhone Mail 8A293)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=utf-8
Message-Id: <8C0A8E8A-B26C-4330-9173-94530FEDD350@thomasclausen.org>
X-Mailer: iPhone Mail (8A293)
From: Thomas Heide Clausen <thomas@thomasclausen.org>
Date: Fri, 6 Aug 2010 19:22:32 +0200
To: "Charles E. Perkins" <charles.perkins@earthlink.net>
Cc: "autoconf@ietf.org" <autoconf@ietf.org>, Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd:Forgotone [Was: RFC 5889)
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, 06 Aug 2010 17:22:58 -0000

Charlie,

You suggest a face-to-face meeting. As you know I will be in your neck of the woods next week, so let's discuss, then ...

Wg-chair-hat-on: 

If we do that, we do owe it to the wg to report both the arguments and the outcome of the discussions here on the list, as I believe that both are valuable for the wg. Although (still wearing that hat) I would very much like for as much of the discussions to be in public (ie on the list)....

Wg-chair-hat-off:

I'll respond in more details later, but I have suitcases to pack ...

-- 
Thomas Clausen
http://www.thomasclausen.org/

On 6 août 2010, at 18:56, "Charles E. Perkins" <charles.perkins@earthlink.net> wrote:

> Hello Thomas,
> 
> I said:
> 
>>> Do you _really_ want to exclude hosts from your network?
>>> Where will the applications reside?
> 
> You said:
> 
>> User applications (regular user applications) reside on hosts. Hosts are
>> accessing the network by way of being connected to (i.e. one IP hop away
>> from) a router.
> 
> Of course I do not have a problem with running applications
> on MANET routers.  I have proposed this for many years --
> and in fact I do not in any way require that the applications
> reside on hosts that are one hop away from a router.
> 
> My question was partly in jest -- but I do fully
> expect that non-routing hosts will be found in many
> or perhaps even most ad hoc networks.  For instance,
> we will have sensor fields and transmit-only data
> aggregators (both of which do not need to be routers,
> but are likely to need addresses).  I keep thinking
> this is totally obvious!
> 
> 
>> The connectivity between a host and a router is a "classic IP link",
>> and there are already excellent protocols in existence for managing
>> also autoconfiguration of addresses for hosts on classic IP links.
> 
> My objection has been to disqualify non-routing hosts from receiving
> addresses by way of an [autoconf] protocol.  There are of course known
> protocols (excellent or not, does not matter here) for configuring
> "classic hosts" on "classic IP links".  I reckon we mean the same
> thing by those terms.
> 
> My point is that there are almost certainly going to be non-routing
> hosts in <networks whose connectivity is established by MANET routers.>
> I would have just said "MANETs", but now we have so little agreement
> that we don't even know what a MANET is any more.
> 
> 
>> The connectivity between routers is.....who knows? Maybe a MANET,
>> maybe an OSPF network, maybe an ISIS network, and maybe links between
>> routers have "undetermined connectivity properties" -- or not, they
>> may be of NBMA or P2P or telepathic nature. However, that's a matter
>> for routers to figure out and manage; hosts are exposed to a classic
>> IP link and are isolated by an IP hop from any specific connectivity
>> properties of the connectivity/links between routers.
> 
> Here I have to disagree.  A host may have an 802.11 link to a router,
> and be subject to every single last problem of indeterminate range,
> interference, link-local ambiguity, and the other concepts which have
> proved so difficult for [autoconf] to resolve (regardless of so much
> reputable research available).
> 
> And, moreover, it's not up to the "routers".  It's up to "us",
> because we're designing the routers (at least in [manet] wg,
> not in [autoconf]).  Moreover, if a MANET router can work better
> by transacting new protocol with a host, then (a) the host may
> then considered to be something besides a "classic host", and
> (b) why not?  Let's figure it out.  But this does NOT mean that
> a network of the abovementioned variety has to REQUIRE changes
> to classic hosts; as an example, NEMO has made a lot of changes
> but still allows "classic" hosts to reside on mobile networks.
> Our situation is a bit different, insofar as mobile wireless hosts
> still must pay due respect to the realities of wireless.
> 
> 
>> Of course, there *may* be applications (for example, the routing demon)
>> running on routers and exposed to the specific connectivity properties
>> of the connectivity/links between routers. These, and only these
>> (non-user) applications should be sufficiently aware of these properties
>> to operate correctly. User-applications reside on hosts, separated by
>> an IP hop from any "strangeness" between routers, and exposed to
>> well-defined properties of a classic IP link.
> 
> 
> I also disagree with this.  Numerous studies have shown that
> applications can benefit from knowledge of bit-error rate,
> link capacity, jitter, and so on.  Of course we'd prefer that
> applications not have to pay attention to CDMA vs. 802.11,
> etc.  Nevertheless, I am sure that in a face-to-face meeting
> on this subject we would quickly find that we are in substantially
> complete agreement.
> 
> 
>>>> >> This architectural consideration thus separated the issue of
>>>> >> "configuring routers" from the issue of "configuring hosts" in this
>>>> >> context, and the rough consensus was that we would first focus on
>>>> >> configuring routers. Which lead us to where we are now.
> 
> ...
> 
>> This particular point was discussed - at length - at IETF'67 in 2006 in
>> San Diego, where it received (in my recollection) wide consensus; in part
>> because of its analogy with the "regular Internet".
> 
> Surely, "configuring" routers and hosts should be
> done differently.  This does NOT imply:
> (a) hosts should be barred from using the address
>    allocation protocol established for MANET routers, or
> (b) hosts should run useless router code in order to
>    make use of said address allocation protocol, or
> (c) the [autoconf] address allocation protocol design
>    should proceed on the assumption that non-routing
>    hosts are out of scope.
> 
> 
> Regards,
> Charlie P.
> 
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf