[arin-ppml] Policy Proposal: Predicable IPv4 Run Out by Prefix Size

[David Farmer]

On 10 Jun 2009 Pete Templin wrote:

> Scott Leibrand wrote:
> > Pete Templin wrote:
> >>
> >> I'm simply not following your suggestion of the numbers, which
> >> includes looking at the spreadsheet you've provided.  I'll base my
> >> discussions on the one quarter (1/4) ratio since that's what's
> >> written into the Policy Proposal.
> >>
> >> Case study #1: ARIN has a /13 of space, also known as 524,288
> >> addresses.  Four large-enough requests happen to be at the head of
> >> the line, and based on the one-quarter ratio they're eligible for a
> >> /15 of space per request.  Each request is issued a /15, also known
> >> as 131,072 addresses.  These 524,288 addresses in four allocations
> >> would wipe out the pool, not the 24 allocations that you present
> >> above.
> > 
> > If ARIN has a /13 of space, the first large-enough request to come
> > in could get a /15 based on a 1/4 ratio.  That would take ARIN's
> > space down to /14+/15, meaning that the second large-enough request
> > could get a /16.  That leaves /14+/15+16, which means the next few
> > also get a /16.  Once the /14 gets broken up, leaving /15+16, then
> > the next few requests can only get /17, until the /15 gets broken
> > up, at which point it goes to /18, etc. etc. until you get to the
> > minimum allocation size.

Yes that is the intended sequence.  I found a different problem in my spread 
sheet, I'm reworking it, once I update it the same URL should work.

> OK, now I understand the intentions.  That said, the first paragraph
> of the proposed policy needs a complete re-write, or at least the
> first sentence: "When ARIN receives its last /8, by IANA implementing
> section 10.4.2.2, a maximum allocation and assignment size will be put
> into effect."  This needs to be completely redone to reflect the
> dynamic nature of the ideas you're batting around.  Ideas like
> "sliding scale", "dynamic allocation/assignment size", etc. come to
> mind.

I thought that was clear from the second sentence "one quarter (1/4) of the 
total unrestricted IPv4 resources available to ARIN for allocation or 
assignment AT THE TIME".   But, I'm happy to clarify it, sometimes you just 
need someone else to read it, especially someone who wasn't part of the 20 
or so emails that lead up to its creation. 

"When ARIN receives its last /8, by IANA implementing section 10.4.2.2, a 
proportionally decreasing maximum allocation and assignment size will be 
put into effect.  The maximum allocation or assignment will be the next whole 
CIDR prefix less than or equal to one quarter (1/4) of the total unrestricted 
IPv4 resources available to ARIN at the time of each allocation or 
assignment, but no longer than the applicable minimum allocation or 
assignment.  All other allocation and assignment rules, requirements, or 
procedures apply in addition."

Does that rewrite of the first paragraph better communicate the intent?

If you think that is good, I'll submit that and some other grammar fixes.

> That said, I think this policy proposal leads to a
> highly-unpredictable run-out model at a micro (i.e. per-request) level
> - there would be essentially no way to predict how much of an
> assignment/allocation a requester might get unless there was a public
> status board, reports (rumors?) on mailing lists (yesterday I got a
> /X!!!), etc.  It's predictable run-out at a macro level, but quite
> unpredictable at a micro level.

Realize most requests are for the smaller blocks, so most people won't have 
this unpredictability until the very end.  What ever our run out looks like ARIN 
will probably need some kind of real-time status of what is left.

It boils down to there will be unpredictability no matter what, this proposal, 
trades some additional unpredictability in the size block you will get for more 
predictability in the availability of a block at all.  While trying to avoid rationing 
as much as possible, and ensuring there is some minimal dispersion of the 
resources.

But I agree it creates uncertainty in the size block that is available when you 
make a request, and that troubles me, but it was clear from the discussion in 
San Antonio that people really didn't like rationing.  2009-2 which basically 
gave everyone a /20 when ARIN got down to /9 didn't go over well.  With that 
proposal there was good certainty on the size of the blocks and the 
availability of blocks, but it rationed.  Whereas this proposal doesn't ration, 
has some certainty of availability of blocks, but creates uncertainty in the size 
blocks available at any moment, other than it will be going down.

A possible middle ground could to, create set of ranges of resources 
available to ARIN with associated maximum allocation or assignment size.  A 
hybrid between 2009-2 and this proposal.  

Just throwing out an idea here;

ARIN has less than a /8, but more than /11, the max is /12
ARIN has less than a /11, but more than /15, the max is /16
ARIN has less than a /15, but more than /20, the max is /20

This third option has good certainty on the size of the blocks, expect near the 
boundaries, and the availability of blocks, however it would necessitate some 
rationing.  

Is this a better option?  I'd be willing to start over with something more like 
this.

> Pete
> 



===============================================
David Farmer                                      Email:farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota		       Phone: 612-626-0815
2218 University Ave SE		       Cell: 612-812-9952
Minneapolis, MN 55414-3029	       FAX: 612-626-1818
===============================================