Re: any dangers of filtering every /24 on full internet table to preserve FIB space ?

Tue Oct 11 21:08:25 UTC 2022

The /24 is as small as it will get before it cuts into profits for the tiny bit of administration it would take to announce /25, /26. This argument is almost as old as my kids. Is it fair or just, probably not, but that's they way the consensus seems to want it.RichardRichard GolodnerInfratection IT Services
-------- Original message --------From: William Herrin <bill at herrin.us> Date: 10/11/22  16:00  (GMT-06:00) To: Matthew Petach <mpetach at netflight.com> Cc: nanog at nanog.org Subject: Re: any dangers of filtering every /24 on full internet table to
  preserve FIB space ? On Tue, Oct 11, 2022 at 1:15 PM Matthew Petach <mpetach at netflight.com> wrote:> Wouldn't that same argument mean that every ISP that isn't honoring> my /26 announcement, but is instead following the covering /24, or /20,> or whatever sized prefix is equally in the wrong?>> What makes /24 boundaries magically "OK" to filter on,Hi Matthew,/24 is the consensus filtering level for Internet-wide routes and ithas been for decades. It became the consensus as a holdover from"class C" and remains the consensus because too many people would haveto cooperate to change it. Indeed, a little over a decade ago somefolks tried to change it to /19 and then /20 for prefixes outside "theswamp" and, well, they failed. Likewise, more than a few folksannounce /26's to their immediate transit providers and they simplydon't move very deep into the system -- nobody has any expectationthat they will.> To wrap up--I disagree with your assertion because it depends entirely> on a 'magic' /24 boundary that makes it OK to filter more specifics smaller> than it, but not OK to filter larger than that and depend instead on covering> prefixes, without actually being based on anything concrete in BGP or> published standards.Got any better reasons besides disliking the consensus?Regards,Bill Herrin-- For hire. https://bill.herrin.us/resume/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20221011/d86b7037/attachment.html>