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> 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 >>> <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.
