Re: maximum ipv4 bgp prefix length of /24 ?
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. Kind 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 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 b...@herrin.us https://bill.herrin.us/
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 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 b...@herrin.us https://bill.herrin.us/
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 avoid a transient, it needs to make before break. Quite a bit of FIB programming needs to happen just to modify a single /24. Then the next /24 in the set also modifies its nexthop. and so on for 10 routes. All because a peer link flapped. Affecting convergence. Then you need to buy a line card that can hold all the individual routes, because you can't always compress, because not all the routes in your compressed set have the same nexthop during a transient. Finally, it's all nicely compressed. Now what? You have lots of empty slots in your FIB. I'm sure lots of nerds can come up with transient reduction algorithms, but I'd rather not. Kind Regards, Jakob --- Date: Sat, 30 Sep 2023 20:04:29 -0700 From: Owen DeLong Not sure why you think FIB compression is a risk or will be a mess. It?s a pretty straightforward task. Owen
U.S. test of national alerts on Oct. 4 at 2:20pm EDT (1820 UTC)
This year's test of the U.S. national emergency alert includes something for ISPs and network operators. The wireless portion of the national test is scheduled 2 minutes (2:18pm EDT or 1818 UTC) before the main broadcast test at 2:20. Mobile phones usually receive the alert about a minute later. Radio and TV will receive the national alert a few minutes after 2:20pm. iPhone iOS 17 added a new feature for Wireless Emergency Alerts. When iOS 17 iPhones get a wireless emergency alert (WEA), it will trigger a data network query for additional information. Its a small query and response, but there are a lot of iPhones making the query at the same time (I'm assuming Apple engineer's have built in some time skew). Apple has assured FEMA that Apple's CDN and servers will be able to handle the triggered load. The iOS 17 triggered query will either be a tiny blip in the network graphs around 2:18pm to 2:22pm which no one will notice, or some CDNs and ISP operators will be wondering what that heck that spike was. If your phone is configured with Spanish, it will display the alert in both English and Spanish. “THIS IS A TEST of the National Wireless Emergency Alert System. No action is needed.” “ESTA ES UNA PRUEBA del Sistema Nacional de Alerta de Emergencia. No se necesita acción.” You'll know your iOS17 device did an extra data query, if it displays a longer message (extra sentences) in addition to the messages above. "This is only a test. No action is required by the public." https://www.fema.gov/press-release/20230803/fema-and-fcc-plan-nationwide-emergency-alert-test-oct-4-2023
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 that will result in no space savings whatsoever. > > This is rather the Pigeonhole Principle that guarantees this. > > https://en.wikipedia.org/wiki/Lossless_compression#Limitations Ah, thank you for the more specific pointer--a good read, though slightly less entertaining than Hofstadter. ^_^ Matt
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 Pigeonhole Principle that guarantees this. https://en.wikipedia.org/wiki/Lossless_compression#Limitations
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 > risk free and simple. > > While in reality there are tons of proprietary engineering choices to > make devices perform in expected environments, not arbitrary > environments. So already today you could in many cases construct > specific FIB, which exposes these compromises and makes devices not > perform. 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. If your device is counting on FIB compression to deliver sufficient space savings to allow a FIB of size > SRAM to fit into SRAM, it really should have a reasonable, sane fallback mode for when the next routing update happens to result in a FIB that is incompressible. 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]. As I discovered many years ago, at web scale, even seemingly highly-improbable sequences of bits end up happening frequently enough to become problematic. In short: if you count on FIB compression working at a compression ratio greater than 1 in order for your network to function, you had better have a good plan for what to do when your phone rings at 3am because your FIB has just become incompressible. ^_^; Matt [0]. https://genius.com/Douglas-hofstadter-contracrostipunctus-annotated
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 next hop. Straightforward, as you say. However, there are more advanced versions of FIB compression as well. Routers have an implicit default route to a drop-and-report target. Pragmatically, though, the user doesn't really care what happens to unroutable packets: they can't reach a destination regardless. If you replace that implicit default route with a "don't care," you can roll up the entire address space into a set of "send everything to this next hop with these exceptions." And you can build on that recursively to get extraordinary FIB compression. This latter version, however, is not straightforward. Bugs that escape QC are quite a bit more likely. Will Juniper stop with the simplest version of FIB compression where not much can go wrong? Not if it works and customers like it. Regards, Bill Herrin -- William Herrin b...@herrin.us https://bill.herrin.us/
Re: Discord contacts
I don't know if this is related or not, but we've been working a strange issue with a Cloudflare-hosted site for weeks now, where some source IPs incur a 45-60 second delay on page-loads to a specific web-site, but other source IPs load instantaneously. We can't find a common denominator. We've tested from the same physical location using two different subnets, and one works; the other misbehaves. We've ruled out that it's not a superblock thing either. Both we and the web-site owner have tickets open with them. In our ticket, they actually conceded that they were able to reproduce the problem internally, but it still hasn't gotten anywhere. Dehr? On 9/29/23 15:03, Rubens Kuhl wrote: This issue is also happening with services other than Discord, so pointing to a Cloudflare issue. Discord may be just the canary in the coal mine. Rubens On Fri, Sep 29, 2023 at 9:34 AM Drew Weaver wrote: Any contacts from Discord here? Just started seeing cloudflare blocking 250,000 IP addresses. Thanks, -Drew
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 proprietary engineering choices to make devices perform in expected environments, not arbitrary environments. So already today you could in many cases construct specific FIB, which exposes these compromises and makes devices not perform. There are dragons everywhere, but we can remain largely ignorant of them, as these engineering choices tend to be reasonable. Sometimes they are abused by shops like EANTC and Miercom for marketing reasons for ostensibly 'independent' tests. I think this compression is part of this continuum, magic inside the box I hope works because I can't begin to have a comprehensive understanding exactly how much risk I am carrying. Pretty much all performant boxes no longer have bandwidth to store all packets in memory (partial buffering), many of them have 'hot' and 'cold' prefixes. You just gotta hope, you're not gonna be able to prove anything, and by trying to do so, you're more likely to increase your costs due to false positives than you are to find an actionable problem. Most problems don't matter, figuring out which problem needs to be fixed is hard. -- ++ytti
