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? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."