From owner-freebsd-net@FreeBSD.ORG Tue Mar 2 06:10:43 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9891316A4D4; Tue, 2 Mar 2004 06:10:43 -0800 (PST) Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57CE943D2F; Tue, 2 Mar 2004 06:10:43 -0800 (PST) (envelope-from brad.knowles@skynet.be) Received: from [10.0.1.3] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p3/8.12.3) with ESMTP id i22EAXxe002845; Tue, 2 Mar 2004 09:10:34 -0500 (EST) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@127.0.0.1 Message-Id: In-Reply-To: <20040302135230.GF3438@astral-on.net> References: <4043B6BA.B847F081@freebsd.org> <200403011507.52238.wes@softweyr.com> <20040302031625.GA4061@scylla.towardex.com> <20040302042957.GH3841@saboteur.dek.spc.org> <20040302082625.GE22985@cell.sick.ru> <20040302084321.GA21729@xor.obsecurity.org> <20040302090219.GC3438@astral-on.net> <20040302135230.GF3438@astral-on.net> Date: Tue, 2 Mar 2004 15:10:33 +0100 To: ad@astral-on.net From: Brad Knowles Content-Type: text/plain; charset="us-ascii" ; format="flowed" cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: My planned work on networking stack X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2004 14:10:43 -0000 At 3:52 PM +0200 2004/03/02, Andrew Degtiariov wrote: >> Oh, and then there are all the operational issues where >> zebra/quagga can't keep sessions going when a neighbor flaps, etc.... >> Those would require re-architecting the whole routing system, at > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Congratulation. That's namely what the conversation was about. Right. We can either re-architect zebra/quagga, or we can start with something that addresses the weaknesses in these tools, or we can do something else. I'm advocating that we at least take a long hard look at what Henning Brauer has done, and seriously consider whether it would make sense for us to start with that to give us a leg up on the re-architecting process. If nothing else, this would at least give us an interesting insight to what some of the weaknesses are in this category, and maybe help us identify better solutions faster and more easily. In particular, if there are such serious problems with zebra/quagga that they would need to be completely re-architected in order to be useful, then I don't see that as being a particularly fruitful line of work to pursue. I'd rather start with something that requires less re-work, and would presumably allow us to more easily add in any additional bits that we feel are necessary or desirable. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)