[arin-ppml] Initial ISP Allocation Policy

[Brian Jones]

See inline comments.
--
Brian


On Thu, Jul 18, 2013 at 4:36 AM, David Huberman <
David.Huberman at microsoft.com> wrote:

> Hello everyone,
>
> I would like to thank everyone for a very good discussion in this thread.
> First I'll give a very brief summary of the discussion so far, and then I
> have a solution to float to the list for feedback.
>
> Myself, Dan, Bill, and Steven have posted in favor of the high level
> concept that the differentiation in ARIN policy between enterprise networks
> and provider networks is no longer productive or relevant.  Owen may agree
> in principle, but cautions us to be very careful with how we proceed.  He
> is concerned that an effective "one size fits all" solution may be very
> difficult to design. George offers us an alternative nomenclature to
> consider (NSP v. ISP).
>
> I would like to now shift the discussion to how we approach potentially
> collapsing the two categories into one so that future interactions with
> ARIN are conducted under policy language which is relevant in 2014 and
> beyond.
>
> I agree with Dan that a wholesale paradigm shift in ARIN policy can only
> be accomplished with multiple proposals. There would be quite a few
> sections to change (with each change requiring careful consideration by the
> community).  Moreover, I think we must be sensitive to ARIN's need to react
> to the possible impacts to both the financial and workflow modeling that
> would result from any changes we propose.
>
> At the same time, incremental change in NRPM is actually really hard. If
> this were 5 years ago, I would probably work very hard to help effect
> incremental change.  But I think ARIN and the community have together
> failed to react to changes in the market over the last 15 years, and it is
> time to consider very big change. Let's get NRPM into a sane state for 2014
> and beyond.
>
> In an effort to roll up sleeves and be productive, please indulge me while
> I lay out one potential vision for what a sane NRPM might look like.  I
> warn you, good reader, that some of what I propose is very radical.
>
> - A section on obtaining initial IPv4 addresses from ARIN.  No distinction
> between end-users and ISPs.  No distinction between single-homed and
> multi-homed deployments (*if you don't understand why the difference has no
> virtue, ping me on or off list and I will show you the math as I see it).
>  Text might look something like:
>
>         "In order to receive an initial allocation from ARIN, an
> organization must:
>
>                 - demonstrate they operate an IP network that requires
>                 IPv4 addresses to deploy and/or grow; and
>
>                 - provide a numbering plan detailing how IPv4 addresses
>                 will be used in the first 180 days upon receiving an
> allocation.
>
>         ARIN will review and verify the data provided, and provide for the
> organization's 6 month need."
>
> - A section on obtaining additional blocks, which still outlines the 80%
> rule. ("If you've efficiently used what you have, you can have more" is a
> technically sound concept that does not need much fixing.)  Platform
> differences which are already fleshed out in NRPM (e.g., residential market
> area provider networks with their different metrics than more common
> buildouts) can and should remain.
>

The 80% rule may not be appropriate in the IPv6 realm. I would argue that
the percentage should be less for IPv6 additional requests.


>
> - We would have to figure out what to do with the requirement to SWIP, as
> the requirement is predicated on the classification of "ISP" actually
> existing (which it would not).  That might need a working group to
> reconcile.
>
> - A section on obtaining initial IPv6 addresses from ARIN. Given that IPv6
> is still very much in its infancy, I really would like to see very simple
> NRPM text which allows requestors to self-select what size block they need.
> The only barrier to abuse or silliness would be the fee schedule.   It is
> arrogant and technically indefensible that ARIN policy today tries to
> dictate what a network does, and does not, justify as far as block size.
>  IPv6 is much too immature for ARIN policy to presume such wisdom.
>

I do not agree that IPv6 is "very much in its infancy" or "immature". We
have had IPv6 deployed in some form since 1997. Any forward thinking R&E
should already be there. By those standards IPv4 was immature back in the
late 1980's, but that sure didn't stop an Internet explosion. Fee schedules
should not be implemented in any way that will prohibit IPv6 adoption. In
other words blocks of IPv6 addresses should remain relatively easy to
justify the need for.


>
> - A section on obtaining additional IPv6 addresses from ARIN.  Existing
> text in 6.5.3 is probably good enough for today, as there are only a
> handful of networks in the world with any experience needing additional
> IPv6 addresses due to efficient use of an initial block.  Obtaining
> additional IPv6 addresses is a topic for many years from now, not today.
>

I think there are already organizations requesting additional allocations
of IPv6 addresses. Don't shove it under the rug and pretend its not an
issue. Better to figure it out ahead of the growth curve.



> Do you think any of this has value?  Would it accomplish the overarching
> goal of improving ARIN policy to make it relevant to network operators in
> 2014 and beyond?  What would your sane NRPM look like?
>
> With regards,
> David
>
>
> _______________________________________________
> 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/20130719/8bc5018d/attachment.htm>