On Tue, May 23, 2017 at 10:27:30PM +0200, Toke Høiland-Jørgensen wrote: > Ondrej Zajicek <santi...@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: santi...@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."
