> On Oct 2, 2023, at 01:18, Nick Hilliard <[email protected]> wrote:
>
> William Herrin wrote on 02/10/2023 08:56:
>> All it means is that you have to keep an eye on your FIB
>> size as well, since it's no longer the same as your RIB size.
>
> the point Jacob is making is is that when using FIB compression, the FIB size
> depends on both RIB size and RIB complexity. I.e. what was previously a
> deterministic 1:1 ratio between RIB and FIB - which is straightforward to
> handle from an operational point of view - becomes non-deterministic. The
> difficulty with this is that if you end up with a FIB overflow, your router
> will no longer route.
It was never 1:1 if you have more than one path for any route. The FIB only
contains the chosen path(s) to any destination even without fib compression.
>
> That said, there are cases where FIB compression makes a lot of sense, e.g.
> leaf sites, etc. Conversely, it's not a generally appropriate technology for
> a dense dfz core device. It's a tool in the toolbox, one of many.
Even at a dense DFZ core device, there are a large number of single-origin
consecutive /24s in the table which can be fib compressed with no loss. For a
long time, someone was teaching up and coming operators in Asia that they
should always announce everything as disaggregated /24s to guard against route
hijacking. This unfortunate practice persists still, making FIB compression
quite practical even at core nodes.
Owen
>
> Nick
