Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications

Teco Boot <teco@inf-net.nl> Tue, 31 August 2010 06:43 UTC

Return-Path: <teco@inf-net.nl>
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 363913A6909 for <autoconf@core3.amsl.com>; Mon, 30 Aug 2010 23:43:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.519
X-Spam-Level:
X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 4RLl1GRQUxCU for <autoconf@core3.amsl.com>; Mon, 30 Aug 2010 23:43:26 -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 85F413A68AD for <autoconf@ietf.org>; Mon, 30 Aug 2010 23:43:26 -0700 (PDT)
Received: by ewy22 with SMTP id 22so3874091ewy.31 for <autoconf@ietf.org>; Mon, 30 Aug 2010 23:43:56 -0700 (PDT)
Received: by 10.213.22.6 with SMTP id l6mr132110ebb.38.1283237036792; Mon, 30 Aug 2010 23:43:56 -0700 (PDT)
Received: from [10.128.0.195] ([77.61.241.196]) by mx.google.com with ESMTPS id u9sm13511246eeh.23.2010.08.30.23.43.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 30 Aug 2010 23:43:55 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Teco Boot <teco@inf-net.nl>
In-Reply-To: <4C7883D0.20101@earthlink.net>
Date: Tue, 31 Aug 2010 08:43:54 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <45722A95-9DC3-4C30-AB59-E6CD4631B906@inf-net.nl>
References: <AANLkTi=MZORvNSW7wHdHYOzkOwNZojBars26GfSPgWc9@mail.gmail.com> <ABE739C5ADAC9A41ACCC72DF366B719D035CA5CE@GLKMS2100.GREENLNK.NET> <4C741EBB.8060909@earthlink.net> <ABE739C5ADAC9A41ACCC72DF366B719D03609170@GLKMS2100.GREENLNK.NET> <4C75308C.1090506@earthlink.net> <ABE739C5ADAC9A41ACCC72DF366B719D036094AB@GLKMS2100.GREENLNK.NET> <4C767360.7050805@earthlink.net> <7E56B44F-80A1-4A19-9498-0AACAFC5B4D9@inf-net.nl> <C7C8FE2C-4232-4BC0-A4CB-59DCCFB2A529@inf-net.nl> <4C7883D0.20101@earthlink.net>
To: "Charles E. Perkins" <charles.perkins@earthlink.net>
X-Mailer: Apple Mail (2.1081)
Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" <Chris.Dearlove@baesystems.com>
Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications
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: Tue, 31 Aug 2010 06:43:30 -0000

Hi Charlie,

Op 28 aug 2010, om 05:34 heeft Charles E. Perkins het volgende geschreven:

> 
> Hello Teco,
> 
> On 8/27/2010 2:53 AM, Teco Boot wrote:
>> Hi Charlie,
>> 
>> More thoughts on the grey zone, separating host and routers.
>> You stick to the basic definition: routers forward packets, hosts do not.
>> OK?
>> 
>> We had discussion on routing protocol speakers. I said: sending routing
>> protocol packets makes a node a router.
>> 
>> But for routing protocol speakers, that:
>>  - do not forward packets
>>  - do not send RAs
>>  - do not advertise any willingness to forward packets
>> Would that be routers?
>> 
>> If you say: no, these are hosts, I can follow.
> 
> These are hosts.  Check.
> 
>> But for accepting such, it should be made clear to other nodes, that
>> the routing protocol speaker is a host, not a router.
> 
> Now you lost me.  Why must such a host need to be mentioned
> to other nodes?  If it were mentioned (e.g., by a proactive
> routing protocol) why would it have to be identified as a
> non-routing host?
If other nodes are not aware of this_node, they don't send packets to it.
If other nodes are not aware this_node does not forward packets, it could
be a black hole. This_node MUST NOT be the next hop for other destinations.

>> Some mechanisms:
>>  - passive mode / don't send routing protocol packets at all
>>  - OLSR willingness = WILL_NEVER (0)
>>  - not advertise any links
>>  - advertise links, but with "do not use" attribute / metric
>>  - only put reachability for itself in AODV / DYMO messages
>>  - never send BGP reachability with own address as next_hop
> 
> What mechanisms are these?  Host mechanisms?
These are mechanisms for making sure other nodes are aware this_node
does not forward packets to other destinations.
I am not sure how this may work for NHDP (in OLSR, appendix B.7.).

> How is "not advertising" a "mechanism" (for example)?
Example: in OSPF terms: not sending LSA.

>> Using this classification, a BGP route server is a nice example for a
>> host being an active routing protocol speaker.
> 
> The host is a router server, not a router.
A host is not a router. I don't get your message. 

>> draft-jasinska-ix-bgp-route-server-00:
>> |  Although a route server uses BGP to exchange
>> |  reachability information with each of its clients, it does not
>> |  forward traffic itself and is therefore not a router.
>> 
>> If we agree on such classification, there is some advertorial work to do.
>> Because many would say (ad hoc) routing protocol speakers are routers.
> 
> Yes, people are saying this.  I don't agree.
My point is, if you do not agree, you could be more responsive to WGLCs on this.
Take for example the RFC5889-draft and the new charter. These are full of term 
"router", which if you were consistent, you would strongly disagree on.

> It sounds to me like a way to wind up toy angels and
> get them to dance on the head of a pin, so to speak.
> 
>> E.g. we need errata on RFC's from MANET WG and update the active drafts.
> 
> I'd have to check on this.
You better do.

Charlie,
I can support the idea MANET routing protools may run on hosts.
But for this discussion, can we be somewhat to the point?
It may help. And be less time consuming.


Regards, Teco

> 
> Regards,
> Charlie P.