[190174] in North American Network Operators' Group
Re: NANOG67 - Tipping point of community and sponsor bashing?
daemon@ATHENA.MIT.EDU (Mike Hammett)
Fri Jun 17 07:47:46 2016
X-Original-To: nanog@nanog.org
Date: Fri, 17 Jun 2016 06:45:26 -0500 (CDT)
From: Mike Hammett <nanog@ics-il.net>
Cc: nanog@nanog.org
In-Reply-To: <CAB69EHjGgNcnKVKHHo3zK_EguWRyxJQpEPkT8ArBNp2VLQ2kkg@mail.gmail.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
I think a similar point was made at NANOG. A distributed IX will let the ma=
rket dictate that. Places that are better for people to operate in will see=
a rise in customers and places that aren't won't.=20
-----=20
Mike Hammett=20
Intelligent Computing Solutions=20
http://www.ics-il.com=20
Midwest Internet Exchange=20
http://www.midwest-ix.com=20
----- Original Message -----
From: "Eric Kuhnke" <eric.kuhnke@gmail.com>=20
To: nanog@nanog.org=20
Sent: Thursday, June 16, 2016 6:17:51 PM=20
Subject: Re: NANOG67 - Tipping point of community and sponsor bashing?=20
> However: exchange port fees are not my biggest enemy today. My cross=20
connect fees have not gone down *at all*. On a proportion basis, cross=20
connect fees have gone from "not mattering" to being an important part of=
=20
any deployment cost calculation. Why aren't we raising hell about cross=20
connect fees?=20
IMHO we should be, in the spirit of:=20
https://en.wikipedia.org/wiki/Rent_Is_Too_Damn_High_Party=20
Assuming the existence of overhead fiber trays throughput, when you=20
consider the actual cost of a two strand XC between two cages in the same=
=20
facility:=20
30 meter SC-SC duplex 9/125 G.657.A1 cable: $11=20
There should be a community effort to lobby facility managers and colo/IX=
=20
real estate management that the value of their facility will be greater if=
=20
XCs are free or nearly free, resulting in higher occupancy and a greater=20
critical mass of carriers, rather than trying to extract revenue from the=
=20
tenants by $300/mo MRC per fiber pair between two racks.=20
On Thu, Jun 16, 2016 at 4:06 PM, Phil Rosenthal <pr@isprime.com> wrote:=20
> Hello all,=20
>=20
> I wasn't able to attend NANOG this time around, but watched Dave Temkin's=
=20
> presentation on youtube.=20
>=20
> My comments are:=20
> 1) Over the past 5 years:=20
> My cost for switch/router ports have gone down a lot.=20
> My cost for transit has gone down a lot.=20
> My cost for exchange ports have gone down, but not quite as fast as my=20
> transit and switch/router ports, and this does lead to some value=20
> questions. Dave is right to ask them.=20
>=20
> However: exchange port fees are not my biggest enemy today. My cross=20
> connect fees have not gone down *at all*. On a proportion basis, cross=20
> connect fees have gone from "not mattering" to being an important part of=
=20
> any deployment cost calculation. Why aren't we raising hell about cross=
=20
> connect fees?=20
>=20
> 2) Exotic features -- Pvlan, L2VPN, L3VPN have absolutely no purpose on a=
n=20
> exchange. If it could be done 'free' with commodity hardware, then fine -=
-=20
> but if it translates to requiring Big Expensive Routers instead of a=20
> cheaper but fast switch, this should translate to higher pricing for the=
=20
> customers requiring these exotic features -- not the customers who just=
=20
> want a big L2 vlan.=20
>=20
> 3) Remote peering -- This is mostly a question about distance for value.=
=20
> There is a clear benefit in providing multi-datacenter exchanges within a=
=20
> metro, and both FL-IX and SIX are doing this with a very good value=20
> proposition. Having the ability to join DECIX Frankfurt from NYC and vice=
=20
> versa -- again, this is a bizarre service to be offered, and regular user=
s=20
> should not be expected to pay for this. If there is a market for these=20
> services at an unsubsidized price, then fine -- but regular members shoul=
d=20
> not be subsidizing this service.=20
>=20
> 4) sFlow -- I'm not sure why this is even really a topic. Commodity=20
> hardware does have sFlow capability, and FLIX demonstrates this well. Wit=
h=20
> that said, for us, it is of extremely limited value. We might check these=
=20
> graphs to validate measurements of our internal netflow/sflow graphing=20
> systems, but generally, I look at the graphs generated by my exchange=20
> vendors less than once per year per exchange. I am honestly not even sure=
=20
> if SIX offers this service, as I never had a reason to check.=20
>=20
> 5) Marketting vs Outreach: These things are honestly basically the same=
=20
> thing, mostly separated by the question of "is it good marketing or not".=
I=20
> like having more members at the exchanges I am a member of. If it=20
> translates to an additional 3% per year to have an additional 5% of traff=
ic=20
> to new members, I am fine with this. If it translates to an extra 50% of=
=20
> cost for 5% of additional traffic, I am not fine with it.=20
>=20
> Finally -- there is nothing wrong with asking questions. If you are an=20
> exchange company and you can defend your prices for what you offer, then=
=20
> there is no problem. If you are an exchange and are mostly just hoping=20
> nobody asks the questions because you won't have any good answers -- well=
,=20
> I think this is exactly why Dave asked the question.=20
>=20
> Best Regards,=20
> -Phil Rosenthal=20
> > On Jun 16, 2016, at 1:58 PM, Adam Rothschild <asr@latency.net> wrote:=
=20
> >=20
> > I think a fresh conversation is needed around what makes up a=20
> > "minimally viable" feature set for an IXP:=20
> >=20
> > The days of an IXP "needing" to engineer and support a multi-tenant=20
> > sFlow portal, because the only other option is shelling out the big=20
> > bucks for Arbor, have long passed -- overlooking the plethora of open=
=20
> > sourced tools, folk like Kentik have broken into that market with=20
> > rationally priced commercial alternatives. Likewise, one might argue=20
> > that offering layer-2 and layer-3 (!) VPNs is at best non-essential,=20
> > and a distraction that fuels purchasing very expensive hardware, and=20
> > at worse competitive with customers.=20
> >=20
> > On the other hand, building out a metro topology to cover all relevant=
=20
> > carrier hotels, with reasonable path diversity, is absolutely table=20
> > stakes. And outreach is a great function, *when* it nets unique new=20
> > participants. To cite a recent example, the various R&E networks and=20
> > smaller broadband and mobile providers showing up here in the US, due=
=20
> > to excellent efforts by the NYIIX and DE-CIX teams.=20
> >=20
> > At the end of the day, IXP peering must be significantly cheaper than=
=20
> > transit alternatives, many of which are priced based on utilization=20
> > (as opposed to port capacity). We can dance around this point all we=20
> > want, but absent a change in trajectory, I worry some IXPs will=20
> > ultimately price themselves out of the market, and all the gold-plated=
=20
> > features in the world won't satiate those making purchasing decisions.=
=20
> >=20
> > $0.02,=20
> > -a=20
> >=20
> > On Thu, Jun 16, 2016 at 11:17 AM, Niels Bakker <niels=3Dnanog@bakker.ne=
t>=20
> wrote:=20
> >> * zbynek@dialtelecom.cz (Zbyn=C4=9Bk Posp=C3=ADchal) [Thu 16 Jun 2016,=
14:23=20
> CEST]:=20
> >>>=20
> >>> Dne 15.06.16 v 20:10 Mikael Abrahamsson napsal(a):=20
> >>>=20
> >>>> Well, the customers also wanted more functions and features. They=20
> wanted=20
> >>>> sFLOW statistics to show traffic, customer portals, better SLAs,=20
> distributed=20
> >>>> IXes, remote peering, more hand-holding when connecting etc.=20
> >>>=20
> >>>=20
> >>> Are you sure they still want them if they have to pay for these=20
> features=20
> >>> separately?=20
> >>>=20
> >>> Currently, such luxury functions are increasing costs also for networ=
ks=20
> >>> who don't need/want it.=20
> >>=20
> >>=20
> >> sFlow statistics isn't a luxury function. Neither is remote peering.=
=20
> The=20
> >> others Mikael mentioned are debatable at worst but you'd be telling th=
e=20
> >> membership what they really want rather than listening to them saying=
=20
> what=20
> >> they want.=20
> >>=20
> >> This thread is full of people who have never run large L2 networks=20
> stating=20
> >> their opinions on running large L2 networks, and they invariably=20
> >> underestimate their complexity and the logistics required.=20
> >>=20
> >>=20
> >> -- Niels.=20
>=20
>=20
