Ondrej Zajicek <santi...@crfreenet.org> writes: > 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.
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
