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