Dean <[email protected]> writes: > 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.
Well, I'm mostly just trying to ensure that the changes you make to support SADR routing will be compatible with Babel, when I do get around to implementing it there as well. Would be silly if you go through a lot of effort of testing that everything works as it's supposed to, which then has to be redone because the implementation needs to be changed to support Babel as well. Better get it right the first time; so it needs to support the union of functionality of both protocols... But by all means, go ahead with your implementation rather than wait for me to get around to doing the Babel part. I think the main things to support would be (1) make the nest changes "always on" (i.e. not hidden behind a configure switch), and (2) make sure that SADR routes and non-SADR routes can coexist in the same routing table. Also, if you haven't already, I'd suggest reading section three of the Babel SADR draft: https://tools.ietf.org/html/draft-boutier-babel-source-specific-01#section-3 Not sure how Bird can check for this, but if you're only supporting Linux IPV6_SUBTREES I guess it'll be fine... -Toke
