[PATCH 2/4] Static protocol supports SADR

[Dean]

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.