[arin-ppml] IPv4 Fragment Managemnt policy proposal

[Owen DeLong]

On Apr 29, 2010, at 6:49 AM, Joe Maimon wrote:

> 
> 
> Owen DeLong wrote:
>> 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
> 
> 
> I agree with the intent and support the policy proposal. I will also note that PP110 deals with this head on, but the two are not incompatible in either intent or effect.
> 
PP 110 does this in a way that singles out particular classes of organization at the expense of others. This policy proposal allows all organizations to get IP resources while they are available, but, limits the number of the remaining crumbs of address space that may be cornered by any one organization at a time.

> 
>> 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
> 
> 
> This could be somewhat confusing. I would support a simple 1 request == 1 NEW prefix + possible adjustments to old prefixes, which could differ from current practice.
> 
Why is it confusing?  Let's say the remaining free pool contains:

250 /22s
100 /20s
18 /19s
5 /14s
1 /12

(total prefix equivalents /11 + /13 + /14 + /15 + /16 + 2 /17 + /18 + /19 + /21)


A request comes in for a /9 and is approved.

The organization requesting the /9 would have the option of receiving {1x/12, 3x/14}.

They would not have the option of receiving {1x/12, 5x/14, 18x/19, 100x/20, 250x/22}.

IOW, the request for the /9 cannot be filled and they get the 4 largest blocks
available.

I don't think it would be fair to limit the /9 requestor to a single /12 when there is a
stack of /14s sitting right next to it.

An organization requesting a /20 that is approved would receive one of the
remaining /20s under business as usual.

I can understand the "bitmath is hard let's go shopping" concept if
the applicant was going to need to identify the largest available
sub-blocks, etc. However, this is very simple from the end user's
perspective.  All the "hard math" is handled by ARIN's systems.

The requestor says "I need a /9".

ARIN approves the request, looks in their allocation system and sees
they don't have a /9 available and cannot manufacture one from four
or fewer remaining pieces.  The system automatically offers up
the {1x /12, 3x/14} recipe. ARIN offers this to the requestor on a
basically here's what we can give you if you like basis.  The
requestor says yes or no. Simple.

Now let's see if we can find the corner cases, etc...

Given the same free pool (let's assume the /9 didn't want the pieces
and went away to try their luck on the transfer market)...

Request for a /10 -- Same results as the /9. (and off to the transfer
market he goes, also.. The free pool remains in tact).

Note: Both the /9 and the /10 could not be completely filled anyway. The
total free space is less than  a /10.

Request for a /11 -- While there is actually a /11 total space in the free pool,
this request would still receive only a partial fill. They would receive the same
four possible blocks {1x/12, 3x/14} as the previous 2 requests. A /11 is
equivalent to 8x/14. This requestor would receive address space which
is equivalent to 7x/14 or 87.5% of what he requested.

As such, I think that this policy is significantly more fair than PP 110 as
it does not exclude large organizations from getting reasonable proportions
of the remaining crumbs of address space while preventing any single
request from wiping out a significant number of crumbs.

>> 
>> 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.
> 
> 
> I question the effectiveness of any proposal that could be defeated simply by inundating ARIN with multiple smaller requests if the objective of the requester cannot be achieved via a single large request.
> 
1.	This won't work because the second request will need to demonstrate
	effective utilization of the space issued under the first request.  Processing
	time on the first request alone will place your second request significantly
	further back in the queue.

> Unless constrained by policy, larger entities would easily be able to muster the manpower required to inundate ARIN with many justified small requests, either successively or concurrently.
> 
2.	Concurrent requests would be rejected as duplicates or consolidated. (I have
	seen ARIN catch these in the past when multiple administrators at the same
	company did not realize the other was working on the request).

> As I currently understand it, the 12 or 3 month window are maximums, not minimums.
> 
You can justify a maximum of 12 (3) months worth of space in a single request, correct.
You can make a subsequent request at any time, so long as you can show efficient
utilization of your previous requests.

IOW, the large organization would have to:

1.	Submit request
2.	Get request approved (some delay here, days if ARIN is "innundated").
3.	Accept sub-fill.
4.	Make utilization of addresses and SWIP it.
5.	Prepare subsequent request (some delay here, 9 women cannot have a baby in 1 month)
6.	Goto 1.

In the time elapsed between 2 and 6, there is likely a significant number of
organizations in the queue ahead of them.

As such, I think there are already sufficient safeguards in this case.

>> 
>> While this policy could be regarded as unfair to larger
>> entities,
> 
> I think we need to ask ourselves a few questions:
> 
> Is it possible to do anything that would not be perceived as unfair to segments of the ARIN community?
> 
Of course not.

> What about inaction?
> 
Probably not the most fair thing to do, but, almost certainly the safest.

> Have some segments of the ARIN community received or are perceived to have received more than their fair share of fairness to date?
> 
That depends to a great extent on your perspective. Obviously it is your perspective that large and x-large organizations have.
I am not convinced that is true.

> Might it not be time for them to repay the balance?
> 
This assumes facts not in evidence... Namely that the answer to the previous question is yes.

> Could not it be considered that the only policy that is fair to large entities would be one that levels the field between them, by denying them resources equally, instead of potentially allowing one of them to gain a few month (or longer) advantage over the others?
> 
There is actually no way to accomplish this, and, even if there were, it would not actually be fair.

> Do we believe that IPv4 players large and small will begin an orderly transition to IPv6 when faced with real resource scarcity or do we expect or suspect chaos and crisis?
> 
Probably a little of both.

> If there is a real chance of chaos and crisis, are we doing the best we can to prepare and attempt to mitigate?
> 
I don't think ARIN's role is to mitigate the chaos and crisis of individual ISPs choices on IPv6 transition. I think ARIN's role is to manage the remaining address space in a manner which is responsible, technically sound, and in line with the intent of the community as expressed through the policy development process.

> Damned if we do, damned if we dont - is the question one of how hot will hell be?
> 
Pretty much.

> 
>> 
>> 9. Timetable for implementation: Immediate, although it has no
>> actual effect until some time after IANA runout.
> 
> Only due to detail, but not due to intent. Edits could easily change that.
> 
I do not believe such a change would be beneficial to the policy or the
community.

Owen