Re: A case against vendor-locking optical modules

[Nick Hilliard <nick () foobar org>]

On 17/11/2014 18:11, Jérôme 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) ?

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.

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.  From 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.

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.

> Did you ever experience a shift in a vendor's position regarding the use
> of compatible modules ?

No, but I've never had the opportunity to wave $100m at a vendor either.

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.

Nick