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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Thu, 05 August 2010 12:22 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 227003A699A for <autoconf@core3.amsl.com>; Thu, 5 Aug 2010 05:22:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.935
X-Spam-Level:
X-Spam-Status: No, score=-0.935 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_40=-0.185, 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 FfiQ9iTbbGf5 for <autoconf@core3.amsl.com>; Thu, 5 Aug 2010 05:22:43 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 88D1B3A6987 for <autoconf@ietf.org>; Thu, 5 Aug 2010 05:22:42 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o75CNBXT010932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <autoconf@ietf.org>; Thu, 5 Aug 2010 14:23:11 +0200
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o75CNA2X025046 for <autoconf@ietf.org>; Thu, 5 Aug 2010 14:23:11 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o75CN7Df021806 for <autoconf@ietf.org>; Thu, 5 Aug 2010 14:23:09 +0200
Message-ID: <4C5AAD2B.3070508@gmail.com>
Date: Thu, 05 Aug 2010 14:23:07 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1
MIME-Version: 1.0
To: autoconf@ietf.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>
In-Reply-To: <AANLkTikWgoUHeJsZwWDViVyavWXjvtLfffrosHPcCPya@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
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 12:22:46 -0000

Le 05/08/2010 11:47, Emmanuel Baccelli a écrit :
> 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?".

That is a good question, looking at it the other way around.

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

I agree.  I think this logic "if it is not a host then it is a router"
is not a right logic.  It could be, for example, a multi-homed device,
not routing, yet multiple interfaces, etc.

If it is not a host then it could be a multi-homed host, a router, and
probably more.

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

:-) sounds good.

How about us wanting to configure an "AUTOCONF node"? (a little bit of a
Router, of a Host, and of a MANET Router).

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

I will be happier if it boiled down to defining an "AUTOCONF node" or
entity, or so.

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

Reads good.

Alex

>
>
> Emmanuel
>
>
>
>
>
>
>
> On Thu, Aug 5, 2010 at 10:38 AM, Henning Rogge
> <henning.rogge@fkie.fraunhofer.de
> <mailto: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
> <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 <mailto:Autoconf@ietf.org>
> https://www.ietf.org/mailman/listinfo/autoconf
>
>
>
>
> _______________________________________________ Autoconf mailing
> list Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf