[PATCH 2/4] Static protocol supports SADR

[Dean]

On 05/24/2017 03:53 PM, Ondrej Zajicek wrote:
> On Tue, May 23, 2017 at 08:03:38PM +0200, Dean wrote:
>>>> 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:
>>>
>>> 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).
>> In #2 which table would bird table would be used as the main kernel table?
> Usually the SADR table. Otherwise, no SADR route could be pushed to main
> kernel table.
>
> Something like:
>
> ipv6 table tab1;
> ipv6 sadr table tab2:
>
> protocol ospf v3 {
>      ipv6 sadr {
>          table tab2;
>      }
> }
>
> protocol rip {
>      ipv6 {
>          table tab1;
>      }
> }
>
> protocol kernel {
>      ipv6 sadr {
>          table tab2;
>          export all;
>      }
> }
>
> protocol pipe {
>      table tab1;
>      peer table tab2;
>      export all;
>      import all;
> }
>
> For clarity, the example uses explicit tables in channel definitions.
>
>
>> 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.
> Well, it is potentially problematic issue, but IMHO it is more an
> operational issue to have reasonable configuration and network design.
> The alternatives #1-#4 are more or less equivalent w.r.t. that.
>
>
> Also, we discussed that internally and agreed that #2 is a way to go. It
> avoids pitfalls of #1 and allows additional configuration. As sometimes
> it makes sense that non-SADR routes are translated to SADR routes with
> configurable src/from other than ::/0. E.g.:
>
> I have a gateway router with internal OSPF SADR network and two uplinks
> from two ISPs that propagate a default route by RIP. Each uplink is valid
> for associated prefix range assigned by that ISP, but RIP itself does not
> know about that. So configuration would be like main SADR table connected
> to OSPF and Kernel, and two non-SADR tables connected to appropriate RIPs,
> and pipes between non-SADR tables and the SADR table, the pipes would be
> configured to assign appropriate src/from to the routes propagated from
> non-SADR to SADR table based on ISP range.
>
> Now i have a pretty clear idea how to implement the pipe hack anyway, so
> perhaps the best way to continue would be that you just ignore the issue
> and implement just interaction between SADR-aware protocols, while i will
> add the pipe hack later.
>
Ok, sounds good.