<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
It costs money to get an AS number, this may be a dis-incentive.<br>
<br>
BGP requires some thought and complexity to setup, while there are
multiple "plug and play" load balancing/NAT hack appliances out there.<br>
<br>
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.<br>
<br>
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).<br>
<br>
These are all dis-incentives to running out and getting an ASN and PI
/24 unless you need it. <br>
<br>
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.<br>
<br>
A first hurdle to getting a PI/24 allocation might be to show you are
running with a PA /24 <br>
<br>
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.<br>
<br>
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. <br>
<br>
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. <br>
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.<br>
<br>
<br>
<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Paul_Vixie@isc.org">Paul_Vixie@isc.org</a> wrote:
<blockquote cite="mid:58495.1181333844@sa.vix.com" type="cite">
<blockquote type="cite">
<pre wrap="">As I've said a couple times recently, I'm not opposed to / am in favor of
issuing PI /24s to any multihomed network.
</pre>
</blockquote>
<pre wrap=""><!---->
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" ?
</pre>
<blockquote type="cite">
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<pre wrap="">If you're not multihomed, and not big enough to qualify for PI space under
current guidelines, sorry, you get to keep using PA.
</pre>
</blockquote>
<pre wrap=""><!---->
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.)
</pre>
<blockquote type="cite">
<pre wrap="">Otherwise the routing tables really would explode.
</pre>
</blockquote>
<pre wrap=""><!---->
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
(<a class="moz-txt-link-abbreviated" href="mailto:PPML@arin.net">PPML@arin.net</a>).
Manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="http://lists.arin.net/mailman/listinfo/ppml">http://lists.arin.net/mailman/listinfo/ppml</a>
</pre>
</blockquote>
<br>
</body>
</html>