"Tactical" /24 announcements

Mon Aug 9 16:13:10 UTC 2021

Yes, it is bad practice.  Yes, it's polluting the route table.
If the # of /24s involved is not ridiculously large (say, <64?) them I would go ahead, as long as IRR and/or RPKI are also updated.
Obviously if everyone did it (i.e. advertising /24s exclusively) then our FIBs would collectively balloon to a grotesquely un-manageable size, at least on platforms that can't auto-aggregate that back down.  Thankfully, everyone isn't doing it.
I, too, would vastly prefer no-one did this, but I have two customers that demand it from time to time... and we've even done it for our own allocation sometimes, and there's no robust, never mind bullet-proof, technical argument why I can't do that for them (or for ourselves).  OTOH robust arguments exist for why it's a good thing to do - sometimes, and temporarily.
¯\_(ツ)_/¯
-Adam

Adam Thompson
Consultant, Infrastructure Services
[1593169877849]
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athompson at merlin.mb.ca<mailto:athompson at merlin.mb.ca>
www.merlin.mb.ca<http://www.merlin.mb.ca/>
________________________________
From: NANOG <nanog-bounces+athompson=merlin.mb.ca at nanog.org> on behalf of Billy Croan <BCroan at unrealservers.net>
Sent: August 9, 2021 10:47
To: nanog list <nanog at nanog.org>
Subject: "Tactical" /24 announcements

How does the community feel about using /24 originations in BGP as a
tactical advantage against potential bgp hijackers?

All of our allocations are larger and those prefixes we announce for
clients as well usually are.  But we had a request recently to
originate everything as distinct /24 prefixes, to reduce the effect of
a potential bgp hijack.  It seemed a little bit like a tragedy of the
commons situation.

Is this seen as route table pollution, or a necessary evil in today's world?
How many routers out there today would be affected if everyone did this?
Are there any big networks that drop or penalize announcements like this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210809/b85d7da7/attachment.html>