[PATCH 1/9] Adding configuration option --enable-sadr.
toke at toke.dk
Tue Mar 7 22:07:45 CET 2017
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
>>> 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?
I meant internally in Bird (i.e. in the nest code). I think you are
mostly doing this already, just mentioned it for completeness :)
More information about the Bird-users