[arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations

[Chris Grundemann]

On Thu, Nov 5, 2009 at 23:31, Seth Mattinen <sethm at rollernet.us> wrote:
> Chris Grundemann wrote:
>> On Thu, Nov 5, 2009 at 15:46, Seth Mattinen <sethm at rollernet.us> wrote:
>>> Member Services wrote:
>>>> 4.2.2.5. Replacement initial allocation
>>>>
>>>> Any ISP which has received an initial allocation, or previous
>>>> replacement initial allocation, smaller than /20 who wishes to receive
>>>> additional address space must request a replacement initial
>>>> allocation. To receive a replacement initial allocation, an ISP must
>>>> agree to renumber out of and return the existing allocation in it's
>>>> entirety within 12 months of receiving a new allocation and provide
>>>> justification for the new allocation as described in section 4.2.4.
>>>>
>>> OPPOSE. A small org might expect to grow and can be punished multiple
>>> times (until they get a /20) by forced renumbering. An end-site office
>>> building, sure, force them to renumber, but not an ISP who is assigning
>>> address blocks to downstream orgs and customers.
>>
>> So, just to be clear Seth; you would rather that small ISP not be able
>> to get resources from ARIN at all then for them to be eligible but
>> have to renumber?
>> ~Chris
>>
>
>
> If I'm reading the policy correctly, PA->23 is a renumber, 23->22 is a
> renumber, 22->21 is a renumber, and 21->20 is a renumber. That's four
> potential renumbering cycles, each one exponentially harder. Renumbering
> sucks. I still have people trying to reference PA addresses I returned
> over half a decade ago (and complaining about it) in spite of every
> humanly effort possible.
>
> It's relatively easy to get PI space under the current policy. A PA /24
> can be had like candy if you say the magic word "multihoming", and
> another /24 can be easily justified with proper planning if you're for
> real. Or just tell two different upstreams you're multihoming and ta-da,
> you have two /24's.
>
> Looking at myself, had such a policy been in place when I just recently
> needed to get more space after my initial /22 to open up the floor for
> more colos, it very well could have broken my business. Ignoring the
> aspect of forcing customers you've reassigned space to to renumber, I've
> worked very, very hard to defend and establish what I hope is a good
> reputation for my PI space. Then there's whatever static whitelists it
> may be in out there in the world (that I could never hope to find or
> update) plus everything customers have configured in their systems. To
> throw it all away and start over would be a nightmare. I'd rather only
> have to renumber once out of PA into PI space (which I did over the span
> of 6 months). This may or may not be unique to me.

Would you support the proposal if it only had a renumbering
requirement up to /22 (the current minimum initial allocation for
multihomed ISPs)?  That would still help keep the impact of lowering
the minimum initial allocation on the routing table down but would not
introduce any new barriers to ISPs qualify under current policy
either.

The general intent of this policy is to make things easier for very
small ISPs while balancing any side effects for the rest of the
community.

~Chris

>
> I like the idea as it would apply to an end-site office or something -
> they can eat the renumbers 'til the cows come home if they want more
> space and return the smaller piece. But for any service provider who may
> be reassigning address space to systems/networks/entities beyond their
> reasonable control or have a guarded reputation attached to it, you
> could end up losing customers to someone who has stable addressing if
> the customer realizes they have to renumber either way.
>
> ~Seth
> _______________________________________________
> 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.
>

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org