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: santi...@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."
