[arin-ppml] Final draft of 2010-13 for Atlanta (Rev 1.55)

[Owen DeLong]

On Sep 29, 2010, at 3:50 PM, Hannigan, Martin wrote:

> 
> 
> 
> On 9/29/10 10:32 AM, "Chris Grundemann" <cgrundemann at gmail.com> wrote:
> 
>> I think the fact that ARIN Staff is concerned that this policy may
>> favor organizations who are granted reservations too much and Marty
>> believes that it does not go far enough to provide relief to those
>> same organizations illustrates that we have actually found a pretty
>> decent compromise.
> 
> I don't think we are too far apart with respect to the concepts, it's the
> mechanics and implementation that I have an issue with. In it's current form
> I doubt that it is even implementable. Regardless,  the reservation
> mechanisms are hugely unfair to large and small networks alike.
> 
The alternative was to make it hugely unfair to small or large networks
in favor of the other. I would think that most people would call that
balance.

> By reducing the allocation sizes only the larger reserved allocations are
> significantly impacted. That impact is both planning and expense. The way
> that the proposal reads to me is that if you make a reservation under a
> class, you are assigned at min and could be max. If you are assigned the min
> and the allocations are reduced based on inventory, you're good to go. If
> you're reduced at the max, you're cut X% to insure that all reservations
> over the lifecycle of the system are met. And everywhere in between.
> 
That's simply not true. In order for the larger reserved allocations to be impacted
more than the smaller ones, the smaller ones already have to be down to a /28.
I don't think it makes sense to try and issue addresses from ARIN in any smaller
chunks.

Let's look at some semi-realistic examples.

A	An extra large organization qualifies for a reservation of a /18 per quarter
B	A large organization qualifies for a reservation of a /20 per quarter
C	A medium organization comes out to a /22
D	A small organization works out to a /24
and
E	an X-small organization works out to a /28

Multiplying each by 8 quarters (24 months)
A	is a /15
B	is a /17
C	is a /19
D	is a /21
and
E	is a /25

Let's assume that the combined reservations in the other categories add up
such that this category is limited to a /16 total space available.
(This isn't a realistic limit under the proposed policy, but, a realistic limit
would require me to generate a much larger set of requestors to over-
subscribe the space.)

Obviously we can't fulfill all of the reservations from a /16, so, we
take one bit away from each reservation...

A	is now a /16
B	is now a /18
C	is now a /20
D	is now a /22
and
E	is now a /26

This still oversubscribes the space, so, we hack off one more bit...

A	is now a /17
B	is now a /19
C	is now a /21
D	is now a /23
and
E	is now a /27

Everyone gets 1/4 of what they applied for and they all go away similarly
unhappy.

Now, let's say that instead of a /16, we had only a /18 left for this category.
Again, even more unrealistic to the policy, but, illustrative, nonetheless...

A	would get reduced to a /19
B	would get reduced to a /21
C	would get reduced to a /23
D	would get reduced to a /25
and
E	would get reduced to a /28

Everyone gets 1/16th of what they qualified for, except E who gets 1/8 of what
he qualified for. Is this favoring E over all the others? Well, arguably, yes, but,
would the others gain anything at all if we gave E a /29 instead of the /28?
Actually... No... There wouldn't be enough there to give meaningful additional
space to any of the larger requestors anyway. You'd need at least 8 E-sized
organizations reduced to zero in order to even give D another /25.

> //Examples
> 
> Assumptions: Normal member fees apply except when reservations reduced and
> forced to the market aside from other requirements not addressed through
> this proposal:
> 
> Cost $1,000  /32  
> Need: /32
> Assignments=Assn1/2
> 
>             Assn1 Assn2 Addr Deficit Loss
> Funded         10 100   $0
> Reduce 10%     10  90   $10,000
> Reduce 20%     10  80   $20,000
> Reduce 30%     10  70   $30,000
> Reduce 40%     10  60   $40,000
> 
I'm not sure I understand your table here, so, I won't comment.

> 
> If we didn't have the complexity issue, I'd support the proposal if we
> implemented quarterly reductions which would be more fair. The quarterly
> assignment would be based on demonstrated need:
> 
I would not be opposed to removing one quarter at a time rather than one
bit, but, I think numerically you arrive at roughly the same result.

> 
> Assumptions: Every address acquired through a transition proposal is a cost
> savings to the network in a fair and equitable manner.
> 
> Cost $1,000  /32  
> Need1: 10      Need2:  100
> 
>             QTRS   Need1       Need2
>             12     120         1200
>   Reduced 4 8      80          800
>   Reduced 4 4      40          400
> 
> Max Total Savings: $120,000  $1,200,000 All quarters
> Min Total Savings: $40,000   $400,000 All quarters
> 
> You might argue that the numbers are way disparate. Since the assignments
> are need evaluated, the savings delta are not overly relevant. Unless we opt
> to be communists[1].
> 
> If we are using a general ratio of one V6 /32 = v6 /64 with the quarterly
> model we push out far more v6 that we would with the reductions as well.
> Theoretical priming of the v6 pump: more is better even if shorter..
> 
I suspect you mean one V4 /32 = one V6 /64, but, I hesitate to comment
on speculative interpretations of your intent.

I do think your estimate of $1,000 per /32 is speculative at best.

> 
>> An organization may request one reservation under each provision  listed in
>> section 4.10.4. Once a reservation has been satisfied, another may be
>> requested.
> 
> I'm not even accounting for the reservations in multiple classes.
> 
> Additional thoughts on leadership by such a proposal:
> 
> A. The minimum alloc is too low

Raising the minimum allocation reduces the fairness to larger organizations
while simultaneously locking out a progressively larger number of smaller
organizations. As such, I felt it was best to bring it back to smaller numbers.

> B. We need to pick transition technologies, and not pick all of them

In general any effort at having ARIN pick technologies has been rebuffed by
the community. I'm not sure why you think this policy could somehow be an
exception.

> C. Make IPv4 unattractive

It already is and the costs of IPv4 depletion will make it more unattractive.

The problem isn't that IPv4 is attractive. The problem is that IPv6 isn't
attractive enough to get most people over the hump. I believe that
is a self-resolving problem, but, the problem is that many organizations
are not prepared for the transition and will, as a result, suffer a greater
level of pain than they would if they had prepared earlier.

> D. Support continued growth as much as possible during transition

This proposal seeks to do just that. However, the end reality is that there
are only 16.7 million addresses in the last /8. The only way to maximize
growth during transition is to leverage those addresses to as many
IPv6 hosts supported as possible. Realistically, that's why there is
such strong language protecting 4.10.4(c) (the remaining remnant of
the original 2010-13) in the policy. It provides the maximum leverage
of users served vs. addresses issued of any of the use cases in the
policy.

> 
> 1. COMMUNISM: You have two v4 /32 addresses. The state takes both and gives
> you the dots.
> 
It's not communism to believe that you should not give all of the
remaining space to the first person in line. I don't think anyone would
call Ticketron/Bass/etc. communists, but, even they do not allow
someone to walk up and purchase all of the tickets for a concert
that is expected to sell rapidly. Being first in line should not put
you at an overwhelming advantage over those behind you.

Owen


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