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

"Charles E. Perkins" <charles.perkins@earthlink.net> Fri, 06 August 2010 16:56 UTC

Return-Path: <charles.perkins@earthlink.net>
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 E42533A67D1 for <autoconf@core3.amsl.com>; Fri, 6 Aug 2010 09:56:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.234
X-Spam-Level:
X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599]
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 Fcs78pgwCDcp for <autoconf@core3.amsl.com>; Fri, 6 Aug 2010 09:56:11 -0700 (PDT)
Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 9EEAA3A67C3 for <autoconf@ietf.org>; Fri, 6 Aug 2010 09:56:11 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=UWIwwrrlHdIjQ5qDP4d/8PPjqtXyOZ6Us1nk80kE+F3R6qbdA/sOCeZTfFZDJJGx; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [12.204.153.98] (helo=[10.166.254.137]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1OhQDp-0008Ay-VO; Fri, 06 Aug 2010 12:56:42 -0400
Message-ID: <4C5C3EC8.50009@earthlink.net>
Date: Fri, 06 Aug 2010 09:56:40 -0700
From: "Charles E. Perkins" <charles.perkins@earthlink.net>
Organization: Wichorus Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6
MIME-Version: 1.0
To: Thomas Heide Clausen <thomas@thomasclausen.org>
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>
In-Reply-To: <E2946D37-14F1-4DC0-94C3-DC4FE6A3BE79@thomasclausen.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5254521046cf5b6b75a02ea55e7e4db714350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 12.204.153.98
Cc: 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 16:56:13 -0000

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.