Re: maximum ipv4 bgp prefix length of /24 ?

On Sat, Oct 14, 2023 at 2:37 PM John Kristoff wrote: > On Sat, 14 Oct 2023 13:59:11 -0700 > Matthew Petach wrote: > > > That last report shows that only half of the top 1000 websites on the > > Alexa ranking support IPv6. > > The Alexa ranking is no longer maintained. ISOC had a recent article

Re: maximum ipv4 bgp prefix length of /24 ?

On Wed, Oct 11, 2023 at 1:53 PM Mark Andrews wrote: > > On 12 Oct 2023, at 06:51, Delong.com wrote: > > > The point here is that at some point, even with translation, we run out > of IPv4 addresses to use for this purpose. What then? > > You deliver the Internet over IPv6. A really large

Re: maximum ipv4 bgp prefix length of /24 ?

Crap, that was supposed to be private. scott On 10/12/23 11:29 PM, scott via NANOG wrote: UGH, you called me out and I have no defense.  I was thinking of our non-NAT customers. scott On 10/12/23 11:20 PM, Mark Andrews wrote: On 13 Oct 2023, at 08:31, scott wrote: On

Re: maximum ipv4 bgp prefix length of /24 ?

UGH, you called me out and I have no defense. I was thinking of our non-NAT customers. scott On 10/12/23 11:20 PM, Mark Andrews wrote: On 13 Oct 2023, at 08:31, scott wrote: On 10/11/23 7:47 PM, Mark Andrews wrote: Virtually no home network on the planet has fully functional

Re: maximum ipv4 bgp prefix length of /24 ?

> On 13 Oct 2023, at 08:31, scott wrote: > > > > > On 10/11/23 7:47 PM, Mark Andrews wrote: >> Virtually no home network on the planet has fully functional IPv4 available >> to it. > > > Hawaiian Telcom customers have it. No blocks at all. So they don’t use NAT? The internet is a

Re: maximum ipv4 bgp prefix length of /24 ?

> On Oct 12, 2023, at 01:42, Willy Manga wrote: > > . > >> On 12/10/2023 10:00, Owen DeLong wrote: >> [...] However, IF YY is paying attention, and YY wants to advertise 2001:db8::/32 as well as allow 2001:db8:8000::/36 and 2001:db8:f000::/36, I would expect AS YY would

Re: maximum ipv4 bgp prefix length of /24 ?

Thus spake Delong.com (o...@delong.com) on Wed, Oct 11, 2023 at 12:44:35PM -0700: > > > > On Oct 11, 2023, at 11:50, Dale W. Carder wrote: > > > > Thus spake Delong.com via NANOG (nanog@nanog.org) on Tue, Oct 10, 2023 at > > 04:52:07PM -0700: > >> However, IF YY is paying attention, and YY

Re: maximum ipv4 bgp prefix length of /24 ?

. On 12/10/2023 10:00, Owen DeLong wrote: [...] However, IF YY is paying attention, and YY wants to advertise 2001:db8::/32 as well as allow 2001:db8:8000::/36 and 2001:db8:f000::/36, I would expect AS YY would generate ROAs for 2001:db8::/32 with ORIGIN-AS=YY MAXPREFIXLEN=36

Re: maximum ipv4 bgp prefix length of /24 ?

> On Oct 11, 2023, at 19:18, Willy Manga wrote: > > . > > On 11/10/2023 03:52, Delong.com wrote: >> [...] >>> RPKI only asserts that a specific ASN must originate a prefix. It does >>> nothing to validate the authenticity of the origination. >> Nope… It ALSO asserts (or can assert) an

Re: maximum ipv4 bgp prefix length of /24 ?

. On 11/10/2023 03:52, Delong.com wrote: [...] RPKI only asserts that a specific ASN must originate a prefix. It does nothing to validate the authenticity of the origination. Nope… It ALSO asserts (or can assert) an attribute of “Maximum allowed prefix length”. E.g. if I have a ROA for

Re: maximum ipv4 bgp prefix length of /24 ?

> On Oct 11, 2023, at 18:53, Willy Manga wrote: > > > . > On 11/10/2023 22:29, Delong.com wrote: >> [...] >>> Yes, but in that scenario any advertisements between /32 and /36 from that >>> prefix originated by AS65500 are *valid* . That's why "ROAs should be as >>> precise as possible,

Re: maximum ipv4 bgp prefix length of /24 ?

. On 11/10/2023 22:29, Delong.com wrote: [...] Yes, but in that scenario any advertisements between /32 and /36 from that prefix originated by AS65500 are *valid* . That's why "ROAs should be as precise as possible, meaning they should match prefixes as announced in BGP" [1] You completely

Re: maximum ipv4 bgp prefix length of /24 ?

>> The point here is that at some point, even with translation, we run out of >> IPv4 addresses to use for this purpose. What then? > > You deliver the Internet over IPv6. A really large functional Internet > exists today if you only have IPv6. It is only getting bigger. Lots of (the >

Re: maximum ipv4 bgp prefix length of /24 ?

> On 12 Oct 2023, at 06:51, Delong.com wrote: > > > >> On Oct 11, 2023, at 12:47, Mark Andrews wrote: >> >> It is no different to deploying PNAT44 in every CPE box in the world to >> allow you to connect to the global IPv4 internet today. Virtually no home >> network on the planet has

Re: maximum ipv4 bgp prefix length of /24 ?

> On Oct 11, 2023, at 12:47, Mark Andrews wrote: > > It is no different to deploying PNAT44 in every CPE box in the world to allow > you to connect to the global IPv4 internet today. Virtually no home network > on the planet has fully functional IPv4 available to it. Many businesses >

Re: maximum ipv4 bgp prefix length of /24 ?

It is no different to deploying PNAT44 in every CPE box in the world to allow you to connect to the global IPv4 internet today. Virtually no home network on the planet has fully functional IPv4 available to it. Many businesses networks don’t have fully functional IPv4 networks. We have

Re: maximum ipv4 bgp prefix length of /24 ?

> On Oct 11, 2023, at 11:50, Dale W. Carder wrote: > > Thus spake Delong.com via NANOG (nanog@nanog.org) on Tue, Oct 10, 2023 at > 04:52:07PM -0700: >> However, IF YY is paying attention, and YY wants to advertise 2001:db8::/32 >> as well as allow 2001:db8:8000::/36 and 2001:db8:f000::/36,

Re: maximum ipv4 bgp prefix length of /24 ?

> On Oct 10, 2023, at 17:20, Mark Andrews wrote: > > > >> On 11 Oct 2023, at 09:43, Delong.com via NANOG wrote: >> >>> As a community, we have failed, because we never acknowledged and addressed >>> the need for backward compatibility between IPv6 and IPv4, and instead >>> counted on

Re: maximum ipv4 bgp prefix length of /24 ?

Thus spake Delong.com via NANOG (nanog@nanog.org) on Tue, Oct 10, 2023 at 04:52:07PM -0700: > However, IF YY is paying attention, and YY wants to advertise 2001:db8::/32 > as well as allow 2001:db8:8000::/36 and 2001:db8:f000::/36, I would expect AS > YY would generate ROAs for >

Re: maximum ipv4 bgp prefix length of /24 ?

> On Oct 10, 2023, at 22:44, Willy Manga wrote: > > > > > On 11/10/2023 03:52, Delong.com wrote: >> >>> On Oct 10, 2023, at 13:36, Matthew Petach wrote: >>> [...] >>> Owen, >>> >>> RPKI only addresses accidental hijackings. >>> It does not help prevent intentional hijackings. >> OK, but

Re: maximum ipv4 bgp prefix length of /24 ?

ton , Delong.com via NANOG Subject: Re: maximum ipv4 bgp prefix length of /24 ? Date: Tue, 10 Oct 2023 15:43:28 -0700 Im not sure that we never acknowledged it, but we did fail to address it, largely because I think we basically determined that its too hard. Theres really no way for a machine with a

Re: maximum ipv4 bgp prefix length of /24 ?

> On 11/10/2023 03:52, Delong.com wrote: On Oct 10, 2023, at 13:36, Matthew Petach wrote: [...] Owen, RPKI only addresses accidental hijackings. It does not help prevent intentional hijackings. OK, but at least they can help limit the extent of required desegregation in combat unless I

Re: maximum ipv4 bgp prefix length of /24 ?

> On 11 Oct 2023, at 09:43, Delong.com via NANOG wrote: > >> As a community, we have failed, because we never acknowledged and addressed >> the need for backward compatibility between IPv6 and IPv4, and instead >> counted on magic handwaving about tipping points and transition dates where

Re: maximum ipv4 bgp prefix length of /24 ?

> On Oct 10, 2023, at 13:36, Matthew Petach wrote: > > > > On Tue, Oct 10, 2023 at 12:58 PM Delong.com via NANOG > wrote: >> Isn’t this supposed to be one of the few ACTUAL benefits of RPKI — You can >> specify the maximum prefix length allowed to be advertised

Re: maximum ipv4 bgp prefix length of /24 ?

> > The questions you ask Owen are obviously answerable by anyone with access to > a BGP routing table dump (which is pretty much anyone!). > > BGP is many things - it is a topology maintenance protocol, but its a traffic > engineering protocol and an attack mitigation protocol. In the latter

Re: maximum ipv4 bgp prefix length of /24 ?

> As a community, we have failed, because we never acknowledged and addressed > the need for backward compatibility between IPv6 and IPv4, and instead > counted on magic handwaving about tipping points and transition dates where > suddenly there would be "enough" IPv6-connected resources that

Re: maximum ipv4 bgp prefix length of /24 ?

On Tue, Oct 10, 2023 at 12:58 PM Delong.com via NANOG wrote: > Isn’t this supposed to be one of the few ACTUAL benefits of RPKI — You can > specify the maximum prefix length allowed to be advertised within a shorter > prefix and those (theoretically) block hijackers taking advantage of >

Re: maximum ipv4 bgp prefix length of /24 ?

Isn’t this supposed to be one of the few ACTUAL benefits of RPKI — You can specify the maximum prefix length allowed to be advertised within a shorter prefix and those (theoretically) block hijackers taking advantage of advertising more specifics to cut you off? While I recognize that RPKI is

Re: maximum ipv4 bgp prefix length of /24 ?

> On 10 Oct 2023, at 5:35 am, Delong.com wrote: > >> Now I’m trying to understand what your grimmer story for IPv4 might be here >> Owen. Since 2005 the number of IPv4 FIB entries per origin AS has increased >> fropm 8 to 12 in the past 20 years - or a 50% increase. Over ther same >>

Re: maximum ipv4 bgp prefix length of /24 ?

On Mon, Oct 9, 2023 at 11:38 AM Delong.com via NANOG wrote: > [...] > > My grimmer picture for IPv4 is about the intrinsic pressure to deaggregate > that comes from the ever finer splitting of blocks in the transfer market > and the ever finer grained dense packing of hosts into prefixes that is

Re: maximum ipv4 bgp prefix length of /24 ?

> On Oct 5, 2023, at 15:51, Geoff Huston wrote: > >> On 6 Oct 2023, at 6:13 am, Owen DeLong wrote: >> >> Ratio of FIB to RIB is only part of the equation. >> >> IPv6 is NOT under the disaggregation pressure that IPv4 is under because >> there is no pressure (other than perhaps scarcity

Re: maximum ipv4 bgp prefix length of /24 ?

On Sat, Oct 7, 2023 at 9:27 AM Willy Manga wrote: > Hi. > > On 06/10/2023 16:00, nanog-requ...@nanog.org wrote: > > From: Matthew Petach > [...] > > > > There's significantly less pressure to deaggregate IPv6 space right now, > > because we don't see many attacks on IPv6 number resources. > >

Re: maximum ipv4 bgp prefix length of /24 ?

On 10/7/23 14:32, Willy Manga wrote: How about we educate each other to not assume you must deaggregate your prefix especially with IPv6? I see 'some' (it's highly relative) networks on IPv4, they 'believe' they have to advertise every single /24 they have. And when they start with IPv6,

Re: maximum ipv4 bgp prefix length of /24 ?

Hi. On 06/10/2023 16:00, nanog-requ...@nanog.org wrote: From: Matthew Petach [...] The IPv6 FIB is under the same pressure from more specifics. Its taken 20 years to get there, but the IPv6 FIB is now looking stable at 60% opf the total FIB size [2]. For me, thats a very surprising outcome in

Re: maximum ipv4 bgp prefix length of /24 ?

On Wed, Oct 4, 2023 at 11:33 PM Mark Tinka wrote: > > > On 10/5/23 08:24, Geoff Huston wrote: > > The IPv6 FIB is under the same pressure from more specifics. Its taken 20 > years to get there, but the IPv6 FIB is now looking stable at 60% opf the > total FIB size [2]. For me, thats a very

Re: maximum ipv4 bgp prefix length of /24 ?

> On 6 Oct 2023, at 6:13 am, Owen DeLong wrote: > > Ratio of FIB to RIB is only part of the equation. > > IPv6 is NOT under the disaggregation pressure that IPv4 is under because > there is no pressure (other than perhaps scarcity mentality from those that > don’t properly understand IPv6) to

Re: maximum ipv4 bgp prefix length of /24 ?

On Thu, Oct 5, 2023 at 12:11 PM Owen DeLong via NANOG wrote: > So far, that seems to be largely the case, with more than 50% of ASNs > represented in the DFZ in IPv6, we see > roughly 191884 unique destinations in IPv6 and 942750 unique destinations in > IPv4 (admittedly an instantaneous >

Re: maximum ipv4 bgp prefix length of /24 ?

Ratio of FIB to RIB is only part of the equation. IPv6 is NOT under the disaggregation pressure that IPv4 is under because there is no pressure (other than perhaps scarcity mentality from those that don’t properly understand IPv6) to dense-pack IPv6 assignments or undersize IPv6 allocations.

Re: maximum ipv4 bgp prefix length of /24 ?

I think it needs to be slightly more nuanced than that… Because IPv4 is driven to dense-packing and tight allocations, I think disaggregation of IPv4 will only increase over time. The hope is that by issuing larger than needed blocks of IPv6, less disaggregation becomes necessary over time.

Re: maximum ipv4 bgp prefix length of /24 ?

On 10/5/23 08:32, Geoff Huston wrote: Not really. The stability of number in IPv4 as compared to the monotonic rise in IPv6 is what I find to be curious. I think the fact that RIR's allocate very large IPv6 address space to their members may well be what is driving this. Historically,

Re: maximum ipv4 bgp prefix length of /24 ?

On 10/5/23 08:24, Geoff Huston wrote: The IPv6 FIB is under the same pressure from more specifics. Its taken 20 years to get there, but the IPv6 FIB is now looking stable at 60% opf the total FIB size [2]. For me, thats a very surprising outcome in an essentially unmanaged system. Were

Re: maximum ipv4 bgp prefix length of /24 ?

On 10/5/23 07:49, Crist Clark wrote: But if the assumption is that networks will always eventually totally deaggregate to the maximum, we're screwed. Routing IPv4 /32s would be nothing. The current practice of accepting /48s could swell to about 2^(48 - 3) = 2^45 = 35184372088832. What

Re: maximum ipv4 bgp prefix length of /24 ?

Been resisting adding to this thread... But if the assumption is that networks will always eventually totally deaggregate to the maximum, we're screwed. Routing IPv4 /32s would be nothing. The current practice of accepting /48s could swell to about 2^(48 - 3) = 2^45 = 35184372088832. What will

Re: maximum ipv4 bgp prefix length of /24 ?

> On Oct 4, 2023, at 03:18, Mark Tinka wrote: > >  > >> On 10/4/23 09:27, Elmar K. Bins wrote: >> >> >> Justin, >> >> I'm not sure you're not confusing scope here. >> >> Everybody and their sister accept smaller blocks from their customers; we're >> all talking about the DFZ here, not

Re: maximum ipv4 bgp prefix length of /24 ?

If you maximally disaggregate to /24, you end up with about 12M fib entries. At /25 this doubles and you double it again for every bit you move right. At /24, we are on borrowed time without walking right. Also, the CPU in most routers won’t handle the churn of a 10M prefix RIB. Owen > On

Re: maximum ipv4 bgp prefix length of /24 ?

Re Mark, mark@tinka.africa (Mark Tinka) wrote: > From our customers, the most we are accepting today is a /24 and a /48. This > is for transit customers with their own AS and address space. Oh sure - I was looking at those customers who might need multihoming to their ISP, but not multihoming

Re: maximum ipv4 bgp prefix length of /24 ?

On 10/4/23 09:27, Elmar K. Bins wrote: Justin, I'm not sure you're not confusing scope here. Everybody and their sister accept smaller blocks from their customers; we're all talking about the DFZ here, not customer routes that you aggregate. Actually, we don't. From our customers, the

Re: maximum ipv4 bgp prefix length of /24 ?

On 10/4/23 12:11, Musa Stephen Honlue wrote: Which one is easier, 1. Convincing the tens of thousands of network operators and equipment vendors to modify configs and code to accept more specifics than /24, or Equipment vendors can already support 10 million entries in FIB. They just

Re: maximum ipv4 bgp prefix length of /24 ?

Which one is easier, 1. Convincing the tens of thousands of network operators and equipment vendors to modify configs and code to accept more specifics than /24, or 2. Moving to IPv6 a protocol that has been here for 20+ years ??? On Wed, 4 Oct 2023 at 12:41, William Herrin wrote: > On Tue,

Re: maximum ipv4 bgp prefix length of /24 ?

On Tue, Oct 3, 2023 at 11:56 AM Justin Wilson (Lists) wrote: > I think it is going to have to happen. We have several folks on the IX and > various consulting clients who only need 3-6 Ips but have to burn a full /24 > to participate in BGP. I wrote a blog post awhile back on this topic Hi

Re: maximum ipv4 bgp prefix length of /24 ?

li...@mtin.net (Justin Wilson (Lists)) wrote: > I think it is going to have to happen. We have several folks on the IX and > various consulting clients who only need 3-6 Ips but have to burn a full /24 > to participate in BGP. I wrote a blog post awhile back on this topic >

Re: maximum ipv4 bgp prefix length of /24 ?

I think it is going to have to happen. We have several folks on the IX and various consulting clients who only need 3-6 Ips but have to burn a full /24 to participate in BGP. I wrote a blog post awhile back on this topic

Re: maximum ipv4 bgp prefix length of /24 ?

On 02/10/2023 14:19, t...@pelican.org wrote: If the FIB is full, can we start making controlled and/or smart decisions about what to install, rather than either of the simple overflow conditions? There is a project [1] that make use of sflow to install the top n prefixes by traffic,

Re: maximum ipv4 bgp prefix length of /24 ?

> On Oct 2, 2023, at 12:19, Mark Tinka wrote: > > > > On 10/2/23 20:44, Tim Franklin wrote: > >> 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, >> > > Like I

Re: maximum ipv4 bgp prefix length of /24 ?

On a related note, I'm working on a project to handle FIB overflow in such a way as to cause the least disruption in the network. I welcome suggestions either on or off list. Kind Regards, Jakob

Re: maximum ipv4 bgp prefix length of /24 ?

On Mon, Oct 2, 2023 at 12:27 PM Matthew Petach 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 >

Re: maximum ipv4 bgp prefix length of /24 ?

On Mon, Oct 2, 2023 at 11:46 AM Tim Franklin 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

Re: maximum ipv4 bgp prefix length of /24 ?

On 10/2/23 20:44, Tim Franklin wrote: 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, Like I said, it's going to be a messy experiment - for probably a decade, at least.

Re: maximum ipv4 bgp prefix length of /24 ?

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

Re: maximum ipv4 bgp prefix length of /24 ?

> > Come on man, go re-read the post. The two paragraphs you cut literally > explained what happens -instead of- routes dropping out of the FIB or > being black holed. > Ok On Mon, Oct 2, 2023 at 2:03 PM William Herrin wrote: > On Mon, Oct 2, 2023 at 6:05 AM Tom Beecher wrote: > >> That

Re: maximum ipv4 bgp prefix length of /24 ?

On Mon, Oct 2, 2023 at 6:21 AM t...@pelican.org wrote: > On Monday, 2 October, 2023 09:39, "William Herrin" said: > > > That depends. When the FIB gets too big, routers don't immediately > > die. Instead, their performance degrades. Just like what happens with > > oversubscription elsewhere in

Re: maximum ipv4 bgp prefix length of /24 ?

On Mon, Oct 2, 2023 at 6:05 AM Tom Beecher wrote: >> That depends. When the FIB gets too big, routers don't immediately >> die. Instead, their performance degrades. Just like what happens with >> oversubscription elsewhere in the system. > > If you consider blackholing traffic because the

Re: maximum ipv4 bgp prefix length of /24 ?

On Mon, Oct 2, 2023 at 6:40 AM Joshua Miller wrote: > At this point I'd like to see data demonstrating that it's at least viable > from a statistical perspective. https://conferences.sigcomm.org/sigcomm/2013/papers/sigcomm/p111.pdf https://yangtonghome.github.io/uploads/MAoFIBC.pdf More where

Re: maximum ipv4 bgp prefix length of /24 ?

Isn’t that pretty much what Geoff Huston has done with the weekly reports William quoted earlier in this thread?Sure, that’s from a limited set of perspectives, but it probably represents the minimum achievable compression in most circumstances. OwenOn Oct 2, 2023, at 06:41, Joshua Miller

Re: maximum ipv4 bgp prefix length of /24 ?

> On Oct 2, 2023, at 01:18, Nick Hilliard 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,

Re: maximum ipv4 bgp prefix length of /24 ?

ansients during which the FIB needs to > store > mostly uncompressed anyway. > All it does is to increase convergence time. > > Kind Regards, > Jakob > > > From: William Herrin > Date: Sunday, October 1, 2023 at 6:32 PM > To: Jakob Heitz (jheitz) > Cc: nanog

Re: maximum ipv4 bgp prefix length of /24 ?

> > Then you could have knobs for what other routes you discard when you run > out of space. Receiving a covering /16? Maybe you can drop the /24s, even > if they have a different next hop - routing will be sub-optimal, but it > will work. (I know, previous discussions around traffic

Re: maximum ipv4 bgp prefix length of /24 ?

Seems like we've reached the limits of apriori speculation. At this point I'd like to see data demonstrating that it's at least viable from a statistical perspective. If someone is motivated to demonstrate this, a "backtest" against historical data would be the next step. Later, one could design

Re: maximum ipv4 bgp prefix length of /24 ?

On Monday, 2 October, 2023 09:39, "William Herrin" said: > That depends. When the FIB gets too big, routers don't immediately > die. Instead, their performance degrades. Just like what happens with > oversubscription elsewhere in the system. > > With a TCAM-based router, the least specific

Re: maximum ipv4 bgp prefix length of /24 ?

> > That depends. When the FIB gets too big, routers don't immediately > die. Instead, their performance degrades. Just like what happens with > oversubscription elsewhere in the system. > If you consider blackholing traffic because the relevant next-hops aren't present in the FIB to be looked up

Re: maximum ipv4 bgp prefix length of /24 ?

On Mon, 2 Oct 2023, Jakob Heitz (jheitz) via NANOG wrote: 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

Re: maximum ipv4 bgp prefix length of /24 ?

On Mon, Oct 2, 2023 at 1:18 AM Nick Hilliard wrote: > The difficulty with this is that if you end up with a > FIB overflow, your router will no longer route. Hi Nick, That depends. When the FIB gets too big, routers don't immediately die. Instead, their performance degrades. Just like what

Re: maximum ipv4 bgp prefix length of /24 ?

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.

Re: maximum ipv4 bgp prefix length of /24 ?

On Sun, 1 Oct 2023 at 21:19, Matthew Petach wrote: > Unfortunately, many coders today have not read Godel, Escher, Bach: An > Eternal Golden Braid, > and like the unfortunate Crab, consider their FIB compression algorithms to > be unbreakable[0]. > > In short: if you count on FIB compression

Re: maximum ipv4 bgp prefix length of /24 ?

On Sun, Oct 1, 2023 at 9:55 PM Jakob Heitz (jheitz) wrote: > my main point > is that FIB compression does not allow you to install a FIB with less memory. Hi Jakob, The math disagrees. It's called "oversubscription," and we use it all over the place in network engineering. There are only a

Re: maximum ipv4 bgp prefix length of /24 ?

Regards, Jakob From: William Herrin Date: Sunday, October 1, 2023 at 6:32 PM To: Jakob Heitz (jheitz) Cc: 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 wrote: > Among the issues: > Suppose the FIB h

Re: maximum ipv4 bgp prefix length of /24 ?

On Sun, Oct 1, 2023 at 5:40 PM Jakob Heitz (jheitz) via NANOG 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

Re: maximum ipv4 bgp prefix length of /24 ?

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 by reinstalling some of the routes and figuring out the minimum set of /21, /22, /23, /24 to make it happen. Then to

Re: maximum ipv4 bgp prefix length of /24 ?

On Sun, Oct 1, 2023 at 11:25 AM Seth David Schoen wrote: > Matthew Petach writes: > > > I would go a step further; for any system of compression hoping to gain a > > net positive space savings, > > Godel's incompleteness theorem guarantees that there is at least one > input > > to the system

Re: maximum ipv4 bgp prefix length of /24 ?

Matthew Petach writes: > I would go a step further; for any system of compression hoping to gain a > net positive space savings, > Godel's incompleteness theorem guarantees that there is at least one input > to the system that will result in no space savings whatsoever. This is rather the

Re: maximum ipv4 bgp prefix length of /24 ?

On Sun, Oct 1, 2023 at 1:03 AM Saku Ytti wrote: > On Sun, 1 Oct 2023 at 06:07, Owen DeLong via NANOG > wrote: > > > Not sure why you think FIB compression is a risk or will be a mess. It’s > a pretty straightforward task. > > Also people falsely assume that the parts they don't know about, are

Re: maximum ipv4 bgp prefix length of /24 ?

On Sat, Sep 30, 2023 at 8:04 PM Owen DeLong via NANOG wrote: > Not sure why you think FIB compression is a risk or will be a mess. It’s a > pretty straightforward task. Hi Owen, There are multiple levels of FIB compression. The simplest version merely aggregates adjacent routes with the same

Re: maximum ipv4 bgp prefix length of /24 ?

On Sun, 1 Oct 2023 at 06:07, Owen DeLong via NANOG wrote: > Not sure why you think FIB compression is a risk or will be a mess. It’s a > pretty straightforward task. Also people falsely assume that the parts they don't know about, are risk free and simple. While in reality there are tons of

Re: maximum ipv4 bgp prefix length of /24 ?

Not sure why you think FIB compression is a risk or will be a mess. It’s a pretty straightforward task. Owen > On Sep 30, 2023, at 00:03, Mark Tinka wrote: > >  > >> On 9/30/23 01:36, William Herrin wrote: >> >> >> If I were designing the product, I'd size the SRAM with that in mind.

Re: maximum ipv4 bgp prefix length of /24 ?

> About 60% of the table is /24 routes. > Just going to /25 will probably double the table size. or maybe just add 60%, not 100%. and it would take time. agree it would be quite painful. would rather not go there. sad to say, i suspect some degree of lengthening is inevitable. we have

Re: maximum ipv4 bgp prefix length of /24 ?

On 9/30/23 01:36, William Herrin wrote: If I were designing the product, I'd size the SRAM with that in mind. I'd also keep two full copies of the FIB in the outer DRAM so that the PPEs could locklessly access the active one while the standby one gets updated with changes from the RIB. But

Re: maximum ipv4 bgp prefix length of /24 ?

On 9/29/23 22:56, William Herrin wrote: Actually, BGP can swing that. Routing involves two distinct components: the routing information base (RIB) and the forwarding information base (FIB). BGP is part of the RIB portion of that process. It's always implemented in software (no hardware

Re: maximum ipv4 bgp prefix length of /24 ?

On Sat, 30 Sept 2023 at 09:42, Mark Tinka wrote: > > But when everybody upgrades, memory and processor unit prices > > decrease.. Vendors gain from demand. > > > I am yet to see that trend... Indeed. If you look like 10k/10q for Juniper their business is fairly stable in revenue and ports sold.

Re: maximum ipv4 bgp prefix length of /24 ?

On 9/29/23 06:43, VOLKAN SALİH wrote: But when everybody upgrades, memory and processor unit prices decrease.. Vendors gain from demand. I am yet to see that trend... Mark.

Re: maximum ipv4 bgp prefix length of /24 ?

On Fri, 29 Sept 2023 at 23:43, William Herrin wrote: > My understanding of Juniper's approach to the problem is that instead > of employing TCAMs for next-hop lookup, they use general purpose CPUs > operating on a radix tree, exactly as you would for an all-software They use proprietary NPUs,

Re: maximum ipv4 bgp prefix length of /24 ?

Each unit of mask length increase doubles the size of the table theoretically. About 60% of the table is /24 routes. Just going to /25 will probably double the table size. Not sure I'd like to extrapolate the estimate out to /27. Kind Regards, Jakob

Re: maximum ipv4 bgp prefix length of /24 ?

On Fri, Sep 29, 2023 at 3:26 PM Owen DeLong wrote: > > On Sep 29, 2023, at 15:14, William Herrin wrote: > > I'm less assuming it and more reading it from this SIGCOMM paper: > > https://people.csail.mit.edu/ghobadi/papers/trio_sigcomm_2022.pdf > > Fair enough, but interestingly, I think that the

Re: maximum ipv4 bgp prefix length of /24 ?

> On Sep 29, 2023, at 15:14, William Herrin wrote: > > On Fri, Sep 29, 2023 at 3:11 PM Owen DeLong wrote: >> You continue to assume that there is a fast SRAM cache. I’m not sure >> that is true. I think that all of the FIB RAM on the line cards is fast SRAM >> and no cache. > > Hi Owen, >

Re: maximum ipv4 bgp prefix length of /24 ?

On Fri, Sep 29, 2023 at 3:03 PM Tom Beecher wrote: > General Purpose CPU : Can run Doom. > Trio ASIC : Cannot run Doom. Cute. False. But cute. At the risk of pedantry, the ATMega chip in the Arduino can't run Doom either, nor does it have any DRAM, only SRAM and flash ram. Nevertheless, it

Re: maximum ipv4 bgp prefix length of /24 ?

> > I'm less assuming it and more reading it from this SIGCOMM paper: > https://people.csail.mit.edu/ghobadi/papers/trio_sigcomm_2022.pdf Which doesn't cover the subject at hand. Owen is correct here. The LU block has separate reduced latency RAM that holds the data it uses. (The FIB). Other

Re: maximum ipv4 bgp prefix length of /24 ?

On Fri, Sep 29, 2023 at 3:11 PM Owen DeLong wrote: > You continue to assume that there is a fast SRAM cache. I’m not sure > that is true. I think that all of the FIB RAM on the line cards is fast SRAM > and no cache. Hi Owen, I'm less assuming it and more reading it from this SIGCOMM paper:

Re: maximum ipv4 bgp prefix length of /24 ?

> On Sep 29, 2023, at 14:48, William Herrin wrote: > > On Fri, Sep 29, 2023 at 2:13 PM Tom Beecher wrote: >>> My understanding of Juniper's approach to the problem is that instead >>> of employing TCAMs for next-hop lookup, they use general purpose CPUs >>> operating on a radix tree, exactly

RE: maximum ipv4 bgp prefix length of /24 ?

I am reminded of something I “saw” many years ago of a Quake server running on a Juniper M160, it wasn’t fast but oh the connectivity. From: NANOG On Behalf Of Tom Beecher Sent: Saturday, September 30, 2023 11:03 AM To: William Herrin Cc: nanog@nanog.org Subject: Re: maximum ipv4 bgp prefix

Re: maximum ipv4 bgp prefix length of /24 ?

General Purpose CPU : Can run Doom. Trio ASIC : Cannot run Doom. Have a good weekend Bill. On Fri, Sep 29, 2023 at 5:48 PM William Herrin wrote: > On Fri, Sep 29, 2023 at 2:13 PM Tom Beecher wrote: > >> My understanding of Juniper's approach to the problem is that instead > >> of employing

Re: maximum ipv4 bgp prefix length of /24 ?

On Fri, Sep 29, 2023 at 2:13 PM Tom Beecher wrote: >> My understanding of Juniper's approach to the problem is that instead >> of employing TCAMs for next-hop lookup, they use general purpose CPUs >> operating on a radix tree, exactly as you would for an all-software >> router. > > Absolutely are

  1   2   >