On 03/07/2017 09:23 PM, Toke Høiland-Jørgensen wrote:
Basically, I want to do the opposite: We are going to have several
(well, at least two) protocols that understand source-specific routing,
so the nest data structures should work with both. And since Babel at
least is perfectly happy to mix source-specific and regular routes (and
will interoperate with an implementation that only supports the latter),
the nest data structures and lookup functions shouldn't be hidden behind
a configure switch (but the OSPF support might be I guess, unless you
can make it run-time configurable without too much hassle).
1. the fib_node structure having a couple more data fields. If a protocolSome data structure overhead is probably fine.
doesn't use them, this data won't hurt it, right?
2. fib_get, fib_find, fib_route, net_get, and net_find functions mightYeah, the behaviour for non-source-specific routes should be unchanged,
do some more processing, but they should ultimately have the same
behavior.
and it should do something sensible when both types of routes exist.
Haven't gotten around to thinking seriously about how I'd implement
source-specific routing for Babel in Bird yet, so you're kinda breaking
new ground here; but happy to be a voice in the background at least
-Toke