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. >> 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 I'd design the router to >> gracefully fail if the FIB exceeded what the SRAM could hold. >> >> When a TCAM fills, the shortest prefixes are ejected to the router's >> main CPU. That fails pretty hard since the shortest prefixes tend to >> be among the most commonly used. By comparison, an SRAM cache tends to >> retain the most commonly used prefixes as an inherent part of how >> caches work, regardless of prefix length. It can operate close to full >> speed until the actively used routes no longer fit in the cache. > > Well, not sure if you're aware, but starting Junos 21.2, Juniper are > implementing FIB Compression on the PTX routers running Express 4 and Junos > EVO. > > We have some of these boxes in our network (PTX10001), and I have asked > Juniper to provide a knob to allow us to turn it off, as it is currently > going to ship as a default-on feature. I'd rather not be part of the > potential mess that is going to come with the experimentation of that over > the next decade. > > Mark.
new net neutrality/title ii mailing list
Since network neutrality and title ii regulation is back in the news, and the issues so fraught with technical and political mis-conceptions, I have started a new mailing list to discuss it, and try (for once) to feed back valid techical feedback into the FCC´s normal processes. I kind of expect some EU-derived regulatory ideas to emerge, in particular. Sign up here: https://lists.bufferbloat.net/listinfo/nnagain The FCC chair has put out the following statement, and is circulating a proposed NPRM to be released Oct 19th. https://docs.fcc.gov/public/attachments/DOC-397257A1.pdf ... There is another FCC effort on a cybersecurity label due october 6th, which amazingly, a FCC commissioner had reached out to hackernews on, and got back loads of wonderful feedback. https://news.ycombinator.com/item?id=37392676 -- Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html Dave Täht CSO, LibreQos
Re: Legal system as a weapon (was Re: AFRINIC placed in receivership)
Hi David Thanks for sharing this. So, its seems like Lu is continuing with his legal intimadations across other RIR regions. Christopher Hawker, should not be intimidated. I was the first internet community members to be sued by Lu and I believe Amin was the second and Brian and Benedict cases followed across the AFRINIC region who also faced similar legal suits. Some of the defamation cases across various high courts have since been dismissed after over one year litigations and defending ourselves. I personally never thought of seeking support from anyone as no one came to offer it. But I remained positive with my legal counsel who was able to take up the case within my means and continued to legally represent me and defend me within my financial means. I believe the same is true for both Amin in Nigeria, Brian in Malawi and Benedict in TZ. We believe in what we stand for across Africa in as far as AFRINIC is concerned and it is worthwhile experience for the future of Africa for we understand how digital transformation has impacted out continent with the small IPv4 space that was allocated to us by IANA when AFRINIC was formed. We have managed to do something with it in the last decades to transform out continent and no bully shall deter us from the noble cause. In any case, all the best to Christopher Hawker and in case you need some ideas or references on how to go about Lu, please reach out. Noah On Fri, 29 Sept 2023, 01:48 David Conrad, wrote: > Somewhat related (at least one of the principals is the same) and perhaps > of interest to some here. While I have strong opinions on the topic, > provided without comment: > > https://www.gofundme.com/f/supporting-and-protecting-internet-governance > > Regards, > -drc > > On Sep 13, 2023, at 6:27 PM, Bryan Fields wrote: > > > I think this qualifies as potentially operational. > > Afrinic placed in receivership, board elections to be held in six months: > https://archive.ph/jOFE4 > -- > Bryan Fields > > 727-409-1194 - Voice > http://bryanfields.net > > >
Re: Legal system as a weapon (was Re: AFRINIC placed in receivership)
Lol Le 30 septembre 2023 19:49:29 UTC, Mel Beckman a écrit : >Just like a lawyer, trying to add layers to the model. :) > > -mel > >> On Sep 30, 2023, at 8:58 AM, Anne Mitchell wrote: >> >> >> >>> On Sep 29, 2023, at 11:20 PM, Mel Beckman wrote: >>> >>> The seven lawyers of the OSI model >>> >>> 1: Family lawyer (where it all starts) >>> 2: Admiralty lawyer >>> 3: Intellectual Property lawyer (because, of course) >>> 4. Immigration lawyer >>> 5. Real Estate lawyer >>> 6. Entertainment lawyer >>> 7. Labor lawyer >>> >> >> You forgot Estate Planning lawyer and, of course, email law and policy >> lawyer. :-) >> >> Anne >> >> --- >> Anne P. Mitchell, Esq. >> Email Law & Policy Attorney >> CEO Institute for Social Internet Public Policy (ISIPP) >> Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal email marketing >> law) >> Creator of the term 'deliverability' and founder of the deliverability >> industry >> Author: The Email Deliverability Handbook >> Board of Directors, Denver Internet Exchange >> Dean Emeritus, Cyberlaw & Cybersecurity, Lincoln Law School >> Prof. Emeritus, Lincoln Law School >> Chair Emeritus, Asilomar Microcomputer Workshop >> Counsel Emeritus, eMail Abuse Prevention System (MAPS) >> >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Legal system as a weapon (was Re: AFRINIC placed in receivership)
Just like a lawyer, trying to add layers to the model. :) -mel > On Sep 30, 2023, at 8:58 AM, Anne Mitchell wrote: > > > >> On Sep 29, 2023, at 11:20 PM, Mel Beckman wrote: >> >> The seven lawyers of the OSI model >> >> 1: Family lawyer (where it all starts) >> 2: Admiralty lawyer >> 3: Intellectual Property lawyer (because, of course) >> 4. Immigration lawyer >> 5. Real Estate lawyer >> 6. Entertainment lawyer >> 7. Labor lawyer >> > > You forgot Estate Planning lawyer and, of course, email law and policy > lawyer. :-) > > Anne > > --- > Anne P. Mitchell, Esq. > Email Law & Policy Attorney > CEO Institute for Social Internet Public Policy (ISIPP) > Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal email marketing > law) > Creator of the term 'deliverability' and founder of the deliverability > industry > Author: The Email Deliverability Handbook > Board of Directors, Denver Internet Exchange > Dean Emeritus, Cyberlaw & Cybersecurity, Lincoln Law School > Prof. Emeritus, Lincoln Law School > Chair Emeritus, Asilomar Microcomputer Workshop > Counsel Emeritus, eMail Abuse Prevention System (MAPS) > >
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 ourselves to blame; but blame does not move packets. randy, who was in the danvers cabal for the /19 agreement
Re: Legal system as a weapon (was Re: AFRINIC placed in receivership)
> On Sep 29, 2023, at 11:20 PM, Mel Beckman wrote: > > The seven lawyers of the OSI model > > 1: Family lawyer (where it all starts) > 2: Admiralty lawyer > 3: Intellectual Property lawyer (because, of course) > 4. Immigration lawyer > 5. Real Estate lawyer > 6. Entertainment lawyer > 7. Labor lawyer > You forgot Estate Planning lawyer and, of course, email law and policy lawyer. :-) Anne --- Anne P. Mitchell, Esq. Email Law & Policy Attorney CEO Institute for Social Internet Public Policy (ISIPP) Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal email marketing law) Creator of the term 'deliverability' and founder of the deliverability industry Author: The Email Deliverability Handbook Board of Directors, Denver Internet Exchange Dean Emeritus, Cyberlaw & Cybersecurity, Lincoln Law School Prof. Emeritus, Lincoln Law School Chair Emeritus, Asilomar Microcomputer Workshop Counsel Emeritus, eMail Abuse Prevention System (MAPS)
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 I'd design the router to gracefully fail if the FIB exceeded what the SRAM could hold. When a TCAM fills, the shortest prefixes are ejected to the router's main CPU. That fails pretty hard since the shortest prefixes tend to be among the most commonly used. By comparison, an SRAM cache tends to retain the most commonly used prefixes as an inherent part of how caches work, regardless of prefix length. It can operate close to full speed until the actively used routes no longer fit in the cache. Well, not sure if you're aware, but starting Junos 21.2, Juniper are implementing FIB Compression on the PTX routers running Express 4 and Junos EVO. We have some of these boxes in our network (PTX10001), and I have asked Juniper to provide a knob to allow us to turn it off, as it is currently going to ship as a default-on feature. I'd rather not be part of the potential mess that is going to come with the experimentation of that over the next decade. Mark.
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 acceleration). It's not consulted per-packet, so as long as the update rate is slow enough for the CPU to keep up and there's enough DRAM (which is cheap and plentiful these days) to hold the entire thing, there's no particular upper bound to the number of routes. Not unless you are running BGP Add-Paths in its extreme guise to consider all available paths, and then there is the chance you could push your RAM and CPU into unknown territory, depending on the platform, code and control plane you've got. The limiting factor is the FIB. The FIB is what is implemented with hardware acceleration on high-end routers in order to achieve large packet-per-second (PPS) numbers. It relies on storage hardware which is both faster and more expensive than DRAM. Consequently it has much less capacity to store information than DRAM. Currently shipping equipment intended for BGP backbone use can manage 1M to 2M routes in the hardware-accelerated FIB regardless of the amount of DRAM on the machine. There are line cards out there today that are able to hold 10 million routes in FIB. Mark.
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. so 1GE port costs the ~same as 1TE port, not more, not less. If there was reduction in port prices over time, then revenue would have to go down or ports sold up. Of course all this makes perfect sense, the sand order doesn't affect the sand price, all the cost is in people thinking how sand should be ordered and then designing machines which put the sand together. -- ++ytti
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, with proprietary IA. Which is called 'Trio'. Single Trio can have hundreds of PPEs, packet processing engines, these are all identical. Packets are sprayed to PPEs, PPEs do not run constant time, so reordering occurs always. Juniper is a pioneer in FIB in DRAM, and has patente gated it to a degree. So it takes a very very long time to get an answer from memory. To amortise this, PPEs have a lot of threads, and while waiting for memory, another packet is worked on. But there is no pre-emption, there is no kind of moving register/memory around or cache-misses here as a function of FIB size. PPE does all the work it has, then it requests an answer from memory, then goes to sleep, then comes back when the answer arrives and does all the work it has, never pre-empted. But there is a lot more complexity here, memory used to be in the original Trio RLDRAM which was a fairly simple setup. Once they changed to HMC, they added a cache in front of memory, a proprietary chip called CAE. IFLs were dynamically allocated one of multiple CAEs they'd use to access memory. Single CAE wouldn't have 'wire rate' performance. So if you had pathological setup, like 2 IFL, and you'd get unlucky, you'd get both IFLs in some boots assigned to same CAE, instead of spread to two CAEs, you would on some boots see lower PPS performance than other boots, because you were hot-banking the CAE. This is only type of cache problem I can recall related to Juniper. But these devices are entirely proprietary and things move relatively fast and complexity increases all the time. > router. This makes each lookup much slower than a TCAM can achieve. > However, that doesn't matter much: the lookup delays are much shorter > than the transmission delays so it's not noticeable to the user. To In DRAM lookups, like what Juniper does, most of the time you're waiting for the memory. With DRAM, FIB size is trivial engineering problem, memory bandwidth and latency is the hard problem. Juniper does not do TC AMs on it's service provider class devices. -- ++ytti
