[arin-ppml] Proposal 98: Last Minute Assistance for Small ISPs

Tue Oct 27 13:36:43 EDT 2009

On Tue, Oct 27, 2009 at 09:29, Bill Darte <BillD at cait.wustl.edu> wrote:
> Hello,
>
> I am the ARIN Advisory Council shepherd for policy proposal #98 Last
> Minute Assistance for Small ISPs.
>
> This policy proposal(PP) was authored by Ted Mittelstaedt and accepted
> onto the ACs docket to review and work on.  It was received too late to
> evaluate fully, fashion acceptable text to become a draft policy and be
> presented at the Dearborn meeting, just past.
>
> Essentially, the PP asks ARIN to follow a predetermined lowering of the
> minimum allocation size of blocks for ISPs as the free pool(FP) of ARIN
> addresses depletes.  The minimum allocation size of /20 would be lowered
> to /21 when ARIN has allocated 90% of its FP (which presumably is the
> last IANA /8 allocated according to NRPM 10.4). Subsequently, when the
> FP exhausts 95% the minimum will become a /22.  At 97% exhaustion, the
> minimum becomes /23 and remains so.  The purpose is to allow ISPs who
> have never been able to qualify for /20 allocations, to qualify under
> this policy for small blocks of address space.
>
> The AC accepted this PP because it is yet another end-game tool proposed
> to transition the industry and expectations during the runout of IPv4
> addresses and there seems to be sympathy with this in the community.
>
> 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.

One of the most frequent, loud and justified complaints I have heard
regarding other trigger-based policies is that they make it harder to
plan.  Add to that the added complexity for ARIN staff during what
will likely be an already complex time.  Eliminating them doesn't seem
to reduce the potential effectiveness of this policy, imo.

The fact is that we are very close, in policy-cycle terms, to the end
of unallocated IPv4 and as such I think that we may want to carefully
consider what benefit, if any, these triggers offer.  If lowering the
minimum allocation is a good idea, let's just do it now.  If lowering
the maximum allocation is a good idea, let's just do it now.  Etc.  I
think our time is better spent arguing the merits of the actual
changes rather than the details of the triggering events.

>
> However, IF space were returned in small amounts to ARIN, post runout,
> then this policy would establish a new and continuing small size for
> allocations to help emerging or other small ISPs.  It is impossible to
> predict the status of the Internet routing table at this time and
> whether upstream providers would announce such small networks.  It is
> therefore impossible to predict the usefulness of this outcome of the
> policy.

Despite the title and rational, this would not only help small ISPs;
post run-out especially it would potentially help anyone willing to
take a small allocation from any return pool which emerges (I don't
see anything in the policy which actually limits it to small ISPs). If
IPv4 continues to become more valuable, larger and larger ISPs will
have to learn to do more and more with less and less.

I also note that this PP may compliment PP 97 - Waiting List for Unmet
IPv4 Requests in that it could help offer more options to folks post
run-out if small blocks (legacy /24s perhaps) are returned; take this
/23 that we _do_ have or go find your /20 via a transfer...

> In preparation for AC discussion of this PP to determine its fate
> (abandonment or adoption as a draft policy), I ask the Internet
> community to read the PP at
> http://lists.arin.net/pipermail/arin-ppml/2009-July/014747.html and
> comment on this list.
>
> Specifically, I would request your 1/ interpretation of this policy as
> it may differ from my explanation above; 2/ assessment of the
> practicality and usefulness of this policy; and 3/ a clear statement of
> support or lack of support for this PP becoming a draft policy.  If it
> becomes a draft policy, it will be discussed at the Toronto public
> policy meeting and perhaps eventually become an implemented policy.

1) My interpretation basically matches yours, with additional comments above.
2) As written the policy is not practical, lowering the minimum
allocation may be useful however.
3) I think that the triggering events should be removed so that we can
discuss the merits of lowering the minimum allocation.  I support the
creation of a draft policy which simply lowers the size of the minimum
allocation for _non-transfer_ allocations.

> Thank you for your support of ARIN and your involvement in the policy
> development process.
>
> Bill Darte
> ARIN Advisory Council
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org