maximum ipv4 bgp prefix length of /24 ?

Mon Oct 2 19:27:18 UTC 2023

On Mon, Oct 2, 2023 at 11:46 AM Tim Franklin <tim at pelican.org> wrote:

> On 02/10/2023 19:24, Matthew Petach wrote:
>
> The problem with this approach is you now have non-deterministic routing.
>
> Depending on the state of FIB compression, packets *may* flow out
> interfaces that are not what the RIB thinks they will be.
> This can be a good recipe for routing micro-loops that come and go as your
> FIB compression size ebbs and flows.
>
> Had NOT considered the looping - that's what you get for writing in public
> without thinking it all the way through *blush*.
>
> Thanks for poking holes appropriately,
> Tim.
>

No worries--if this were easy, we would have been doing it decades ago
without thinking twice.

To William's point to Tom--we are perhaps using the term "compression" in
incompatible ways at times during this conversation.

There is a difference between what the papers Williams cited are doing,
which is finding more optimal ways of storing the full structure in memory
with what I think the general thread here is talking about, which is
'proxy-aggregation' of a form--reducing the actual number of entries in the
forwarding table, regardless of the *method* of storage.

"FIB compression" of the form talked about in the papers William cited is
already being done; we don't store whole string representations of the
routing table in memory, and look them up sequentially, we store them in
binary tries, which are faster and take up less space (e, compressed), but
they still encode and represent the *whole* set of prefixes in the
forwarding table.

"FIB-count-reduction" would be a more accurate term for what we're tossing
about here, and that's where dragons lie, because that's where your FIB and
RIB no longer represent the same set of information.  And while Jon is
right, it can help struggling ISPs stave off expensive upgrades, it does so
at the cost of potentially increased troubleshooting nightmares when
packets stop going where the RIB expects them to go, and network engineers
are left scratching their heads trying to figure out why.   ^_^;

As Mark just said--sane ISPs push their vendor for a knob to disable it, so
that they can return back the land of deterministic lookups for the sanity
of their engineers.  ;)

Thanks!

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20231002/617b07a8/attachment.html>