[PATCH 1/9] Adding configuration option --enable-sadr.
dluga93 at gmail.com
Tue Mar 7 22:02:04 CET 2017
On 03/07/2017 09:51 PM, Toke Høiland-Jørgensen wrote:
> Dean <dluga93 at 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
>> 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
>> 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:
> Not sure how Bird can check for this, but if you're only supporting
> Linux IPV6_SUBTREES I guess it'll be fine...
> (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?
More information about the Bird-users