[arin-ppml] ARIN 2-Byte ASN inventory and issuance

Chris Woodfield chris at semihuman.com
Mon Apr 11 18:25:27 EDT 2016


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 <owen at delong.com> wrote:
> 
> 
>> On Apr 11, 2016, at 15:05 , Chris Woodfield <chris at semihuman.com <mailto:chris at 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 <owen at delong.com <mailto:owen at delong.com>> wrote:
>>> 
>>>> 
>>>> On Apr 11, 2016, at 14:38 , John Curran <jcurran at arin.net <mailto:jcurran at arin.net>> wrote:
>>>> 
>>>> On Apr 11, 2016, at 5:06 PM, Owen DeLong <owen at delong.com <mailto:owen at delong.com>> wrote:
>>>>> 
>>>>> On Apr 11, 2016, at 12:24 , John Curran <jcurran at arin.net <mailto:jcurran at 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 at arin.net <mailto:ARIN-PPML at 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 info at arin.net <mailto:info at arin.net> if you experience any issues.
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20160411/ce1ca1a6/attachment.htm>


More information about the ARIN-PPML mailing list