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

Wed Oct 12 15:39:48 UTC 2022

Andrey,

On Oct 12, 2022, at 7:54 AM, Andrey Kostin <ankost at podolsk.ru> wrote:
>> My point is that it's not a feature of BGP, it's a purely human convention, arrived at through the intersection of pain and laziness. There's nothing inherently "right" or "wrong" about where the line was drawn, so for networks to decide that /24 is causing too much pain, and moving the line to /23 is no more "right" or "wong" than drawing the line at /24.  A network that *counts* on its non-connected sites being reachable because they're over a mythical /24 limit is no more right than a customer upset that their /25 announcements aren't being listened to.
> 
> IMO this line wasn't arbitrary, it was (and it still is) a smallest possible network size allocated by RIRs.

There was a period in the mid- to late-90s where some of RIRs allocated longer than /24s, i.e., to match the amount of address space justified by the requester, even if that meant (say) a /29. This didn’t last very long as one of the (at the time) 800 lb gorillas (Sprint) decided to start filtering at /19 (which IIRC was the default prefix length RIPE-NCC chose to allocate to LIRs) to keep their routers from falling over.

In this context, any prefix length, including /24, is arbitrary. Today, filtering on /24 will probably drop some number of perfectly valid and perhaps better routes to specific destinations (I’m too lazy to look to see). That’s fine as long as there is some covering route that allows the traffic to get from here to there. It feels to me like the responsibility should be on the announcer to ensure there is some covering less-specific for stuff that has "a good chance" of being filtered.

> So it's just a common sense to receive everything down to /24 to have the complete data about all Internet participants.

Given infinite resources, sure. However, I believe the issue here, as it was in the mid- to late-90s, is hardware limitations. Having a partial view with (potentially) non-optimal less specifics is better than having your routers fall over.

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20221012/863d6ea9/attachment.sig>