nanog mailing list archives
Re: maximum ipv4 bgp prefix length of /24 ?
From: William Herrin <bill () herrin us>
Date: Mon, 2 Oct 2023 14:11:15 -0700
On Mon, Oct 2, 2023 at 12:27 PM Matthew Petach <mpetach () netflight com> wrote:
There is a difference between what the papers William 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.
Hi Matthew, Either you're misreading the papers or I quoted the wrong ones. Apologies if it's the latter. The RIB is stored in a trie (a radix tree) in essentially all router implementations. From there it's processed into a FIB whose design depends on the hardware implementing it. For a software implementation that's another trie, sometimes with hash-based cache of current activity. For a TCAM, it's an array ordered from most specific to least specific. (TCAMs are special hardware that processes every array element simultaneously instead of linearly.) These structures don't change with FIB compression. What changes is the number of routes stored in them and the complexity of the software that translates the RIB into a FIB.
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. ;)
Just so it doesn't get lost - I endorse that idea as well. With a very few exceptions, I think the operator should have sufficient knobs to control how their equipment does its work. The developer doesn't (and can't) know all of the situations the operator will encounter, so can't plan his software to be smart enough to always do the right thing on its own. The exceptions deal with knobs where the operator is not just likely shoot themselves in the foot but likely shoot other people too. That doesn't apply here. Regards, Bill Herrin -- William Herrin bill () herrin us https://bill.herrin.us/
Current thread:
- Re: maximum ipv4 bgp prefix length of /24 ?, (continued)
- Re: maximum ipv4 bgp prefix length of /24 ? tim () pelican org (Oct 02)
- Re: maximum ipv4 bgp prefix length of /24 ? Joshua Miller (Oct 02)
- Re: maximum ipv4 bgp prefix length of /24 ? Owen DeLong via NANOG (Oct 02)
- Re: maximum ipv4 bgp prefix length of /24 ? William Herrin (Oct 02)
- Re: maximum ipv4 bgp prefix length of /24 ? Tom Beecher (Oct 02)
- Re: maximum ipv4 bgp prefix length of /24 ? Matthew Petach (Oct 02)
- Re: maximum ipv4 bgp prefix length of /24 ? Tim Franklin (Oct 02)
- Re: maximum ipv4 bgp prefix length of /24 ? Mark Tinka (Oct 02)
- Re: maximum ipv4 bgp prefix length of /24 ? Delong.com via NANOG (Oct 02)
- Re: maximum ipv4 bgp prefix length of /24 ? Matthew Petach (Oct 02)
- Re: maximum ipv4 bgp prefix length of /24 ? William Herrin (Oct 02)
- Re: maximum ipv4 bgp prefix length of /24 ? Chris Hills (Oct 03)
- Re: maximum ipv4 bgp prefix length of /24 ? Owen DeLong via NANOG (Oct 02)
- Re: maximum ipv4 bgp prefix length of /24 ? Jakob Heitz (jheitz) via NANOG (Oct 02)
- Re: maximum ipv4 bgp prefix length of /24 ? Jon Lewis (Oct 02)
- Re: maximum ipv4 bgp prefix length of /24 ? Owen DeLong via NANOG (Oct 02)
- Re: maximum ipv4 bgp prefix length of /24 ? Elmar K. Bins (Oct 04)
- Re: maximum ipv4 bgp prefix length of /24 ? Mark Tinka (Oct 04)
- Re: maximum ipv4 bgp prefix length of /24 ? Elmar K. Bins (Oct 04)
- Re: maximum ipv4 bgp prefix length of /24 ? Owen DeLong via NANOG (Oct 04)