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
protocol
doesn't use them, this data won't hurt it, right?
Some data structure overhead is probably fine.
2. fib_get, fib_find, fib_route, net_get, and net_find functions might
do some more processing, but they should ultimately have the same
behavior.
Yeah, the behaviour for non-source-specific routes should be unchanged,
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
Oh, I see what you mean. Since Babel works better with SADR, the nest
changes should be more focused on Babel, *then* OSPF should make use of
them. Instead of the other way around.
