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

[Toke Høiland-Jørgensen]

Dean <dluga93 at gmail.com> writes:

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

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