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.
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 <[email protected]> wrote: > >> >> On Apr 11, 2016, at 14:38 , John Curran <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Apr 11, 2016, at 5:06 PM, Owen DeLong <[email protected] >> <mailto:[email protected]>> wrote: >>> >>> On Apr 11, 2016, at 12:24 , John Curran <[email protected] >>> <mailto:[email protected]>> 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 ([email protected] > <mailto:[email protected]>). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > <http://lists.arin.net/mailman/listinfo/arin-ppml> > Please contact [email protected] <mailto:[email protected]> if you experience any > issues.
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
