[arin-ppml] ARIN 2-Byte ASN inventory and issuance

Tue Apr 12 10:46:22 EDT 2016

This is a commercial view of the world; Part of the network here is a SDN network where we build layer-1 optical or layer-2 VPN with research organizations spread from Chicago and El Paso to Tokyo. I have no control over the equipment at the remote end; I don’t want to have to argue with a research team about how they ought to upgrade or run their equipment, I need the easiest way I can to setup BGP peering for a fragment of our address space without breaking the whole of routing for campus.

Yes, obtaining a 2-byte ASN was for the convenience of me not arguing with a network engineer in Tokyo, Qatar, or West, Texas about them upgrading their equipment because frankly, for my users, it’s all about the research and moving train-loads of data as quickly as possible.

Thank you
Richard Letts

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
Sent: Monday, April 11, 2016 5:03 PM
To: Chris Woodfield <chris at semihuman.com>
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN 2-Byte ASN inventory and issuance

The harm is that this continued practice is hampering deployment of exchange point RS with artificial imposition of requirements for ASNs ≤65535 for no reason other than the convenience of operators who come to the exchange(s) with obsolete equipment or antiquated policies.

Owen

On Apr 11, 2016, at 15:25 , Chris Woodfield <chris at semihuman.com<mailto:chris at semihuman.com>> wrote:

I’ll note that there are some pretty substantial “ifs” in your statement there. Not all operators are in a position to satisfy those “ifs”.

Also, how is this behavior harmful? What operational issues arise from use of the backward-compatible mode here? Is it just a matter of not being able to see other ASNs with 23456 in path if you’re running in compatibility mode? If so, that’s not going to impact anyone but the operator itself (which IMO should be motivation enough to upgrade, but I don’t control those operator’s budgets).

-C

On Apr 11, 2016, at 3:08 PM, Owen DeLong <owen at delong.com<mailto:owen at delong.com>> wrote:

On Apr 11, 2016, at 15:05 , Chris Woodfield <chris at semihuman.com<mailto:chris at semihuman.com>> wrote:

I’d argue that doing so ignores the fact that 2-byte vs 4-byte AS numbers (yes, I’m still using that terminology, so sue me) are handled fundamentally differently by the BGP protocol. As such, this isn’t a place where we can effectively boil the ocean and force providers to update their hardware via policy.

Actually, they aren’t treated at all differently if you are using the modern configuration options.

Sure, if you are continuing to use traditional communities, you are limited to low-order ASNs in the ASN portion of the community string.

Sure, there’s a certain amount of backwards-compatible handling of ASPATH management in modern routers and that code still gets occasionally exercised in interacting with ancient equipment still in operation.

However, if you have a configuration using extended communities and full support of modern ASNs enabled on your router, then all ASNs are treated as 32-bit ASNs and there is no fundamental difference remaining.

There’s no attempt to boil the ocean and force providers. Merely an attempt to recognize that the days of treating them differently have, in fact, passed in most of the world and we shouldn’t be further enabling the harmful behavior of pretending otherwise.

If this is such a huge issue, why isn’t it coming up in the other RIRs?

Owen

As such, I’d far prefer that *as available* we continue to keep 2-byte ASNs in reserve for providers who can document their reasons for not being able to support having a 4-byte ASNs. Obviously there will be a day where those are all gone and then we’ll have no choice but to force operators to run compliant hardware/software.

Note I’m making it clear that this isn’t just a matter of software; there’s quite a bit of gear out there on the internet that doesn’t have available software at all that supports 4-byte ASNs. And there are definitely operators that don’t have the budget to swap it out.

This isn’t a case of inefficiency, it’s simply the fact that many providers are stuck using old hardware. Given negligible cost to accommodate, I have no problem doing so.

Thanks,

-C

On Apr 11, 2016, at 2:53 PM, Owen DeLong <owen at delong.com<mailto:owen at delong.com>> wrote:

On Apr 11, 2016, at 14:38 , John Curran <jcurran at arin.net<mailto:jcurran at arin.net>> wrote:

On Apr 11, 2016, at 5:06 PM, Owen DeLong <owen at delong.com<mailto:owen at delong.com>> wrote:

On Apr 11, 2016, at 12:24 , John Curran <jcurran at arin.net<mailto:jcurran at arin.net>> wrote:
Since parties coming to ARIN are distinguishing between these classes of 4-byte ASNs
and come back explicitly asking for one ≤65535, are you suggesting that ARIN not hold
these lower ones to be able to satisfy such requests?

Yes.

I believe that we, more than any other region, have been lazy in our adoption of current internet technologies to the detriment of the internet at large.

I believe that continuing to facilitate this is not providing a useful service to the internet as a whole.

Just to be clear, you feel that ARIN registry policy which rapidly depletes the
lower range of 4-byte ASNs would be technically sound and facilitate fair and
impartial number resource administration?

No. I believe that ARIN registry policy which ignores any previous distinction
between ASNs ≤65535 and ASNs ≥65536 is harmful. I believe that a policy which
makes no distinction and hands them out as if they were a single pool of 32-bit
numbers is in the best interests of the community.

At some point there will no longer be available ASNs ≤65535. So be it. That
date should neither be accelerated nor decelerated by ARIN policy.

It would be helpful if you could explain how in some detail, given that there
appears to be sufficient number of lower range 4-byte ASNs for those who
require such for their operations, and further that the supply appears to be
sufficient for quite some time (potentially till there is greater acceptance
and far fewer hurdles with the use of higher range 4-byte ASNs…)

So far, I haven’t seen so much a requirement as a convenience request for those
lower numbers.

Owen

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto:ARIN-PPML at arin.net>).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net<mailto:info at arin.net> if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20160412/d522782a/attachment.htm>