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-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On Behalf Of Owen DeLong Sent: Monday, April 11, 2016 5:03 PM To: Chris Woodfield <ch...@semihuman.com> Cc: arin-ppml@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 <ch...@semihuman.com<mailto:ch...@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 <o...@delong.com<mailto:o...@delong.com>> wrote: On Apr 11, 2016, at 15:05 , Chris Woodfield <ch...@semihuman.com<mailto:ch...@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 <o...@delong.com<mailto:o...@delong.com>> wrote: On Apr 11, 2016, at 14:38 , John Curran <jcur...@arin.net<mailto:jcur...@arin.net>> wrote: On Apr 11, 2016, at 5:06 PM, Owen DeLong <o...@delong.com<mailto:o...@delong.com>> wrote: On Apr 11, 2016, at 12:24 , John Curran <jcur...@arin.net<mailto:jcur...@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@arin.net<mailto:ARIN-PPML@arin.net>). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net<mailto:i...@arin.net> if you experience any issues.
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
