nanog mailing list archives

Re: NANOG67 - Tipping point of community and sponsor bashing?


From: Eric Kuhnke <eric.kuhnke () gmail com>
Date: Thu, 16 Jun 2016 16:17:51 -0700

However: exchange port fees are not my biggest enemy today. My cross
connect fees have not gone down *at all*. On a proportion basis, cross
connect fees have gone from "not mattering" to being an important part of
any deployment cost calculation. Why aren't we raising hell about cross
connect fees?

IMHO we should be, in the spirit of:
https://en.wikipedia.org/wiki/Rent_Is_Too_Damn_High_Party

Assuming the existence of overhead fiber trays throughput, when you
consider the actual cost of a two strand XC between two cages in the same
facility:

30 meter SC-SC duplex 9/125 G.657.A1 cable: $11

There should be a community effort to lobby facility managers and colo/IX
real estate management that the value of their facility will be greater if
XCs are free or nearly free, resulting in higher occupancy and a greater
critical mass of carriers, rather than trying to extract revenue from the
tenants by $300/mo MRC per fiber pair between two racks.



On Thu, Jun 16, 2016 at 4:06 PM, Phil Rosenthal <pr () isprime com> wrote:

Hello all,

I wasn't able to attend NANOG this time around, but watched Dave Temkin's
presentation on youtube.

My comments are:
1) Over the past 5 years:
My cost for switch/router ports have gone down a lot.
My cost for transit has gone down a lot.
My cost for exchange ports have gone down, but not quite as fast as my
transit and switch/router ports, and this does lead to some value
questions. Dave is right to ask them.

However: exchange port fees are not my biggest enemy today. My cross
connect fees have not gone down *at all*. On a proportion basis, cross
connect fees have gone from "not mattering" to being an important part of
any deployment cost calculation. Why aren't we raising hell about cross
connect fees?

2) Exotic features -- Pvlan, L2VPN, L3VPN have absolutely no purpose on an
exchange. If it could be done 'free' with commodity hardware, then fine --
but if it translates to requiring Big Expensive Routers instead of a
cheaper but fast switch, this should translate to higher pricing for the
customers requiring these exotic features -- not the customers who just
want a big L2 vlan.

3) Remote peering -- This is mostly a question about distance for value.
There is a clear benefit in providing multi-datacenter exchanges within a
metro, and both FL-IX and SIX are doing this with a very good value
proposition. Having the ability to join DECIX Frankfurt from NYC and vice
versa -- again, this is a bizarre service to be offered, and regular users
should not be expected to pay for this. If there is a market for these
services at an unsubsidized price, then fine -- but regular members should
not be subsidizing this service.

4) sFlow -- I'm not sure why this is even really a topic. Commodity
hardware does have sFlow capability, and FLIX demonstrates this well. With
that said, for us, it is of extremely limited value. We might check these
graphs to validate measurements of our internal netflow/sflow graphing
systems, but generally, I look at the graphs generated by my exchange
vendors less than once per year per exchange. I am honestly not even sure
if SIX offers this service, as I never had a reason to check.

5) Marketting vs Outreach: These things are honestly basically the same
thing, mostly separated by the question of "is it good marketing or not". I
like having more members at the exchanges I am a member of. If it
translates to an additional 3% per year to have an additional 5% of traffic
to new members, I am fine with this.  If it translates to an extra 50% of
cost for 5% of additional traffic, I am not fine with it.

Finally -- there is nothing wrong with asking questions. If you are an
exchange company and you can defend your prices for what you offer, then
there is no problem.  If you are an exchange and are mostly just hoping
nobody asks the questions because you won't have any good answers -- well,
I think this is exactly why Dave asked the question.

Best Regards,
-Phil Rosenthal
On Jun 16, 2016, at 1:58 PM, Adam Rothschild <asr () latency net> wrote:

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.




Current thread: