> On Apr 11, 2016, at 15:05 , Chris Woodfield <[email protected]> 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 <[email protected] >> <mailto:[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.
