Dean <dlug...@gmail.com> writes: > On 03/07/2017 09:51 PM, Toke Høiland-Jørgensen wrote: >> Dean <dlug...@gmail.com> 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 > >> (2) make sure that SADR routes and non-SADR routes can coexist in the same >> routing table. > Is that something that can be fixed in BIRD? Isn't it just a kernel problem?
I meant internally in Bird (i.e. in the nest code). I think you are mostly doing this already, just mentioned it for completeness :) -Toke
