While I did allude to some of the complexity, my main point
is that FIB compression does not allow you to install a FIB with less memory.
Because you must be prepared for transients during which the FIB needs to store
mostly uncompressed anyway.
All it does is to increase convergence time.
From:
William Herrin <bill@herrin.us>
Date: Sunday, October 1, 2023 at 6:32 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: nanog@nanog.org <nanog@nanog.org>
Subject: Re: maximum ipv4 bgp prefix length of /24 ?
On Sun, Oct 1, 2023 at 5:40 PM Jakob Heitz (jheitz) via NANOG
<nanog@nanog.org> wrote:
> Among the issues:
> Suppose the FIB has all the /24 components to make a /20, so it programs a /20.
> Then one of the /24's changes nexthop. It now has to undo all that compression
Yeah... all this stuff is on the same level of complexity as
implementing a B-Tree. Standard task on the road to an undergraduate
computer science degree. Compared to decoding a BGP update message,
where nearly everything is variable length and you have to nibble away
at the current field to find the start of the next field, this is a
cakewalk.
It doesn't actually get complicated until you want to do more than
just joining adjacent address blocks.
Regards,
Bill Herrin
--
William Herrin
bill@herrin.us
https://bill.herrin.us/