Filter babel routes on a per-neighbor or per-interface basis

[Ondrej Zajicek]

On Thu, Jul 22, 2021 at 08:17:54PM +0200, Toke Høiland-Jørgensen wrote:
> > Would it be possible to send all feasible babel routes to the bird
> > table?
> 
> I don't think this would be the right approach; rather, there should be
> a filtering step before routes are input into the babel route selection,
> as mentioned above. And possibly adding an output filter so routes can
> be modified on a per-interface basis would make sense as well?

Hi

I think that (optionally) pushing all feasible routes to the BIRD table
seems like an interesting idea. It would be relatively easy (by using the
same mechanism that is here for BGP ADD-PATH). Babel already requires
importing the selected route back in order to announce it to peers, so it
would be possible to move best route selection completely to the BIRD table
(by moving some logic from babel_select_route() to babel_rte_better()).

It also has some unortodox applications, like using different feasible
routes for different routing tables with rule-based routing.

But disadvantage is that it would require having two distinct modes
of operation (the current one and this new one).

Adding import (and perhaps export) per-interface filters is also an
interesting idea. I thought about it in the past in context of RIP, but
one obstacle is that the filtering code assumes it runs on struct rte,
so you would need to convert it back and forth between struct rte and
struct babel_route. The advantage is that it would integrate easily
into current mode of operation.

Seems to me that these two approaches are not exclusive and try to
solve slightly different use cases.


> > Also, this makes it impossible to use ECMP with babel.
> 
> Babel (the protocol) does not support ECMP. This is deliberate - see
> this message for details:
> https://mailarchive.ietf.org/arch/msg/babel/i4tqsRIL3DS9e22GJ0QuoMef-P0/

Some notes to ECMP:

First, it is kind of unrelated to whether we send multiple routes to the
main table. On the contrary, ECMP in BIRD in general works that protocol
merges feasible routes to one route with ECMP next hop and such route is
propagated to the main table. So sending multiple non-merged routes to
the main table is problematic for ECMP (it is done by BGP, where we do
not have 'internal BGP table').

Second, i do not think there is a strong reason to not support ECMP in
Babel. It is true that for ad-hoc wifi networks it is probably not that
advantageous, but Babel has also support for running on traditional wired
networks (fixed rxcost, k-out-of-j selection for failure detection) and
there ECMP makes full sense.

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