On Mon, Jan 30, 2023 at 12:54:15AM +0100, Daniel Gröber wrote: > The main motivation for this change is to allow for ingress route > filtering. With the current internal route selection proto/babel exports > only the one route it selected and an admin cannot decide which > neighbours/interfaces to import certain routes from using filters. > > To fix this we rip out the internal route selection entirely and let bird > do it's thing instead.
Hello On the first glance, this looks a bit like a reverse change what we did to RIP in v1.6.0 (years ago). The original RIP implementation did route selection in main table, did not even have internal route table, and such approach has several complications: 1) All relevant data must be in struct rte (or struct rta), not just internally in struct xyz_rte 2) Complicated interactions between generic nest logic and protocol logic 3) Problematic handling of unreachable/withdrawn route (which uses both RIP and Babel to keep info about lost reachability) 4) Less consistent behavior with other IGPs like OSPF (arguably) But, your change is less radical, as you still keep internal Babel FIB, so perhaps most of these issues are irrelevant. Will look at it. > Note that this does very much represent a breaking change as now export > filters have to explicitly re-export babel routes which was implicit > before, using say `source = RTS_BABEL`. > > It's unclear to me if we should support the old behaviour and how I would > circumvent the export filter for babel routes if so. Comments and > suggestions welcome. This could be handled in babel_preexport() by force-export regardless of filters. OTOH, Accepting some Babel route for local use, while rejecting it in export to peers may be valid use case. -- 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."
