[arin-ppml] Proposal 98: Last Minute Assistance for Small ISPs
Ted Mittelstaedt
tedm at ipinc.net
Fri Oct 30 14:50:21 EDT 2009
George, Wes E [NTK] wrote:
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Chris Grundemann
> Sent: Tuesday, October 27, 2009 1:37 PM
> Subject: Re: [arin-ppml] Proposal 98: Last Minute Assistance for Small ISPs
>
> On Tue, Oct 27, 2009 at 09:29, Bill Darte <BillD at cait.wustl.edu> wrote:
>> Reservations expressed by myself at the time of acceptance was that the
>> proposal seemed overly complex with thresholds and tiggers that rely
>> upon 1/ ARIN's ability to accurately assess the remaining free pool in
>> small, single digit percentages; 2/ the ability of ARIN to react to
>> changes in status of the free pool based upon these thresholds and
>> announce the changes to the public; and 3/ most importantly, that all
>> these thresholds and all the remaining FP might be eliminated with a
>> single justified large allocation rendering the policy's incremental
>> process mute.
>
> I agree. With regard to this PP and other PP and DP which deal with
> IPv4-free-pool-run-out / soft-landing strategies: I am beginning to
> wonder if it isn't better to do away with all of the staggered
> triggers and accompanying complexity for a much simpler approach.
>
> In this case specifically, if the community believes that lowering the
> minimum allocation may help as we approach and pass IPv4 free-pool
> exhaustion, why not just lower it now? Forget the triggers all
> together.
>
Hi George,
That is actually my preference, the reason I added the triggers is
to make the proposal more palatable to those who have concerns that
lowering the minimum too early might increase the DFZ unnecessairly.
The minimums in that section exist today explicitly to prevent such
fragmentation. As an ISP admin I share those concerns as well.
However, my feeling is also that the ISP business is maturing to where
other factors are limiting the fragmentation of routes in the DFZ.
Forcing small ISP's to go to LIR's made really a huge amount of
sense in 1995-2000 when anybody could get an extra couple phone lines,
put some 28.8k modems on a router, and a 56K circuit to an ISP and
hang up their ISP shingle.
With the advent of 56k it raised the bar somewhat, but products like
the Ascend MAX allowed even small operators to supply 56k dialup over
BRI's - but we saw the beginnings of the weeding-out process where
people who wern't serious about making a business out of Internet access
left the market.
Then when DSL came in and dialup started declining, and moving to
the outsourcers, it did a lot more weeding, and made conditions such
that smaller ISP's couldn't get started anyway. ISP's were either
forced to get big or go away.
With the advent of cheap wireless gear it's kind of leaving an opening
for the small access providers to get started again - but I think it's
pretty severely restricted to rural areas, and I don't know that we
would have that many applicants from startup small ISPs.
I think the primary producer of applicants for /24's under part
4.2.2.1.1 are going to be "niche" small ISPs (particularly WISPs)
who for years have operated with upstream LIR assignments, and have a
single upstream feed, (and won't be getting more) and are afraid
that as the squeeze is put on IPv4 in the future, that they could
get knocked offline. I don't think it's going to
be garage operators who have never been ISP's before, wanting to
get into the "ISP land rush". It's not like it was 10 years ago,
in this business. Thus, I don't feel that we are going to see that
explosive growth of DFZ BGP advertisements from orgs getting /24's
under section 4.2.2.1.1 If anything, the growth is going to come
from the inability of the RIR's to assign adjacent IPv4 blocks
to new requesters.
It is going to be a challenge for a lot of those smaller ISPs
anyway even if they get an IPv4 block they can advertise, because
now they will have to advertise it to their upstream, whereas
before their upstream took care of all of that for them.
Ted
More information about the ARIN-PPML
mailing list