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

[Toke Høiland-Jørgensen]

Dean <dluga93 at gmail.com> writes:

> On 03/07/2017 01:17 PM, Toke Høiland-Jørgensen wrote:
>> Dean Luga <dluga93 at gmail.com> writes:
>>
>>> That is correct, it will not be compatible with other OSPF implementations.
>>>
>>>  From what I've searched, there is no standard for supporting SADR in
>>> OSPF, only some IETF drafts (some of which expired) that describe the
>>> desired behavior.
>>>
>>> One or two of these drafts plan to use OSPF extended LSAs to support
>>> SADR, but the extended LSAs are also still drafts, and I am not sure
>>> they would cooperate with the current ospf standard.
>>>
>>> So yes, the design details are mine, but they are based on the OSPF
>>> behavior specified in these documents.
>> Ah, I see. Well, for compatibility with the Babel SADR extension, it
>> would be good if at least the nest support could be done via separate
>> data structures (Ondrej's suggestion of a separate address family is not
>> a bad one). The Babel protocol specifies an extension TLV for SADR
>> routes that can co-exist with non-SADR routes in the same network. Would
>> need to support that in Bird as well, so please take that into account
>> when you modify the Bird core :)
>>
>> -Toke
>
> Hi,
>
> I don't know much about Babel, could you go into more detail about
> this? Is the problem with the code in nest, or with the fact that my
> OSPF implementation can't be used with other nodes that use the
> standard OSPF?
>
> I tried to make it so that SADR in OSPF wouldn't affect functionality
> of other protocols. Not counting the addition of the new data
> structure, the only changes of existing code in nest should be:

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