[PATCH 2/4] Static protocol supports SADR

[Ondrej Zajicek]

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 at 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."