bikeshed for all!

[Julian Elischer]

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