> But what impacts does this have on performance? Great we solved hijacking issue. But this other ASN which used to be a preferred route doesn’t use ROA/ROV (yet or refuses).
No performance impact: a routing table is a very (ahaha) binary thing, it takes a destination address and does a longest prefix match search in a table to find the next hop interface, to which it routes the packet.
Route validity is considered (alongside a bunch of other routing policy inputs) when constructing the table, not when a packet arrives.
The purported performance hit wouldn't be from the propagation delay on any given router, but rather from shifts in traffic resulting in a longer path.
In practice, I suspect there will be very little impact for most traffic, since typical aspath lengths are, like, 2. (Mostly, direct peering between CDNs and ISPs if the data isn't cached within the ISP network to begin with)
edit for source:
> The average AS path length in a well-developed content network is about 1. Maybe 1.1.
> The purported performance hit wouldn't be from the propagation delay on any given router, but rather from shifts in traffic resulting in a longer path.
You are right, I neglected to point out that origin validation is (in the absence of shenanigans) not going to cause one path to be preferable to another: if the origin is the same AS, either both paths or neither is valid.
If the origin in two paths is two different ASes, either both are valid or shenanigans are afoot - perhaps there's a hijack being prevented, perhaps the network operator has screwed up their ROAs, perhaps the network operator is measuring sBGP uptake, perhaps the network operator is doing a rather bizarre and ineffectual form of traffic ingress management, or perhaps the network is in a transition from one AS to another, but those are all "shenanigans" in which routing efficiency is secondary to some other goal.
An alternative source for average BGP path length is https://blog.apnic.net/2024/01/10/bgp-in-2023-bgp-updates/ - where many other similar statistics can be found, and independently repeatable methodology is available. The average BGP path length for IPv4 is around 5.5 hops, and for IPv6 it is just shy of 5 hops. These numbers have been stable for a while with IPv4 slowly shrinking and IPv6 slowly growing, albeit in both cases by around 0.2 hops a decade.
And perhaps also relevant to the parent's question: path length itself is a pretty poor indicator of network performance by just about any measure you can name (excepting perhaps the TTL field), and is a last resort measure used only when all else is equal. The case of a prefix hijack being thwarted by origin validation is an extreme example in which the shorter (invalid) path represents 100% packet loss and the longer (valid) path given preference due to origin validation is infinitely more performant.
edit: oh, disclaimer - I am a co-author of one of the RPKI RFCs, and while I am personally not involved in secure BGP at present my employer definitely is. Opinions presented are mine.
You're certainly not wrong here -- it all depends what you're measuring and how. The 5-5.5 figure seems to be average length inside the internet routing tables, which is going to be skewed by smaller networks with relatively sparse connectivity and how IP space is carved up geographically.
> And perhaps also relevant to the parent's question: path length itself is a pretty poor indicator of network performance by just about any measure you can name (excepting perhaps the TTL field), and is a last resort measure used only when all else is equal.
Perhaps I focused the conversation in the wrong direction by mentioning AS path (and then further by describing the AS path between CDNs and end-users and framing that as "typical"). For a major CDN, most of the bytes served are originating from and destined to the same metro. Unless those CDNs have some serious problems with their RPKI setups, I expect that those bytes are going to continue flowing the same way they have been.
Average AS Path being about 1 isn't right. For direct peer CDN content sure Even AWS has their own path that's at least 2 from GTT, Areilon, NTT, etc from wherever you connect. if you are at a data center and use blended IP Transit that's another ASN to add to the path RIPE report had the average at 3-4 in 2012.
Path length is dependent on where you stand and look at it all, of course.
If anyone knows of a place in which a border router is only one (or 1.1 average) hop away from every other network on the planet, please let me know what real estate prices are like there, though.
(I suspect the 1.1 figure measures something quite different - the average path length inside a CDN or similar, which probably should be closer to one but might involve sneaky things like an overlay network).
I would wager the 1.1 figure is "average path length from CDN to end user", and quite possibly weighted by bytes served.
Most of the major players in the space (Netflix, Akamai, YouTube, Facebook, etc) have boxes inside ISP networks across major metros, so the path length to reach those ISPs' users is in fact 1 assuming a cache hit, and the RTT is certainly less than 20ms.
No performance impact: a routing table is a very (ahaha) binary thing, it takes a destination address and does a longest prefix match search in a table to find the next hop interface, to which it routes the packet.
Route validity is considered (alongside a bunch of other routing policy inputs) when constructing the table, not when a packet arrives.