[arin-ppml] ARIN-2012-3: ASN Transfers - Last Call

[McTim]

On Wed, May 16, 2012 at 1:35 AM, Tom Vest <tvest at eyeconomics.com> wrote:
>
> On May 9, 2012, at 8:30 PM, William Herrin wrote:
>
>> On 5/9/12, John Curran <jcurran at arin.net> wrote:
>>>> ARIN-2012-3: ASN Transfers
>>>
>>> I was asked recently about the number of issued and not presently
>>> advertised ASN's in the ARIN region, and thought it best to reply
>>> publicly so everyone has the same information.
>>>
>>> ARIN does not directly monitor ASN usage, but the esteemed
>>> Geoff Huston does at <http://www.potaroo.net/tools/asn32/>
>>>
>>>> From that report as of this morning -
>>>
>>>   There are 24406 16-bit ASN's assigned to the ARIN region, with
>>>   1099 presently in the regional free pool, 8259 unadvertised in
>>>   BGP, and 15048 advertised in BGP.
>>
>> Interesting!
>>
>> For folks looking for a reason for AS number transfers, here's a thought:
>>
>> Implementing BGP communities is a nuisance with a 32-bit AS number.
>> The convention is: 16 bits AS number, 16 bits tag. Virtually every
>> shipping router is configured to display them in this manner. AS
>> numbers larger than 65535 require a service provider who wants to
>> offer communities to implement it in an unconventional manner. This
>> can be expected to cause collisions and other confusion in this
>> tagging mechanism for downstreams with more than one BGP link. Where
>> an organization wishes to implement communities, a 16-bit AS number is
>> *highly* desirable on a technical basis.
>>
>> Geoff's numbers suggest that there are upwards of 8,000 16-bit as
>> numbers recoverable in the ARIN region, some third of the total. Given
>> some incentive for the current holders to release them of course. When
>> we run out of fresh 16-bit AS numbers, the availability of those 8,000
>> would simplify operations for new ISPs and new ISP efforts which use a
>> distinct AS number.
>>
>> Tom, is that a good enough reason to allow an AS number transfer? As a
>> technical necessity to follow the conventions for BGP communities?
>>
>> Regards,
>> Bill Herrin
>
>
> Hi Bill,
>
> Apologies for not responding to this question when you first posed it -- local distractions have been more numerous/pressing than usual, and I didn't want to respond before thinking about this a bit more.
>
> No surprise perhaps, but In the end I come to the same conclusion via the same logic that I applied to earlier transfer-related proposals. That is to say, I recognize that it is possible -- at least for a subset of a subset of current/incumbent operators in very narrow, specific operational circumstances -- to make a valid argument in favor of resource transfers as proposed based on the relative "technical" merits/convenience of the expected/best-possible results (i.e., the potential for some operators to buy/sell options to postpone or completely avoid the extra work vs. uncertainty tradeoffs associated with ASN32 BGP community interop, potentially until "everything gets sorted out" by someone else), assuming that all else remains equal.  However, as with previous transfer proposals, I believe that the cons outweigh the pros by a wide margin. Or, to be more specific...
>
> Assuming that "all else remains equal" (i.e., no second-order, unintended effects):
>
> 1. The relative benefits that ASN transfers would provide as a response to this *specific* problem (i.e., as compared to non-transfer related alternatives), and the relatively modest size of the operator population to whom those benefits might be accessible, seem very very modest to me when compared to both (a) the lure of all of the other purely commercial/strategic ASN transfer-related aspirations that the community has already considered and rejected, and (b) the much larger population of current and future ARIN community members who are unlikely to ever use BGP communities externally, and who -- given the numerous and now unavoidable risks and uncertainties to come thanks to IPv4 exhaustion/IPv6 adaptation -- would almost certainly benefit more from maintaining something that more closely resembles the "status quo" in ASN-related policies.

+1  I am also opposed to 2012-3



>
> 2. The huge asymmetry in the relative duration(s) of impacts depending on whether this proposal is adopted or rejected. Assuming that the demand for ASN16 remains steady at appx. current rates, it seems quite likely that vendor code and/or other mechanisms for reducing the risk of ASN32 community collisions, etc. will become widely available in the not-too-distant future -- which means that 100% of the relative benefits to current extended community option users that you've highlighted will disappear in, at most, a couple of years. By contrast, the additional operational uncertainty and unpredictability that this policy would visit upon all ASN holders/BGP speakers and their customers -- not to mention the perverse incentives that this change would impose on the vastly larger number of operators, and non-operators, who likely would never have any (other) interest in BGP community options of any kind -- would go on forever, or at least for as long as BGP is widely used.
>
> To me, this seems like ample justification to oppose this proposed change.

Agreed.


-- 
Cheers,

McTim
"A name indicates what we seek. An address indicates where it is. A
route indicates how we get there."  Jon Postel