[PATCH 2/4] Static protocol supports SADR

[Toke Høiland-Jørgensen]

Ondrej Zajicek <santiago at crfreenet.org> writes:

> On Tue, May 23, 2017 at 10:27:30PM +0200, Toke Høiland-Jørgensen wrote:
>> Ondrej Zajicek <santiago at crfreenet.org> writes:
>> 
>> >> 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.
>> 
>> Semantically, a SADR-aware route with source ::/0 is equivalent to a
>> non-SADR aware route. So what about a variant of this that makes the
>> SADR information be always available in the routing table, and just
>> filters out routes with non-zero source prefix for protocols that are
>> not SADR-aware?
>> 
>> I'm not sure if it's even necessary with a separate address type for
>> SADR in this case?
>
> Having separate SADR address type and routing table type is mostly an
> implementation issue. We do not want to have unused src field in
> net_addr_ip6 to make it always two times larger for a border case of
> SADR users.

Hmm, fair enough I suppose ;)

> In the far future, perhaps we change SADR source field to be an
> optional route attribute. That would be elegant and allow to have
> optional SADR routes in regular routing table (like in Linux kernel).
> But it is incompatible with many BIRD design decisions w.r.t. how
> routes, routing table and channels interact. Currently, we use
> net_addr as a primary key, so if we want to have multiple 'best'
> routes with the same dst (and different src), both dst+src have to be
> in net_addr.

Yeah, this makes sense, longer term. And is, incidentally, pretty close
to how the Babel working group is converging on encoding SADRs (as an
attribute (sub-TLV) of routes).

-Toke