[176178] in North American Network Operators' Group
Re: A case against vendor-locking optical modules
daemon@ATHENA.MIT.EDU (Patrick W. Gilmore)
Mon Nov 17 18:19:38 2014
X-Original-To: nanog@nanog.org
From: "Patrick W. Gilmore" <patrick@ianai.net>
In-Reply-To: <546A6674.3080407@foobar.org>
Date: Mon, 17 Nov 2014 18:17:27 -0500
To: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
This is an interesting thread, but the actual winning strategy was only =
tangentially mentioned.
Q: How do you get a vendor to change?
A: Everyone stop buying that vendor's gear.
It's a simple business decision. If the profit dollars of the people who =
stick around with locked optics are greater than the profit dollars of =
everyone buying without, guess what a vendor will do? (I'm ignoring a =
ton of second-order effects, such as having enough kit in production to =
be considered ubiquitous, since most companies can't think that far =
ahead.)
You like Arista for price, density, etc.? Then factor in the cost (OpEx =
& CapEx) of vendor-specific optics and see if they still make sense. =
Don't just look at the per-port cost of the blade. See, it's a simple =
business decision for you too.
Besides, what's wrong with using something (as Nick mentioned) like =
FlexOptics programmable optics? Haven't tried it in Arista, but other =
kit works fine.
--=20
TTFN,
patrick
> On Nov 17, 2014, at 16:19 , Nick Hilliard <nick@foobar.org> wrote:
>=20
> On 17/11/2014 18:11, J=C3=A9r=C3=B4me Nicolle wrote:
>> What are other arguments against vendor lock-in ? Is there any =
argument
>> FOR such locks (please spare me the support issues, if you can't read
>> specs and SNMP, you shouldn't even try networking) ?
>=20
> there have been documented cases in the past where transceivers have =
had
> serious problems working on kit, where those problems have ranged from =
the
> transceivers simply not working correctly to the network devices =
crashing
> and rebooting. The kit vendor gets the blame in all situations, even
> though it's not always their fault.
>=20
> Ultimately, transceivers are devices which need device drivers to work
> properly. I haven't seen any driver code for handling them, but if =
you
> take a look at any other device driver, you'll probably notice that a =
good
> chunk of the code is spend dealing with quirks and device-specific
> weirdness. =46rom talking to vendors, I understand that the situation =
is
> much the same with optical transceivers. So there are some technical
> reasons for being cautious about this, particular at the early stage =
of
> transceiver development.
>=20
> Having said that, most vendors use transceiver lock-out for strictly
> commercial purposes and will refuse to enable full functionality on =
third
> party kit as a matter of policy. Bear it in mind that for every =
customer
> who doesn't accept this, the vendor will make 10x as much cash with =
this
> policy by applying it to enterprise and public sector.
>=20
>> Did you ever experience a shift in a vendor's position regarding the =
use
>> of compatible modules ?
>=20
> No, but I've never had the opportunity to wave $100m at a vendor =
either.
>=20
> These days I buy blank transceivers from a reputable third party =
vendor,
> and recode them in-house as appropriate for whatever kit we need to =
use
> them in. This works well for me, but other people will have different
> policies which work well for them.
>=20
> Nick
