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

[David Farmer]

On 7/31/12 20:57 CDT, Seth Mattinen wrote:
> On 7/31/12 6:17 PM, Owen DeLong wrote:
>> There's been a lot of discussion here about this between Seth
>> and I. How do others feel about putting in a restriction that subsequent
>> non-renumbered requests wait one-year after submitting the prior
>> request?
>>
>> Generally, I oppose the idea of a waiting period as an unnecessary
>> inconvenience both to the requestor and to staff which provides little,
>> if any benefit to the community. However, if that will help us move the
>> policy proposal forward with greater consensus, then I would consider
>> it an acceptable tradeoff. I would like to hear more from the community
>> about whether such a modification to this proposal would increase or
>> decrease your willingness to support it.
>>
>
>
> If the goal is uniformity and equality for the benefit of all orgs, then
> I would also support including a modification to 4.2.1.5 and 4.2.2.2 to
> lower minimum multihomed allocations to /24 concurrent with removing the
> renumber requirement in 4.3.2.2 without adding any sort of waiting period.

I'd be willing to support a /24 minimum for both ISP and end user 
Multihomers without a renumbering or waiting period.

However, my support for end user /24 Multihomers is stronger.  There are 
a lot of  organization that are not ISPs that can make effective use of 
/24 and they can be sizable organizations.

Where as, an ISP that isn't large enough to justify a /20 is generally a 
much smaller organization than an end users organization that only 
justifies a /24.  Therefore, the distinction between end users and ISPs 
on this point is not completely arbitrary and has at least some merit.

So, I support removing the renumbering requirement for small end user 
multihomers.  Independently, I support /24 minimum for multihomed ISPs 
as well.  But I'm not wiling to tie removing the renumbering requirement 
for small end user multihomers, to a  /24 minimum for multihomed ISPs. 
If there isn't consensus for the later we should still do the former.

Alternatively, I support a more optional renumbering clause for end 
users kind of like "4.2.2.1.4. Renumber and return" for ISPs.  At this 
point in the IPv4 game requiring anyone to renumber seems like a highly 
punitive requirement.  Not because of the work of renumbering but 
because of issues of the IPv4 exhaustion and having to go to the market 
to get a /23 and renumber out of their current /24 just to effectively 
get a /24.

If it was only about the cost of renumbering I wouldn't make a big deal 
about it, but when you end up have to go to the market to get IPv4 
addresses then this requirement is doubly punitive to small end users. 
This is also punitive to the community because there is a supply of 
swamp /24s out there that could be put to effective use by small end 
users.  If there are going to multihome anyway the route table is going 
to grow anyway.  The only real danger of route table growth is if end 
users that wouldn't multihome anyway multihome to just to get a /24.  Is 
that going to happen, sure in some cases, but they have to get another 
ISP contract.

So, they will be contributing to the Internet ecosystem to get the 
privilege of requesting the /24, and that now becomes a market place 
issue not a policy issue in my book.

I just looked;

There are 759 and 1745 unaggregateable /23s and /24s respectively in 
ARIN's inventory right now.  I would rather see ~2500 routes from 1000 
to 2000 small guys using those prefixes over the next year or so, than 
fewer bigger guys using them.  It will provide the most benefit to the 
largest number of people in my opinion.

-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================