On 05/23/2017 07:29 PM, Ondrej Zajicek wrote:
On Tue, May 23, 2017 at 03:27:43PM +0200, Dean wrote:
On 05/23/2017 03:04 PM, Ondrej Zajicek wrote:
My opinion is that behavior of OSPF and Kernel protocols should be consistent. If OSPFv3 uses one channel and one table for SADR and non-SADR routes, then Kernel should do the same and there is no reason to connect two Kernel protocols to one kernel table. So if I understand correctly, you are saying that if the static or OSPF protocols use SADR, the kernel protocol should be required to use SADR? Not exactly, protocol instances are independent and may be connected to unrelated tables or just configured differently.
I am saying that both OSPF and Kernel protocols should be designed and implemented in consistent way w.r.t. mixing SADR and non-SADR in one routing domain.
If OSPF is designed to mix SADR and non-SADR routes in SADR_IP6 channel connected to SADR_IP6 table, so should do Kernel protocol when attached to SADR_IP6 table.
And routes from other protocols with normal IPv6 channels should be transformed to SADR routes with a ::/0 source? That is a tricky issue. I see four possibilities:
1) Some hack that allows connecting IP6 channels to SADR_IP6 tables, so unmodified protocols could add SADR routes with a ::/0 source.
2) Soma hack to Pipe protocol that allows to bridge IP6 table and SADR_IP6 table. I.e., SADR-aware protocols connected to SADR_IP6 table and other protocol to regular IP6 table, both tables connected by pipe that translates IP6 routes to SADR routes with a ::/0 source and vice versa (ignoring SADR routes with other source).
3) Modify other protocols to support SADR_IP6 (with ::/0 source).
4) Ignore the issue (use only SADR-aware protocols).
I don't like variant #3. I am not sure how acceptable is variant #4, but it may be OK - seems to me that mixing SADR-aware and SADR-unaware routing protocols rarely makes sense and in cases it does (disjunct IP ranges), it can be done by using two real kernel tables. Variant #2 is probably more clean than variant #1 from implementation POW, but probably more confusing from user POW. What is your opinion?
In #2 which table would bird table would be used as the main kernel table? What I'm worried about is that in a network that has both SADR and non-SADR routers, there can be routing loops if not explicitly avoided (my last patch tries to do this in OSPF). Keeping both SADR and non-SADR tables might cause a problem with this, the router might advertise to OSPF that it has SADR capability, but it would cause routing loops anyway when using the non-SADR routing table.