[arin-ppml] Policy Proposal: Predicable IPv4 Run Out by Prefix Size
ipgoddess.arin at gmail.com
Wed Jun 10 20:07:00 EDT 2009
I agree with Pete. The operational result will not be in line with
the intent of the proposal.
On Jun 10, 2009, at 1:46 PM, Pete Templin <petelists at templin.org> 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.
> 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.
> 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.
> 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:
> Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML