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