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

[Tom Vest]

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.

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.

That said, if one is prepared to drop the artificial (and IMO, unrealistic) assumption that "all else would remain equal," then it seems to me that the argument against ASN transfers is even stronger. 

1. Assuming that actual operational reliance on extended community options is more commonplace among large networks and transit providers than among than among smaller operators, the proposed rationale-policy would likely exacerbate the present pattern/trend toward ASN16 concentration, and thus shift us toward a future in which an ever-increasing share of those operators who possess the greatest capacity to contribute to an industry-wide "sorting out" of ASN32 issues choose instead to exercise the option that they purchased, in the form of ASN16 transfers, to just wait and let others work out the kinks. At best, this would likely push the achievement of rough ASN16-ASN32 technical and operational parity yet further into the indefinite future.

2. At worst, it might cause the ongoing, gradual narrowing over time of the perceived and actual feature gaps separating ASN16s from ASN32s to decelerate, or even to reverse course, multiply, and grow larger. The ultimate culmination of such a reversal would be the commercial rejection/non-viability of ASN32s, and the industry-wide "adverse selection" of perpetually scarce ASN16s.

Conceivably, if credible evidence were to come to light indicating that current operational reliance on extended community options is uniform across operators of all sizes, then I might wish to reconsider my position. Alternately (per my message @May 4, 2012 5:29:20 PM EDT), if at some point in the future we learn that the preponderance of ASN16-based, extended community options-using operators have extended "most favored ASN format" treatment to their ASN32-based providers, peers and customers in all (other) operational matters, then I might temper or completely drop my objections at that point.

Until such time, however, I am & will likely remain opposed.

Regards, 

TV