Dean <dluga93@gmail.com> writes:
On 03/07/2017 01:17 PM, Toke Høiland-Jørgensen wrote:
Dean Luga <dluga93@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