[190157] in North American Network Operators' Group
Re: NANOG67 - Tipping point of community and sponsor bashing?
daemon@ATHENA.MIT.EDU (Phil Rosenthal)
Thu Jun 16 19:06:40 2016
X-Original-To: nanog@nanog.org
From: Phil Rosenthal <pr@isprime.com>
In-Reply-To: <CAPZUUwWxjQK4oWcY2wSM6WwO4FdTK6Vbu25PKvX7_e6ooruOuQ@mail.gmail.com>
Date: Thu, 16 Jun 2016 19:06:33 -0400
To: Adam Rothschild <asr@latency.net>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
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:
>=20
> I think a fresh conversation is needed around what makes up a
> "minimally viable" feature set for an IXP:
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> $0.02,
> -a
>=20
> On Thu, Jun 16, 2016 at 11:17 AM, Niels Bakker =
<niels=3Dnanog@bakker.net> wrote:
>> * zbynek@dialtelecom.cz (Zbyn=C4=9Bk Posp=C3=ADchal) [Thu 16 Jun =
2016, 14:23 CEST]:
>>>=20
>>> Dne 15.06.16 v 20:10 Mikael Abrahamsson napsal(a):
>>>=20
>>>> 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.
>>>=20
>>>=20
>>> Are you sure they still want them if they have to pay for these =
features
>>> separately?
>>>=20
>>> Currently, such luxury functions are increasing costs also for =
networks
>>> who don't need/want it.
>>=20
>>=20
>> 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.
>>=20
>> 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.
>>=20
>>=20
>> -- Niels.
