nanog mailing list archives
Re: maximum ipv4 bgp prefix length of /24 ?
From: Matthew Petach <mpetach () netflight com>
Date: Mon, 2 Oct 2023 12:27:18 -0700
On Mon, Oct 2, 2023 at 11:46 AM Tim Franklin <tim () 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
Current thread:
- Re: maximum ipv4 bgp prefix length of /24 ?, (continued)
- Re: maximum ipv4 bgp prefix length of /24 ? Tom Beecher (Oct 02)
- 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)