Can an IXP sell traffic?
This is a rhetorical question.
I know that it can… In fact, it is obvious that it can.
It is quite common to see several companies buying and selling traffic through IXPs.
But whenever I have been involved with more serious companies, it was common for this type of traffic to be over a Bilateral VLAN between the Downstream and Upstream, and the ASs involved were from the operations themselves (different from the ASN used by Route-Servers).
But I have seen a reasonably large scenario in which the IXP operator, maintaining the MLPA LAN with the pair of Route-Servers, adds another participant with the SAME ASN as the route-servers, and through this participant starts to sell traffic.
This seemed very strange to me!
And that is why I came to ask if this is correct or not.
I would appreciate any guidance on the subject.
In fact, there were other aggravating factors that worried me:
The IXP activation information itself (VLAN, IPv4/IPv6, Route-Servers, etc.) was indistinguishable from the information in the transit BGP session. And the extra Billing information for anything sent by the transit was not explicit.
The routes reported exchanged by this transit had the ASN transparency function in the AS-Path.
Of course they can sell transit. The reason they don't is that it has
the potential to create a conflict of interest. When your customer is
also a competitor and your customer suffers an outage that's your
fault... Well, you see where this is going.
Over the coming years, I expect exchange points to do some strangely interesting things, as the towel of revenue continues to get tighter and tighter to squeeze. Especially so if a few of the large content providers continue to pull back from route servers and such. Mark.
Yep. Other-Bill has this exactly right. To add a little to that, for an IXP to be successful, many ISPs have to trust it enough to build out to it and participate in it, which requires investment on their parts. To be trustworthy, it helps a _lot_ if the IXP is “neutral.” That is, it’s not a part of your competitor, and you have reason to believe that if you invest in it now, it won’t treat you unfairly in the future.
So, to succeed, it helps a _lot_ if IXP have very simple, unitary models. They don’t do other things which makes them complicated, opaque, hard-to-understand, hard-to-trust. Just not handling money at all is a huge win for IXP stability and growth, for instance, because it simplifies things and makes them more easily trusted.
Selling transit is a thing that ISPs do. When an IXP competes with its ISP participants, it not only sets itself up for the conflicts and failures that Bill points out, it also makes itself less trustworthy, because of the _future risk_ of those conflicts and failures, and that decreased trustworthiness decreases “investor confidence” and ISP willingness to extend themselves, and that, in turn, causes the IXP to not grow, or grow more slowly than it would otherwise.
Over the coming years, I expect exchange points to do some strangely interesting things, as the towel of revenue continues to get tighter and tighter to squeeze.
Especially so if a few of the large content providers continue to pull back from route servers and such.
Content providers aren’t leaving IXP’s completely. They’re still there, still paying monthly for ports and XCs. Still doing bilateral peering over the IX. There’s no revenue hit to an IXP for a CDN to de-peer off the route servers.
UK, and London in particular, is quite a dynamic market. At LONAP we see plenty of networks connect and see an immediate “quick win” of traffic by connection to our route-servers, where adoption among the membership is something like 85-90%.
If an operator decides to replace those RS sessions with a (often intractable) portal to request bilateral sessions - or worse, email - that immediate traffic benefit is lost. That can affect the value the IXP provides to its members.
The paradigm shift happening in the content/cloud space is that the "quick win value" eyeball networks enjoy from peering with the route server to reach them does not appear to continue to be worth the admin. effort for said content/cloud folk.
Not sure how or if adding a portal layer makes that easier for them to manage.
But of course, there is the real issue that continuously upgrading clusters that serve exchange points across most of the exchange points around the world is a task that might have been underestimated, after all.
* mark@tinka.africa (Mark Tinka) [Thu 07 Nov 2024, 19:25 CET]:
The paradigm shift happening in the content/cloud space is that the "quick win value" eyeball networks enjoy from peering with the route server to reach them does not appear to continue to be worth the admin. effort for said content/cloud folk.
You almost can't have lower effort peering than via an IXP's route server. Most of them these days are well run with IRR-based filtering and RPKI OV.
You almost can't have lower effort peering than via an IXP's route
server. Most of them these days are well run with IRR-based filtering
and RPKI OV.
i used to resist. my instinct is that the data plane and the control
plane should be congruent or you can have hard to debug issues[0].
but, as i have gotten older and lazier, and as you say, route servers
have gotten quite reliable, i have come over to the route server side.
I don’t think there is any satisfactory argument that can be made for wanting to avoid route server routing. For the content/cloud folk, I think avoiding it provides a mechanism via which they can screen for the utility of having to keep an exchange point node upgraded and optimized for service. Mark.
I don’t think there is any satisfactory argument that can be made for wanting to avoid route server routing. For the content/cloud folk, I think avoiding it provides a mechanism via which they can screen for the utility of having to keep an exchange point node upgraded and optimized for service.
Plenty of eyeball networks will announce prefixes differently via a bilateral session vs a route server session vs DFZ, then come yelling because traffic isn’t going the way they expected it to. There can be times that the administrative overhead of dealing with those folks far outweighs any financial or performance benefits.
Route servers are generally useful, but can be a royal pain in the ass too, depending on how they’re used.
Please verify you are emailing the correct person. I have no idea how this thread relates to a domain name transfer but I highly recommend verifying the recipient of your emails to make sure they go to the right place.
| Domain awaiting transfer initiation |