ISP support for use of 4-byte ASNs in peering
Folks - Is there a public list somewhere of service providers that do not support 4-byte autonomous system numbers when peering? (if not, should there be one?) At ARIN, we are still having parties returning 4-byte ASN's (seeking 2-byte instead), indicating that the 4-byte ones are not sufficiently accepted in peering to be usable. This is obviously a less than desirable situation, and it appears that it is not trending towards resolution at this time. Thoughts? /John John Curran President and CEO ARIN
On 09/08/2011 14:47, John Curran wrote:
At ARIN, we are still having parties returning 4-byte ASN's (seeking 2-byte instead), indicating that the 4-byte ones are not sufficiently accepted in peering to be usable. This is obviously a less than desirable situation, and it appears that it is not trending towards resolution at this time.
At INEX, we see 60% of IXP connections which can handle ASN32 natively. However, INEX is a small IXP and I haven't seen similar figures from other IXPs which could validate this 60/40 split. Having said that, in the IXP world most new service providers connect into route servers, so there is often no perceived requirement for direct ASN32->ASN16 interconnection - the intersection of new service providers and ASN32 holders is quite large. And if you really want a bilateral peering relationship, there's no reason not to use AS23456.
Thoughts?
- interior BGP community management is great fun with an ASN32, oh yes. - i don't have much sympathy for people who whine about not being able to support ASN32 peerings. There is no good reason for this these days. - from personal experience, I understand why ASN32 is less popular. However, it's certainly usable. Nick
While attempting to focus on ISPs there is still [unbelievably] a vendor support issue. You may consider this a procurement failure, but the fact remains that some products [Cisco me3400e] have yet to implement support. -Michael On 8/9/2011 9:24 AM, Nick Hilliard wrote:
On 09/08/2011 14:47, John Curran wrote:
At ARIN, we are still having parties returning 4-byte ASN's (seeking 2-byte instead), indicating that the 4-byte ones are not sufficiently accepted in peering to be usable. This is obviously a less than desirable situation, and it appears that it is not trending towards resolution at this time.
At INEX, we see 60% of IXP connections which can handle ASN32 natively. However, INEX is a small IXP and I haven't seen similar figures from other IXPs which could validate this 60/40 split.
Having said that, in the IXP world most new service providers connect into route servers, so there is often no perceived requirement for direct ASN32->ASN16 interconnection - the intersection of new service providers and ASN32 holders is quite large. And if you really want a bilateral peering relationship, there's no reason not to use AS23456.
Thoughts?
- interior BGP community management is great fun with an ASN32, oh yes.
- i don't have much sympathy for people who whine about not being able to support ASN32 peerings. There is no good reason for this these days.
- from personal experience, I understand why ASN32 is less popular. However, it's certainly usable.
Nick
On 09/08/2011 15:45, Michael Hare wrote:
While attempting to focus on ISPs there is still [unbelievably] a vendor support issue. You may consider this a procurement failure, but the fact remains that some products [Cisco me3400e] have yet to implement support.
the me3400 is a metro core ethernet switch with L3 extensions. It's not intended as a border router. If you use the wrong tool for the job... Nick
Aren't there still community issues with 4 byte ASN space as well that have not been resolved? -Blake
On 09/08/2011 16:43, Blake Dunlap wrote:
Aren't there still community issues with 4 byte ASN space as well that have not been resolved?
I think I mentioned that. draft-raszuk-wide-bgp-communities will fix this, but it's unclear when we'll start seeing this rolled out in production code. Nick
Granted I've never worked outside academia but the me3400 is otherwise a cost effective gig-e demarc for very simple bgp multihoming. They have made a strategic decision to not implement a simple software update support RFC4893 [it has been 4 years] and to set an artificial price point on entry. Fine, that is their choice. There are other vendors offering 4 byte ASN in simliar products at or near this price point and we'll probably have to move to them. -Michael On 8/9/2011 10:38 AM, Nick Hilliard wrote:
On 09/08/2011 15:45, Michael Hare wrote:
While attempting to focus on ISPs there is still [unbelievably] a vendor support issue. You may consider this a procurement failure, but the fact remains that some products [Cisco me3400e] have yet to implement support.
the me3400 is a metro core ethernet switch with L3 extensions. It's not intended as a border router. If you use the wrong tool for the job...
Nick
John Curran wrote:
Folks -
Is there a public list somewhere of service providers that do not support 4-byte autonomous system numbers when peering? (if not, should there be one?)
At ARIN, we are still having parties returning 4-byte ASN's (seeking 2-byte instead), indicating that the 4-byte ones are not sufficiently accepted in peering to be usable. This is obviously a less than desirable situation, and it appears that it is not trending towards resolution at this time.
Perhaps you meant to send this to c-nsp and re-worded it slightly? - Kevin
participants (5)
-
Blake Dunlap -
John Curran -
Kevin Loch -
Michael Hare -
Nick Hilliard