[arin-ppml] Draft Policy ARIN-2012-5: Removal of Renumbering Requirement for Small Multihomers

[Owen DeLong]

On Jul 31, 2012, at 12:29 , Seth Mattinen wrote:

> On 7/31/12 12:37 AM, Owen DeLong wrote:
>> 
>> On Jul 30, 2012, at 20:50 , Seth Mattinen wrote:
>> 
>>> 
>>> 
>>> I understand the nature, I just have a different opinion on the
>>> motivation behind it. Are these orgs requesting more address space
>>> within a timeframe they could have justified a /22 for in the first
>>> place? Are they picking the /24 as an easy entry point and are then
>>> upset there's strings attached that could have been avoided? Are
>>> hundreds of orgs bumping up against the renumber clause or is it just
>>> one or two being loud about it?
>>> 
>> 
>> In most cases, no... Usually they're wanting to come back 2-3 years
>> after getting their /24. Many of these organizations are very small
>> community networks, neighbornets, and the like.
>> 
>> No, it's not hundreds of orgs, nor is it one or two. It's a relatively small
>> number (i.e. not likely to be a significant routing table problem), but more
>> than a few.
>> 
> 
> I would argue there's no reason to change policy for a few orgs when the
> majority aren't affected by current policy in a negative way. There will
> always be at least one.
> 

I would argue that since the policy as is is not providing any benefit and
changing the policy would do no harm and provide benefit, changing policy
makes sense.

> 
>>> I see too many appeals to emotion with the use of phrases like "forced
>>> to suffer the pain and expense of renumbering" (from ARIN staff
>>> comments, which to me indicate an emotional appeal devoid of any
>>> technical merit). The rationale statement itself uses "undue burden of
>>> renumbering" when it was a known restriction in the beginning. A small
>>> multihomer with a /24 was *already* unique just be being able to have a
>>> /24 with practically no justification. To get the /24 they just have to
>>> say "I'm going to multihome!" and leave it at that. Then later they go
>>> "oh, I want more and the internet is being unfair to me". If, for
>>> example, they're blowing through their /24 in a matter of months and
>>> suddenly want more they should not have received a /24 in the first place.
>>> 
>> 
>> It was a restriction put in to get a policy to enable them to get space at
>> all while appeasing the table-growth fanatics. Now we have evidence
>> that the table growth fears are utter nonsense, so the burden doesn't
>> make sense and we're seeking to improve the policy and make it more
>> even handed for all recipients.
>> 
> 
> Routing table growth is not a consideration it in my opposition of this
> policy change. The worst I see with table growth is that /24s could
> start to become unroutable, but that's not a policy problem either.
> 

Nonetheless, that is the sole and only reason justifying the current renumbering
requirement and its cutoff at /22.

> 
>>> Instead of altering policy to cater to what may simply be bad planning
>>> or lack of awareness, I would suggest that this policy be abandoned and
>>> in its place have orgs receiving a /24 attest that they acknowledge that
>>> a) if they require more space in the future they must return and
>>> renumber and b) if they have any inkling of growth they should do their
>>> homework first to see if they can justify a /22. ARIN started doing the
>>> officer attestation thing in the face of runout, why not educate first
>>> instead of jumping straight to altering policy?
>>> 
>> 
>> I don't think it is either bad planning or lack of awareness and I find your
>> prejudices about this to be somewhat condescending.
>> 
> 
> So far it's been emotional appeals (I pointed out the two I didn't like
> seeing) to have the requirement removed, none of which I see as a basis
> to change policy.

I see the argument for the existing policy as purely emotional appeal at this
point.


> 
> 
>> I don't know why you assume they haven't been educated. Knowing doesn't change
>> the fact that once you assign a bunch of /28s, /29s, and /32s to customers,
>> it's hard to renumber them all in order to get more space or the fact that
>> it is an unreasonable burden that unfairly stacks the deck against these
>> smaller organizations that are NOT a serious threat to the routing table.
>> 
> 
> I've been there and done that with two PA /24s I don't think it was a
> burden, unfair, or stacked the deck against me. I expected it from the
> start and planned accordingly. 12 months was *plenty* of time to
> renumber. Based on my own experience with renumbering small networks I
> can't agree with the hardship argument. I would agree that having to
> renumber a larger network (/22 or shorter) becomes a logistical
> nightmare, but not a /24 within 12 months.
> 

I've been there and done that too. Many times in a variety of circumstances.
It really depends on the nature of the network and a number of factors unrelated
to the size.

When you have a customer-affecting renumbering requirement, it is nearly
inevitable that you lose some customers in the process. If the customer has
to renumber, they start considering what other changes they can make while
involved in network upheaval anyway. Nature of the beast. If you're going from
/24 to /23 and risk having to do this again to go to /22, then you're at even more
of a disadvantage as your customers will be looking to renumber into a place
where they won't face forced renumbering again.

> 
>>> Or, another suggestion I would consider supporting depending on how it's
>>> worded: in place of dropping the renumber requirement completely change
>>> it to say that if they request for more space is within 24 months of the
>>> original request then they must renumber and return. If they've had
>>> their /24 for longer than 24 months only then will the renumber and
>>> return requirement be waived.
>> 
>> I could probably live with this. However, would you be willing to compromise
>> to 18 months? Remember, they have to do the initial justification based on
>> only 12 months (or in some cases 3).
>> 
> 
> 
> I'm only aware of a three-month rule for allocations, not end-user
> assignments, and the /24 is only mentioned under assignments.
> 

Fair point. Nonetheless, doubling the anticipated lifespan still seems
excessive to me.

> In 4.3.3 it says "Requesters must show exactly how previous address
> assignments have been utilized and must provide appropriate details to
> verify their one-year growth projection." Are any orgs requesting a /24
> using it as their first foray (and if so, how are they showing previous
> assignments) or are they always coming from longer PA prefixes? A PA /24
> can be justified with nothing more than stating "I intend to multihome".

Most of the organizations I am aware of are showing that they are using
100% of no previous assignments and that they are deploying a sufficiently
large network to justify a multi-homed /24. Often this is done with a
combination of peering contracts, invoices for hardware, and other
such evidence of deployment. Thus, it is usually their initial assignment
rather than using prior assignments as justification.

Admittedly, my experience is limited to those organizations whose applications
I am familiar with or involved in. ARIN may have other data, but they would
be unable to share same.

> I suppose I'd support 18 months but would strongly prefer 24. If an org
> is requesting additional space near the two year mark then I feel it
> shows they've planned appropriately. If they're asking for more in short
> order I feel it's inappropriate because their justification should have
> said they would have been fine for at least a year (50%), and they can
> probably justify a /22 to renumber into or should have justified a /22
> from the beginning.

They were given space based on their 12 month growth plan.

How is asking for more a year later poor planning? If you run out a year
after you got space based on your one-year growth projection, I'd
call that extremely good planning. If you run out after 18 months, I'd
call that optimistic growth projections. If it takes you two years to fill up
your "one year growth plan", I'm not sure I can see that as good planning.

Your attitude here mystifies me.

> When I think of a "small" org I think of all the ones I've dealt with in
> the past and present that could easily survive on a single /24 for
> years, if not for the life of the org. I *do not* see it as "starter" PI
> space that they'd quickly outgrow.

There are many sizes of organizations in the real world. Some small
multi-homed organizations can, indeed, survive on a /24 for many years
and may well be doing so. Others have a one-year growth projection that
really maxes out their /24 and will grow beyond it in about one year.
Others will grow slower or faster than that.

Sometimes you have a realistic growth projection that exceeds a /24
in a year, but you cannot convince ARIN of the realism of that plan.
I would not call having to get more space in 6 months because of that
poor planning. However, I can accept the argument for an 18 month
moratorium, but would strongly prefer 12 or less, if any.

> Place renumber-and-return under a timeframe plus remove the appeals to
> emotion from the proposal and I'd reconsider my opposition.
> 

Noted.

Owen