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

[Toke Høiland-Jørgensen]

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 
>  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 
>
> 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:
https://tools.ietf.org/html/draft-boutier-babel-source-specific-01#section-3

Not sure how Bird can check for this, but if you're only supporting
Linux IPV6_SUBTREES I guess it'll be fine...

-Toke