[PATCH 2/4] Static protocol supports SADR

[Ondrej Zajicek]

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.

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.

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