I think a fresh conversation is needed around what makes up a "minimally viable" feature set for an IXP: The days of an IXP "needing" to engineer and support a multi-tenant sFlow portal, because the only other option is shelling out the big bucks for Arbor, have long passed -- overlooking the plethora of open sourced tools, folk like Kentik have broken into that market with rationally priced commercial alternatives. Likewise, one might argue that offering layer-2 and layer-3 (!) VPNs is at best non-essential, and a distraction that fuels purchasing very expensive hardware, and at worse competitive with customers. On the other hand, building out a metro topology to cover all relevant carrier hotels, with reasonable path diversity, is absolutely table stakes. And outreach is a great function, *when* it nets unique new participants. To cite a recent example, the various R&E networks and smaller broadband and mobile providers showing up here in the US, due to excellent efforts by the NYIIX and DE-CIX teams. At the end of the day, IXP peering must be significantly cheaper than transit alternatives, many of which are priced based on utilization (as opposed to port capacity). We can dance around this point all we want, but absent a change in trajectory, I worry some IXPs will ultimately price themselves out of the market, and all the gold-plated features in the world won't satiate those making purchasing decisions. $0.02, -a On Thu, Jun 16, 2016 at 11:17 AM, Niels Bakker <niels=nanog@bakker.net> wrote:
* zbynek@dialtelecom.cz (Zbyněk Pospíchal) [Thu 16 Jun 2016, 14:23 CEST]:
Dne 15.06.16 v 20:10 Mikael Abrahamsson napsal(a):
Well, the customers also wanted more functions and features. They wanted sFLOW statistics to show traffic, customer portals, better SLAs, distributed IXes, remote peering, more hand-holding when connecting etc.
Are you sure they still want them if they have to pay for these features separately?
Currently, such luxury functions are increasing costs also for networks who don't need/want it.
sFlow statistics isn't a luxury function. Neither is remote peering. The others Mikael mentioned are debatable at worst but you'd be telling the membership what they really want rather than listening to them saying what they want.
This thread is full of people who have never run large L2 networks stating their opinions on running large L2 networks, and they invariably underestimate their complexity and the logistics required.
-- Niels.