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

[Dean]

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:

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?

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.

Thanks.