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

Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr> Thu, 05 August 2010 09:47 UTC

Return-Path: <emmanuel.baccelli@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 52DBE3A693A for <autoconf@core3.amsl.com>; Thu, 5 Aug 2010 02:47:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Level:
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
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 Rfvq5bk-AXRb for <autoconf@core3.amsl.com>; Thu, 5 Aug 2010 02:47:45 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id B18CB3A6A0B for <autoconf@ietf.org>; Thu, 5 Aug 2010 02:47:44 -0700 (PDT)
Received: by ewy22 with SMTP id 22so2582608ewy.31 for <autoconf@ietf.org>; Thu, 05 Aug 2010 02:48:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=0wB1opHoCbvukK8UlAVdwIjoliybD9450u9KwEjb40s=; b=w54L7f8NZ+wjy/V32RFEpjpVGfUZWi3WdY4yxKsLfgtCA2ZJP5vxO1bqbKkOxfuUMc lMQUTQJd6Dn4QjGTsK10ERayptJLEa5whQRwkzt4UJZy4/AVVrxS2kBYfnq47/hh0yWW yht5xFGuBwlL2eKvW1rkZnV1NU8wz/xOnLJIE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=cZpvSy+16NqN7WGP3vVAJSvLScRyauy4dVa6RDm0E65WbSR5YkGwxRQM3fgSSWNn9y c9xn1RhwOe3R93W1dLemayjGohlvovUv/mEc29M2WMxbiXukFk9XrJxVMdIwdoq0bZQD SbudrXpedPo7Onf0gK9er9bV+lcxyBQBhAoIk=
Received: by 10.14.119.133 with SMTP id n5mr2578309eeh.79.1281001693335; Thu, 05 Aug 2010 02:48:13 -0700 (PDT)
MIME-Version: 1.0
Sender: emmanuel.baccelli@gmail.com
Received: by 10.14.119.143 with HTTP; Thu, 5 Aug 2010 02:47:53 -0700 (PDT)
In-Reply-To: <201008051039.03011.henning.rogge@fkie.fraunhofer.de>
References: <4C528979.7010006@oracle.com> <201008040756.04650.henning.rogge@fkie.fraunhofer.de> <4C596602.1060308@earthlink.net> <201008051039.03011.henning.rogge@fkie.fraunhofer.de>
From: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
Date: Thu, 05 Aug 2010 11:47:53 +0200
X-Google-Sender-Auth: SX5qMdxmP94hKpCKaRuWcP9mVzM
Message-ID: <AANLkTikWgoUHeJsZwWDViVyavWXjvtLfffrosHPcCPya@mail.gmail.com>
To: autoconf@ietf.org
Content-Type: multipart/alternative; boundary="90e6ba5bbad5e35a6a048d107254"
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: Thu, 05 Aug 2010 09:47:47 -0000

I share the opinion that this discussion polluted by the unanswered question
"what is the definition of a router?". There are too many different answers
to this question (Thomas mentioned some of them in Maastricht, and other
definitions exist, I'm sure).

Maybe it would be easier to focus on the counterpart instead, and consider
the question "what is the definition of a host?". It seems to me that the
devices we are aiming to configure are typically capable of things that
hosts can't do (including, for instance, forwarding traffic on behalf of
other devices, if necessary).

So the immediate conclusion that most folks make, is: "if it is not a host,
then it is a router". Difficult to blame anyone for making such a deduction,
as the IETF defined a world where you only have these two choices. So I
think, in that sense, we are indeed configuring routers.

Now, if I understand Charlie's point correctly, he raises the question:
"what of the special case where the device we are configuring is really a
host?". This question was already raised some time ago in this working group
(at least while we were discussing the late MANET architecture draft). If I
remember correctly, the rough consensus at that point in time was: "hosts
are considered to be connected to a MANET only through a router, and thus,
the MANET can be considered as comprising of only routers".

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.

However, in the end, Charlie is right: we do want to configure the hosts too
;) So do we want to stick to the original plan (i.e. focus first on router
configuration) or do we want to address instead both router and host
configuration, all at once? I guess this is what it boils down to at this
point.

As far as I am concerned, I think it makes sense to consider the issue of
"configuring routers" from the issue of "configuring hosts" separately
because hosts are and routers have very different capabilities. I'm also
fine with sticking with the original plan, i.e. focus first on router
configuration. But on the way towards solutions for router configuration, I
think we should be careful not to forget the big picture: in the end we want
to also configure hosts. In particular, this means that if an efficient
router configuration solution can easily be extended to become an efficient
host configuration solution, all the better ;)


Emmanuel







On Thu, Aug 5, 2010 at 10:38 AM, Henning Rogge <
henning.rogge@fkie.fraunhofer.de> wrote:

> On Wed August 4 2010 15:07:14 Charles E. Perkins wrote:
> > Hello Henning,
> >
> > On 8/3/2010 10:55 PM, Henning Rogge wrote:
> > > If you run a part of the routing protocol to connect the "host" to the
> > > MANET, it's a router in my oppinion (Ripple would call it a leaf node
> > > for example).
> >
> > What if your host gets an address by running
> > "autoconf.exe", which is not a routing program?
> Does your host set up a route towards the next router and maintains it if
> the
> topology data from the router changes ? If yes I would say it's a primitive
> router too. If no, it's not.
>
> > > If the node just use DHCP or similar protocols to get it's address
> > > without being modified to work with the MANET, it's no router (and
> don't
> > > need the autoconf address model).
> >
> > What if the host does not?  Or, do you mean to say
> > that this discussion is a way to legislate that all
> > hosts must use DHCP?
> I don't think I ever said this. I just presented an example that the
> address
> model is not necessary for running a node in a MANET that use the autoconf
> address model.
>
> Yes, you CAN use it... but you don't need to.
>
> > > The autoconf model is NOT the only way for a host to get an address for
> > > connection to a MANET.
> >
> > The autoconf model for getting addresses doesn't exist.
> > I sure hope it isn't the only way to get an address.
> >
> > But suppose at some point there is an autoconf.exe.
> > It should be a way for a host to get an address.
> > Its connection to the MANET would, presumably allow
> > it to use this address.  Or, do you mean to say that
> > "address allocation" == "connection"?
> I don't see any reason why an autoconfiguration protocol developed by this
> group would only run on interfaces of routers.
>
> > > If you have a router with a policy that limits the routers
> functionality
> > > (in terms of the routing protocol), you could just write a
> > > compact/optimized version of the needed software part for it.
> >
> > main()
> > {
> >       system ("get_address");
> >       if (routing) fail();   /* My compact routing code */
> > }
> >
> > Am I a router?
> I don't see any routing code of a routing protocol. But I don't see your
> problem too.
>
> > >>> It should be done on the routers (but MANETs can and have been run
> > >>> with different address models), and it could be used for hosts
> closely
> > >>> attached to a MANET, but it's not necessary to do so.
> > >>
> > >> What is "it"?
> > >
> > > The autoconf address model should be used on routers (but you could use
> a
> > > different one) and it (the address model) could be used on hosts
> attached
> > > to a MANET, but it's not necessary to use the autoconf address model on
> > > hosts.
> >
> > It's necessary for hosts to adhere to the
> > considerations detailed in the address model
> > document.  I'm not sure if this is the same
> > as "using" it.
> It might be necessary, depending on what software the host is running.
>
> > >>> But in my opinion it is still better it's still better to restrict
> the
> > >>> title as suggested in the WG meeting consensus that to make it too
> > >>> generic.
> > >>
> > >> I can't imagine any non-political reason whatsoever for this.
> > >
> > > If we do otherwise we could have the same problems. People would say
> "you
> > > demand that any computer attached to your MANET use the autoconf
> address
> > > model. But we have to use DHCP, so your address model is wrong."
> >
> > This is a political argument not based on the needs
> > of the addressability, connectivity, or goals of
> > making an ad hoc network.  Insofar as you may be
> > nonetheless correct, I begin to believe that I have
> > zero insight into the technical goals of the discussion.
> >
> > > (I don't say they are right, but we will get people with strange
> comments
> > > on the address model with both titles)
> >
> > Please tell me if my comments are "strange".
> I think the problem you stated is that people can say "the title says it's
> only for routers, so it is not enough for my usecase and I need something
> different".
>
> If we not change the title we might get "the title says it's for all nodes,
> but I cannot force my users to install a special interface configuration on
> their smartphones, so I need something different."
>
> There are nodes in MANET that are a grey area between host and router.
> Because
> of this we cannot make a clear statement on what nodes the autoconf address
> model should be used.
>
> Most of the WG seems to think it's better to restrict the scope a little
> bit
> more and let people use it for other things than the defined scope if they
> think it's right (at least that's how I understand the consensus of the
> group).
>
> Henning Rogge
> --
> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
> Kommunikationssysteme (KOM)
> Neuenahrer Straße 20, 53343 Wachtberg, Germany
> Telefon +49 228 9435-961,   Fax +49 228 9435 685
> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
> GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0
>
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf
>
>