[PATCH 1/9] Adding configuration option --enable-sadr.

[Dean]

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
>>   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?