[ppml] Suggestion for ARIN to deligate smaller IP blocks

[John Paul Morrison]

It costs money to get an AS number, this may be a dis-incentive.

BGP requires some thought and complexity to setup, while there are 
multiple "plug and play" load balancing/NAT hack appliances out there.

BGP may not be a supported product offering on your basic service, so 
you may have to upgrade your service plan and pay setup/engineering 
charges to get BGP.

A PI /24 may be unroutable - you run the risk of being filtered. This 
used to be a big concern a few years ago. (The fact that it doesn't seem 
to be any more seems to point to the fact that the initial routing table 
size panic is over).

These are all dis-incentives to running out and getting an ASN and PI 
/24 unless you need it.

If you can fudge justification of a PA /24,. you can do it for a PI /24, 
so I don't see the difference. If you can fudge it, that seems like an 
enforcement/administrative issue, not a policy issue.

A first hurdle to getting a PI/24  allocation might be to show you are 
running with a PA /24

Taking a look at the big picture - if an organization can legitimately 
justify its requirements and knows enough about what it is doing to want 
an ASN and a PI /24 initial allocation, I don't think ARIN should be 
getting in the way.   Current policy can scarcely be justified any more, 
and that just leaves it looking like the anti-trust/competition limiting 
policy that it inadvertently is.

We should not rely on knee-jerk reactions and circular reasoning to 
shape policy - e.g. the usual address space depletion and routing table 
explosion arguments, where trying to conserve the status quo for as long 
as possible simply delays the adoption or development of newer 
technology (IPv6 and a solution (other than Moore's Law) to routing.

I think people would be very hard pressed to prove that this policy 
would "break the Internet" which would seem to be the only arguments 
against it.
Absolute worst case is you may see an earlier transition to IPv6 (many 
would say this is a plus!) and some routing black holes for the 
newcomers who can't route their new PI /24s.




Paul_Vixie at isc.org wrote:
>> 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 you're multihomed, your PI /24 takes up the same global table routing
>> slot your PA /24 would (less space if you had multiple PA /24s from your
>> various providers which you'd give up to get PI).
>>     
>
> for a PA /24 there's presumably a covering route which makes your addresses
> "reachable from the DFZ" even from places who don't hear or filter your /24.
> so, there's a bit of a qualitative difference in the case where a /24 isn't
> multihomed.  i agree that if it's multihomed, PI uses less DFZ DVRP than PA.
>
>   
>> If you're not multihomed, and not big enough to qualify for PI space under
>> current guidelines, sorry, you get to keep using PA.
>>     
>
> 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.  (to me
> this isn't a bad idea since the worst DFZ bloat is from TE not multihoming.)
>
>   
>> 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.
> _______________________________________________
> This message sent to you through the ARIN Public Policy Mailing List
> (PPML at arin.net).
> Manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070610/97fc3753/attachment.htm>