[arin-ppml] Draft Policy 2012-3: ASN Transfers

David Farmer farmer at umn.edu
Thu Mar 15 20:56:53 EDT 2012



On 3/15/12 19:52 CDT, David Farmer wrote:
>
> On 3/15/12 18:40 CDT, Joe Maimon wrote:
>>
>>
>> Jeffrey Lyon wrote:
>>
>>>> From a marketing standpoint, there seems to be an understanding that
>>> lower numbered AS means better established carrier. Those looking to
>>> offer network services may wish to acquire older networks and merge
>>> into the lower numbered AS. We are AS32421, and a customer of ours was
>>> just issued a 4 digit ASN. I'd be willing to trade for aesthetic
>>> reasons ;)
>>>
>>> This is the only reason I can think of.
>>>
>>> Thanks,
>>
>> Given the coming exhaustion of 2byte ASN, and the difficulties with
>> 4bytes, given my druthers I would much rather get one on the transfer
>> market for a reasonable price so that I can use the nice community
>> attribute layout and keep all my old gear, have zero inter-operation
>> concerns, and appear to be an older established network.
>>
>> Yes, I am one of those guys who try to ensure those whom I consult for
>> and advise get a 2byte while they still can. Nobody has complained that
>> they wanted the 4byte instead.
>
> Also, there seems to be a lot of 2 byte ASNs assigned but not visible in
> the routing system, over 16,000. Yes, at least some of those are
> actually in use, but not visible to the majority of the routing system.
> But, I suspect the vast majority of those 16,000 are just not in use any
> longer. See;
>
> http://www.potaroo.net/tools/asns/index.html
>
>> Or suppose I am transferring addresses and I want the routing gear along
>> with it, but this is not quite an M&A or structuring it as one has its
>> own disadvantages.
>>
>> Or I was your customer and you has an extra one and I used it for all
>> this time and I would like it to outlive our relationship and I dont
>> want to redo all my stuff.
>
> These seem a little hypothetical to me, but still possible.
>
>> I support directed transfers of all resources. Picking and choosing is
>> not quite right, even if it might be more prudent, where there to be no
>> identified benefits.
>
> I'm NOT ready to go all the way and include IPv6, at least not yet.
> Before allowing IPv6 specified transfers, I think we need a lot more
> discussion and thought about technical issues like sparse aggregation,

I meant "sparse allocation", but I'm sure a discussion of "sparse 
aggregation" would be really interesting. :(

> etc... Bedsides there is no good reason to institute a recycling program
> for IPv6, not yet, maybe some day.
>
> Although, I'm ready to take the next step and include ASNs, in
> particular 2-byte ASN. I think I like Kevin's suggestion to restrict ASN
> transfers to 2-byte ASNs only, at least for now. We are running low and
> there can be valid reasons to recycle 2-byte ASNs, no where near as
> strong of reasons as the reasons to recycle IPv4 addresses, but still
> valid.
>
>> Support.
>
> I think I support it too, but think I would like the 2-byte ASN
> restriction added.
>
> If we decide to not allow ASN transfers then we should probably work on
> an awareness campaign and get people to return unused 2-byte ASN, maybe
> get the Board to approve some kind of discount for the return of 2-byte
> ASNs. ARIN could even, put something on the annual invoice, let people
> know they have an ASN that doesn't seem to be in the routing system, and
> allow then to return it and save a $100 or $250 on the invoice.
>
> This is NOT a critical issue like IPv4 exhaustion, but we probably
> shouldn't completely ignore the issue either. Fundamentally, I prefer a
> voluntary transfer system to most any kind of reclamation system, both
> for IPv4 addresses and 2-byte ASNs.
>

-- 
===============================================
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
===============================================



More information about the ARIN-PPML mailing list