[arin-ppml] IPv4 Fragment Managemnt policy proposal

[Owen DeLong]

I don't understand what you mean by "% space available related to % request fulfillment".

The only thing I could think of was essentially what we have today -- If 100% of what you request is available, you get it.
If less than that is available, you get what is left.  Either of these regardless of the number of prefixes involved in fulfilling
your request.

Obviously you're suggesting something that could be a policy proposal, so, can you clarify what I misunderstood?

Since most laws against anti-competitive practices are geared towards preventing small numbers of massive organizations from blocking entry or competition by larger numbers of smaller entities, I believe that allowing a small number (or likely even 1 at some point) to garner all of the remaining space to the exclusion of a much larger number of smaller entities is unfair.  As it already stands, 24 extra large organizations hold more than 80% of the address space issued in 2006 and 2007 (the only statistics I could find on the ARIN web site).  I think the fair thing to do once ARIN starts receiving requests it can't satisfy with a single block is to start limiting the number of crumbs each organization may pick up at one time. Yes, this means that smaller organizations will continue to get the /20s and smaller that they ask for long after we can no longer hand out /9s.  However, that's largely the result of the fact that there are more than 2 million /20s in each /9 more than anything particularly unfair.

As time goes on, the size of the largest crumbs will get progressively smaller. In reality, under this policy, the large organizations will take the largest crumbs early on leaving only smaller crumbs behind.

Should they be allowed to get an ever increasing percentage of the remaining crumbs at the expense of others?

It's clearly expressed in NRPM 8.3 that this is not the will of the community.

One of the few points of 2010-1 that received no opposition was it's provision to limit each entity to exactly 1 crumb.  Here I'm offering 4 crumbs as an alternative strategy.

Otherwise, as it stands now, it's basically a lottery to see which x-large ISP picks up thousands of prefixes in one request to finish out the ARIN free pool.

Remember, there was some community support for proposals that said if your request can't be completely filled, you wait, too bad, so sad. I spoke out against those proposals because I felt they were unfair to large organizations. I believe current policy is unfair to smaller organizations. This policy is my attempt to strike a balance.


Owen

On Apr 28, 2010, at 6:29 PM, Hannigan, Martin wrote:

> 
> 
> No need to assert a position on this, but I will say that the distribution method is severely lacking. Under this regime some will undoubtedly fulfill their requests entirely and others will not. 
> 
> The language that would be more suitable is something akin to pct of space available related to request fulfillment pct IMHO. Specifying hard limits may be anti-competitive, especially with the apparently hostile reason that you state for the creation of this policy “I believe there is a need for policy to prevent this kind of gathering of the last breadcrumbs by a small number of large entities.”
> 
> Best,
> 
> -M<
> 
> 
> -- 
> Martin Hannigan                        http://www.akamai.com
> Akamai Technologies, Inc.              marty at akamai.com
> Cambridge, MA USA                      cell: +16178216079
>                                        ofc: +16174442535
> 
> 
> From: Owen DeLong <owen at delong.com>
> Date: Wed, 28 Apr 2010 14:38:13 -0700
> To: <policy at arin.net>, arin ppml <ppml at arin.net>
> Subject: [arin-ppml] IPv4 Fragment Managemnt policy proposal
> 
> At ARIN XXV, one of the discussions pointed out that under current
> ARIN policy, after IANA runout, a justified request for a /10 could
> (and would) be satisfied, if necessary, by issuing 1024 disjoint /20s.
> 
> I believe there is a need for policy to prevent this kind of
> gathering of the last breadcrumbs by a small number of large
> entities. As such, I offer the following proposal for the discussion
> of the community.
> 
> Owen
> 
> TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0
> 
> 1.      Policy Proposal Name: IPv4 Fragment Management
> 2.      Proposal Originator
>         a.      name: Owen DeLong
>         b.      email: owen at delong.com
>         c.      telephone: 408-890-7992
>         d.      organization: Hurricane Electric
> 3.      Proposal Version: 0.8
> 4.      Date: 2010-04-28
> 5.      Proposal type: New
>         new, modify, or delete.
> 6.      Policy term: Permanent
>         temporary, permanent, or renewable.
> 7.      Policy statement:
> 
> Add the following to the NRPM as new sections 4.2.1.7 et. seq.
> 
> Each time ARIN approves an IPv4 request which it cannot
> satisfy from 4 or fewer bit-aligned blocks of free address
> space, ARIN shall notify the requestor that there is
> insufficient free address space to meet their request and
> shall offer the requestor their choice of the following
> alternatives:
> 
> a. They can have the largest 4 available bit-aligned
> blocks of free addresses.
> 
> b. This section reserved -- (in case we implement the
> waiting list for unmet requests policy)
> 
> c. They can seek resources through the directed
> transfer policy in section 8.3 of the NRPM.
> 
> 8.      Rationale:
> 
> When the ARIN free pool begins to diminish, the free space
> will become fragmented into smaller and smaller remaining
> contiguous spaces. This policy attempts to ensure that a
> large number of remaining disjoint small blocks are not
> consumed by a single large request.
> 
> While this policy could be regarded as unfair to larger
> entities, it is consistent with the safeguards adopted in
> section 8.3 which require an exact match or full fill
> style of resource transfer.  As such, I believe the policy
> is fair and in line with the consensus will of the community.
> 
> 9.      Timetable for implementation: Immediate, although it has no
> actual effect until some time after IANA runout.
> 
> END OF TEMPLATE
> 
> 
> _______________________________________________
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100428/40937914/attachment.htm>