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.