[ppml] Suggestion for ARIN to deligate smaller IP blocks
stephen at sprunk.org
Fri Jun 8 18:10:42 EDT 2007
Thus spake <Paul_Vixie at isc.org>
>> As I've said a couple times recently, I'm not opposed to / am
>> in favor of issuing PI /24s to any multihomed network.
> so, PI /24 for multihomers, but not for TE routes or lockin-
> avoidance? or, in light of how easy it would be for a TE route
> spewer or a lockin-avoider to just multihome in order to get a
> /24, do you really just mean "PI /24 for anybody who asks" ?
If someone is willing to pay for pipes to diverse providers and a
BGP-capable router and has enough clue to get BGP working, there is a
sizeable* faction that believes they "deserve" a routing slot. Given the
number of providers that consume hundreds of routing slots due to
TE/incompetence without adding any value to the majority of the 'net, I am
not unsympathetic to this view. Why is it that AT&T, Cox, Comcast, et al
are allowed to bloat the tables but smaller companies are not?
> anybody who wants to multihome can do that pretty easily, and if
> that's all it takes to qualify for a PI /24, then we're more or less
> throwing open the doors and inviting anybody who really wants
> a PI /24 to ask for one.
I don't think anyone is saying that you don't need to justify use of a /24.
Today you have to justify a /22, and that's not much harder than a /24.
It's well known that people fib when making requests, and most of the people
getting /22s today could probably only justify a /24 anyways -- if that.
The only legitimate complaint I've heard here is that it's easier to lie
your way to a /24 than to a /22, but wouldn't we be better served by
mandating that ARIN pursue fraud more diligently? The Board said as much in
their recent announcement, given the not-so-distant-anymore exhaustion of v4
Reclamation, if passed, may also help by enforcing standards on existing
blocks. My original intent was ARIN would go after the biggest blocks first
(to recover address space), but perhaps they need to go after the smallest
ones as well (to recover routing slots).
> (to me this isn't a bad idea since the worst DFZ bloat is from TE
> not multihoming.)
Is it TE? "Do not attribute to malice that which can be adequately
explained by stupidity."
The top deaggregators have identical paths for all of their bloated routes.
If they are doing TE to peers/transits, they should be marking those routes
no-export or with some other community that allows them to be filtered
beyond the range that they add value. The worst offenders (that we can see)
are not, therefore I choose to believe the reason we see 210k routes instead
of 140k routes is incompetence, not smart people doing TE.
However, given that those worst offenders, with a few notable exceptions,
are also the same people that are whining about routing table bloat, one
could also support a conclusion of malice, i.e. it's okay for _them_ to
bloat the tables since it gives them a reason to block policies that allow
their customers to escape provider lock-in.
>> Otherwise the routing tables really would explode.
> by any reasonable definition of that word, the DFZ at 220KP
> has exploded. so when we talk about explosion let's qualify it:
> "explode again (>1MP)." and after than we'll say "explode yet
> again (>5MP)." the community's record for preventing these
> explosions isn't good; for coping with them, slightly better.
Mr. Schiller has presented the best case I've heard for route bloat causing
problems, but even he admits that most of the routes he's carrying are from
2547 VPNs, internal routes, etc. and not from the public v4/v6 DFZ. I'm
certain** that he's the prime customer for vendors building/selling routers
that can handle 1M+ routes. With all due respect, though, should his
employer's choice to burn 80% of their routing capacity on non-public
prefixes mean that the entire rest of the Internet shouldn't be allowed to
use _their_ spare capacity to make the public Internet work better for
* I don't know if this faction is the majority or not. They're certainly
not as vocal as the crybabies.
** I have no inside knowledge, just common sense.
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
More information about the ARIN-PPML