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.
