Re: [PATCH 1/9] Adding configuration option --enable-sadr.
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.
Dean <dluga93@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
On 03/07/2017 09:51 PM, Toke Høiland-Jørgensen wrote:
Dean <dluga93@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
(2) make sure that SADR routes and non-SADR routes can coexist in the same routing table. Is that something that can be fixed in BIRD? Isn't it just a kernel problem?
Dean <dluga93@gmail.com> writes:
On 03/07/2017 09:51 PM, Toke Høiland-Jørgensen wrote:
Dean <dluga93@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
(2) make sure that SADR routes and non-SADR routes can coexist in the same routing table. Is that something that can be fixed in BIRD? Isn't it just a kernel problem?
I meant internally in Bird (i.e. in the nest code). I think you are mostly doing this already, just mentioned it for completeness :) -Toke
(2) make sure that SADR routes and non-SADR routes can coexist in the same routing table.
Is that something that can be fixed in BIRD? Isn't it just a kernel problem?
Kernel may be fixed once. Or you may have two kernel protocols mapping the BIRD's table to one kernel table with SADR and another without SADR. Filters may be used for this distinction. Or there may be another system supporting mixed both types in one table, e.g. some BSD. MQ
participants (3)
-
Dean -
Jan Matejka -
Toke Høiland-Jørgensen