From owner-freebsd-net@FreeBSD.ORG Fri Dec 14 01:53:43 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F1AF16A468 for ; Fri, 14 Dec 2007 01:53:43 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outI.internet-mail-service.net (outI.internet-mail-service.net [216.240.47.232]) by mx1.freebsd.org (Postfix) with ESMTP id 037E313C46A for ; Fri, 14 Dec 2007 01:53:42 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Thu, 13 Dec 2007 17:53:41 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 713D1126C9E; Thu, 13 Dec 2007 17:53:41 -0800 (PST) Message-ID: <4761E222.7060302@elischer.org> Date: Thu, 13 Dec 2007 17:53:38 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <476061FD.8050500@elischer.org> <200712130021.56473.max@love2party.net> <476072DB.3090600@elischer.org> <200712131549.21669.nvass@teledomenet.gr> <476190F2.2030105@elischer.org> <47619502.5070404@FreeBSD.org> <4761AC47.2010904@elischer.org> <20071213221607.Q81630@maildrop.int.zabbadoz.net> <4761B9CC.1020008@elischer.org> <20071213235843.Q81630@maildrop.int.zabbadoz.net> <4761D31F.10602@FreeBSD.org> In-Reply-To: <4761D31F.10602@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , freebsd-net@freebsd.org Subject: Re: bikeshed for all! X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 01:53:43 -0000 Bruce M. Simpson wrote: > Hi, > > Just to chime in and agree with Bjoern, I'm finishing up a routing > protocol right now so this discussion is somewhat timely. > > I disagree that this is a "bikeshed", quite the contrary -- the visual > and the verbal have to live together, and it's easy for those of us who > have the semantic map in our minds right now to dismiss the discussion > as such. > > Try walking away from it for 6-9 months, come back, and try to get back > into it -- choosing good terminology upfront DOES make a difference to > maintainability of code, and it will make it easier for others > (students, newbies, other folk) to get involved. > > Anyway: > > Some folk (e.g. Marko) prefer the term table, though any way you look at > it, the fib usually uses a trie as its backend data structure -- > although the TRASH structure Linux has been using is a cross between the > trie and the hash table. > > So perhaps there is some merit in say... setroutetbl. > > after all, folk tend to call a "forwarding table entry" a route for the > sake of brevity. > > Bjoern A. Zeeb wrote: >> >> FIB (Forwarding Information Base) has been very standard for years and >> is often confused with foo and bar;-) > > Microsoft use this logical separation of routing and forwarding > functions in their implementation of IP routing, although they don't > call their "routing table" a FIB, they call it a "forwarding table", and > the entries in this are called "forwarding table entries". > > XORP adopted the RIB/FIB split from the start as a design decision, in > doing so the functions of routing protocols can be kept logically > separate from the forwarding plane, which could be hardware, software, > or even a combination thereof (e.g. Cisco CEF). > > The way this has played out follows the traditional BSD way, where > routing protocols (e.g. routed) live in userland, whilst forwarding > (e.g. ip_forward()) lives in the kernel. Yes, and it seems that some reference to forwarding would be correct. What I'm implementing is, as Qing said, a form of policy based forwarding i.e. you can use a broad set of criteria to select a "FIB" (to use the terms here) dependent on a number of criteria. Criteria include source socket (for local connections) which is derived from process information at socket creation time, or a socket option. Firewalls such as pf or ipfw can also select a FIB for a particular incoming packet to be forwarded. the user tool that sets a default FIB for a process could simply be called fib or setfib. I think setfib. vrf has too much extra baggage that I'm not doing.. for real vrf you want vimage. Table instances makes sense but, it's just too long. > > cheers > BMS