[arin-ppml] Draft Policy ARIN-2014-20: Transfer Policy Slow Start and Simplified Needs Verification

Tue Sep 16 11:56:34 EDT 2014

David,

I do not believe current ARIN policy / process will approve a future
looking two year need that is greater than the past 1 year utilization.  I
am fairly certain this is not the case for ISPs, I have less experience as
an end-user that regularly go back for IP space.

At either rate I do not think ARIN should be looking at future looking
projections or making judgments of future business plans.

---

ARIN Staff,
Can you confirm can an ISP request a projected two year supply of addresses
that is greater than the double the past year utilization?

What about an end-user?

Under 4.3.3 how is utilization rate used as a factor is sizing future
assignments?

 4.3.3. Utilization rate

Utilization rate of address space is a key factor in justifying a new
assignment of IP address space. Requesters must show exactly how previous
address assignments have been utilized and must provide appropriate details
to verify their one-year growth projection. The basic criteria that must be
met are:

Can you discuss how you determine if a future looking projection is
justified.

---

WRT the number of transfers...

There are two things going on here.

In the case where the organization already holds a /16 or more, they can
demonstrate 80% utilization and get up to another /16.

In the case where the organization is holding less space then they want to
grow into over the next 2 years, they have two choices.

Choice 1: stable growth.
They can show 80% utilization, and then double.
They can show 80% utilization again, and then again double.

Say they are holding a /18 at 82% utilization.
They can double.  Transfer in a /18, and get total utilization of both /18s
to 80% or more.
They can then double again.  Transfer in a /17, and get total utilization
of the /17 and two /18s to 80% or more.
They can then double again.  They can transfer in a /16 (or /17 if they
don't need all that space)

Choice 2: Rapid Growth:

They can look at their utilization over the most recent 3-12 months, and
based on that use rate, can get a two year supply.

However, if there run rate since they got their last IP block has been
slow, and they now have rapid growth that is not supported by their past
history, then they are "slow started".

They can always double, and can always choose to transfer in less.  They
can transfer in a 90 day supply (or more) which is less than double what
they are currently holding.

Based on that run rate of using that space, they can transfer in a two year
supply.  Of course if the growth rate keeps increasing, then it will end up
being less than a two year supply.  This is the sort of math used for slow
start.

---

This is further complicated for new organizations who get a "small" "slow
start block" up to a /24 for EU and up to a /21 for ISP.  If this starter
block is less than a 3 month supply then extra transfers (at some point)
are required.

Say an EU gets a /24.  This turns our to be a 1 month supply.  At the end
of the month they could claim the /24 as their 3 month run rate and qualify
for a /21.  However, this does not actually reflect their two year need.
They may instead choose to transfer in a /23 (instead of the /21) to get
them through their first 3 months at the conclusion of which they can
demonstrate a  3 month run rate of three /24s which results in an approval
for two year supply of
twenty-four /24s or (/20, /21).

---

In the "real world" example, the EU choose to number out of ISP space.  The
org cannot get space to renumber into in addition to covering their growth
 (this is current ARIN policy) so returning ISP space will eat into the
space they get for growth until the renumbering is complete.

They also have rapid growth.  Per your scenario, they have 29 /24 and what
to grow into a /16 over the next two years.  If they used 29 /24s in 90
days, then the two year need is 29*8=232 /24s, 24 /24s short of a /16.  We
specifically excluded run rates shorter than 3 months because we are
concerned one could easily skew things by creating pent up demand, and
releasing it all in a small window.

In this case the organization wants to transfer in the address space as
soon as possible.  They could have instead chosen to double (less than what
they think they will need in two years) and transfer in 29 /24s. And then
when those are 80% utilized in say 1.8 years, transfer in another /19 to
round them out to the total holdings of a /16.

So in this example extra transfers are needed to return ISP space, and to
establish a past utilization rate that is high enough to justify a /16.

If instead the EU used a /19 of ISP space to 80% or greater use, in under
90 days, they would qualify for a /16 transfer.

___Jason

On Mon, Sep 15, 2014 at 7:53 PM, David Huberman <
David.Huberman at microsoft.com> wrote:

> Thank you for the detailed reply, Jason, and for expanding on my
> simplistic scenarios.
>
> Maybe I'm tired, but I don't understand a fundamental point.  Under
> 2014-20, to transfer a /16 into their account (where a /16 is their
> believed 24-month need), they need to do three transfers over 180 days?
> Today they can do that in one transfer simply by showing their math to ARIN
> staff, demonstrating why they think a /16 is their need.    If what I wrote
> is accurate, why is 2014-20 good in this context?
>
> /david
>
> Quoting text for context:
>
> > Choosing a 90 day look back window, they can show they used 29 /24s and
> qualify for 4*29= 116 /24s
> > They can immediately transfer in  a /18, /19, /20 and a /22.
>
> > They could choose to transfer in a /18 and a /19.
> > They could renumber their ISP space into the /19, and use the /18 and
> the remainder of the three /24s out of the /19 for growth over the next 90
> days
>
> > on 12/13/2014 they could again re-demonstrate they are over 80%.
> > They then qualify under 8.3.2.3.1 to double again
> > They also qualify under 8.3.2.3.2.
>
> > Choosing a 90 day look back window, they can show they used a /18 and
> three /24s  and qualify for four times that amount, a /16, /20, and a /21
>
> > They could choose to transfer in a /16.
>
>
>

-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140916/508285b5/attachment.htm>