A case against vendor-locking optical modules
Hello, I'm having a discussion with Arista, trying to explain to them why I _can't_ buy any hardware unable to run with compatible optical modules. My points are : - I need specific modules, mostly *WDM and BiDi, some still unavailable in their product line - I run at least two other vendors on every locations and can't stack up every spare optics for each of them, neither could remote-hands safely re-program optics to match a specific vendor when needed. - I have an established relationship with a trusted optics supplier, providing support, warranty and re-coding hardware for their entire (impressive) lineup. And this supplier is still 2-5x times cheaper than any vendor-labeled optics even with NFR-like discounts. Based on these points, I discourage every customers of ever using locked-in equipments, and forbid them on my own network. Of course, Arista can't be pleased because their hardware never stepped chord in my customer's networks. But they seem to deliberatly miss my points every time the subject comes up. 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) ? Did you ever experience a shift in a vendor's position regarding the use of compatible modules ? Thanks ! -- Jérôme Nicolle +33 6 19 31 27 14
Let talk about the 800 pound gorilla in the room and the #1 reason to hate vendor locked optics. Some vendors (yes, Cisco I'm looking at you) want to charge ridiculously high prices for optic that are identical to generic optics other than the vendor lock. Maybe a better tactic would be to have the vendor explain to you why the vendor lock is necessary. You are after all the customer and don't owe them any explanations. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Jérôme Nicolle Sent: Monday, November 17, 2014 12:12 PM To: nanog@nanog.org Subject: A case against vendor-locking optical modules Hello, I'm having a discussion with Arista, trying to explain to them why I _can't_ buy any hardware unable to run with compatible optical modules. My points are : - I need specific modules, mostly *WDM and BiDi, some still unavailable in their product line - I run at least two other vendors on every locations and can't stack up every spare optics for each of them, neither could remote-hands safely re-program optics to match a specific vendor when needed. - I have an established relationship with a trusted optics supplier, providing support, warranty and re-coding hardware for their entire (impressive) lineup. And this supplier is still 2-5x times cheaper than any vendor-labeled optics even with NFR-like discounts. Based on these points, I discourage every customers of ever using locked-in equipments, and forbid them on my own network. Of course, Arista can't be pleased because their hardware never stepped chord in my customer's networks. But they seem to deliberatly miss my points every time the subject comes up. 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) ? Did you ever experience a shift in a vendor's position regarding the use of compatible modules ? Thanks ! -- Jérôme Nicolle +33 6 19 31 27 14
Vendor Lock's... this is nothing new, it has been in practice since the beginning of the IT / Computer Industry... We have seen this with Cables (old old days, Vax/PDP 11/ IBM Mainframes, well into the PC cycle), Floppy Drives, Hard Drivers etc etc etc... To the best of my knowledge, none of this was ever won by argument with the vendor...This always changed with time... When more and more people started deploying generic / non oem items, the vendors were forced to either turn a blind eye or forced to reconsider... The big carrot or stick, the vendors always held with the Customers / Consumers, was the warranty and or support. If history has any advice to offer, it would be, if you are not dependent on warranty or support issues from the Vendor, then go forward, do what you please, .. :) Regards. Faisal Imtiaz ----- Original Message -----
From: "Steve Naslund" <SNaslund@medline.com> To: nanog@nanog.org Sent: Monday, November 17, 2014 1:20:09 PM Subject: RE: A case against vendor-locking optical modules
Let talk about the 800 pound gorilla in the room and the #1 reason to hate vendor locked optics. Some vendors (yes, Cisco I'm looking at you) want to charge ridiculously high prices for optic that are identical to generic optics other than the vendor lock. Maybe a better tactic would be to have the vendor explain to you why the vendor lock is necessary. You are after all the customer and don't owe them any explanations.
Steven Naslund Chicago IL
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Jérôme Nicolle Sent: Monday, November 17, 2014 12:12 PM To: nanog@nanog.org Subject: A case against vendor-locking optical modules
Hello,
I'm having a discussion with Arista, trying to explain to them why I _can't_ buy any hardware unable to run with compatible optical modules.
My points are :
- I need specific modules, mostly *WDM and BiDi, some still unavailable in their product line
- I run at least two other vendors on every locations and can't stack up every spare optics for each of them, neither could remote-hands safely re-program optics to match a specific vendor when needed.
- I have an established relationship with a trusted optics supplier, providing support, warranty and re-coding hardware for their entire (impressive) lineup. And this supplier is still 2-5x times cheaper than any vendor-labeled optics even with NFR-like discounts.
Based on these points, I discourage every customers of ever using locked-in equipments, and forbid them on my own network. Of course, Arista can't be pleased because their hardware never stepped chord in my customer's networks. But they seem to deliberatly miss my points every time the subject comes up.
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) ?
Did you ever experience a shift in a vendor's position regarding the use of compatible modules ?
Thanks !
-- Jérôme Nicolle +33 6 19 31 27 14
Le 17/11/2014 19:28, Faisal Imtiaz a écrit :
If history has any advice to offer, it would be, if you are not dependent on warranty or support issues from the Vendor, then go forward, do what you please, ..
Well, I could go on and re-code the optics, at least by simply cloning a few OEMs. But there is still the spare items issue. No datacenter remote-hands will accept any lyability in operating a recoder (wich, when not operated properly, can easily fry the module). So I have to keep multiple spares per module type, each beeing recoded and labelled for different vendors. Le 17/11/2014 19:54, William Herrin a écrit :
Change "can't" to "won't", because you find it inconvenient and insulting to work around artificial and costly problems created by your vendor. If you can't use their equipment then they haven't lost any business but if you _won't_ then they have.
Let's talk about the £800 gorilla in the room then : it's not an issue for a $20 LX SFP, it may be doable for a $120 LR SFP+, it's certainly not an option for an ER-DWDM SFP+ 8-40 waves set ($800 each). You're right about how inconvinient and insulting such restrictions feel, but my main concern is about costs, efficiency and logistics. Having to stock more spare optics, one per vendor, has its cost. Having to cheat the restriction by recoding the optics, also has costs in terms of time, tools and complexity. At the end of the day, everyone loses. Because it's absurd and induce more costs and complexity, I _can't_ fall into such trap. Because it's insulting and bordeline moronic to begin with, I certainly _won't_. Now, about discussing with a CEO, I'm not really sure it could be reached. Salesmen on the other hand have their own interest in both selling OEM modules to the corporate market, and unlocked equipments to the SP/telco market, to whom they won't sell anything otherwise. Is it unrealistic to hope for enough salesmen pressure on the corporate ladder to make such moronic attitude be reversed in the short term ? Best regards, -- Jérôme Nicolle +33 6 19 31 27 14
On Mon, Nov 17, 2014 at 2:12 PM, Jérôme Nicolle <jerome@ceriz.fr> wrote:
Le 17/11/2014 19:54, William Herrin a écrit :
Change "can't" to "won't", because you find it inconvenient and insulting to work around artificial and costly problems created by your vendor. If you can't use their equipment then they haven't lost any business but if you _won't_ then they have.
Let's talk about the £800 gorilla in the room then : it's not an issue for a $20 LX SFP, it may be doable for a $120 LR SFP+, it's certainly not an option for an ER-DWDM SFP+ 8-40 waves set ($800 each).
You're right about how inconvinient and insulting such restrictions feel, but my main concern is about costs, efficiency and logistics.
Having to stock more spare optics, one per vendor, has its cost. Having to cheat the restriction by recoding the optics, also has costs in terms of time, tools and complexity. At the end of the day, everyone loses.
Because it's absurd and induce more costs and complexity, I _can't_ fall into such trap. Because it's insulting and bordeline moronic to begin with, I certainly _won't_.
Have they had a bad quarter because they carelessly induced indirect costs which priced them out of the market? This is something their CEO would like to know about.
Now, about discussing with a CEO, I'm not really sure it could be reached. Salesmen on the other hand have their own interest in both selling OEM modules to the corporate market, and unlocked equipments to the SP/telco market, to whom they won't sell anything otherwise.
You'd be surprised how reachable CEOs are, but if you have any trouble making an appointment, call the CFO instead. CFO's are lonely. Almost nobody ever calls them. The CFO will take the call from a customer/investor, and unlike your salesman the CFO has the CEO's ear. And if he's had a bad quarter, the CFO is even more in tune with the idea that an indirect cost (which makes them no direct money) caused you not to buy.
Is it unrealistic to hope for enough salesmen pressure on the corporate ladder to make such moronic attitude be reversed in the short term ?
Your salesman is not a corporate warrior. He spends his time working the lowest hanging fruit he can find. Unless you have a *lot* of money to spend, that isn't a customer who requires a change to corporate policy. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/> May I solve your unusual networking challenges?
On Mon, 17 Nov 2014, Jérôme Nicolle wrote:
Is it unrealistic to hope for enough salesmen pressure on the corporate ladder to make such moronic attitude be reversed in the short term ?
No salesperson is likely to do that for you. They know only to well that eliminating vendor lock-in means they will lose sales on artificially costly optics from $vendor to a lower-cost rival. Less sales = less commission for the affected sales person. jms
On Mon, 17 Nov 2014 15:34:50 -0500, "Justin M. Streiner" said:
No salesperson is likely to do that for you. They know only to well that eliminating vendor lock-in means they will lose sales on artificially costly optics from $vendor to a lower-cost rival. Less sales = less commission for the affected sales person.
I suspect that losing the commission on a few $6digit chassis sales is worse than losing the commission on a $3digit optic?
On Mon, 17 Nov 2014, Valdis.Kletnieks@vt.edu wrote:
On Mon, 17 Nov 2014 15:34:50 -0500, "Justin M. Streiner" said:
No salesperson is likely to do that for you. They know only to well that eliminating vendor lock-in means they will lose sales on artificially costly optics from $vendor to a lower-cost rival. Less sales = less commission for the affected sales person.
I suspect that losing the commission on a few $6digit chassis sales is worse than losing the commission on a $3digit optic?
That turns into a forest > trees problem. Many salescritters don't think about the larger picture, or the responsible business units don't care about what affects other business units. Also, in the 10G-and-up world, most of those optics are a lot more than $3digits. jms
On Nov 17, 2014, at 12:34 PM, Justin M. Streiner <streiner@cluebyfour.org> wrote:
On Mon, 17 Nov 2014, Jérôme Nicolle wrote:
Is it unrealistic to hope for enough salesmen pressure on the corporate ladder to make such moronic attitude be reversed in the short term ?
No salesperson is likely to do that for you. They know only to well that eliminating vendor lock-in means they will lose sales on artificially costly optics from $vendor to a lower-cost rival. Less sales = less commission for the affected sales person.
jms
Which is why there is NO Arista gear in my network… They lose sales of costly routers as well as optics to any customer who doesn’t want to promote this behavior. It boils down to how much you want to tolerate/support/encourage this behavior. If you feel strongly like I do that such behavior is aberrant and should be strongly discouraged, then vote with your $$$ and don’t buy from vendors that do that. Let your vendors that you don’t buy from know why they lost the sale. I’ve found that showing a vendor a price-redacted copy of the PO to the other vendor can often lead to changes in the way they approach the next sales cycle. Owen
On Mon, 17 Nov 2014, Naslund, Steve wrote:
Let talk about the 800 pound gorilla in the room and the #1 reason to hate vendor locked optics. Some vendors (yes, Cisco I'm looking at you) want to charge ridiculously high prices for optic that are identical to generic optics other than the vendor lock. Maybe a better tactic would be to have the vendor explain to you why the vendor lock is necessary. You are after all the customer and don't owe them any explanations.
The Packetpushers recently discussed this issue: http://packetpushers.net/ps-show-35-oem-sfp-qsfp-modules-work/ Jethro. . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks, Network Manager, Information Services Directorate, University Of Strathclyde, Glasgow, UK The University of Strathclyde is a charitable body, registered in Scotland, number SC015263.
Hello, TheWorldMainBusinessRule says: "Don't work with morons!!!" Never. In any way. Even if it seems for the first look they give you prices and offers times better than normal people. Just don't even think. :) On 17.11.14 20:11, Jérôme Nicolle wrote:
Hello,
I'm having a discussion with Arista, trying to explain to them why I _can't_ buy any hardware unable to run with compatible optical modules.
My points are :
- I need specific modules, mostly *WDM and BiDi, some still unavailable in their product line
- I run at least two other vendors on every locations and can't stack up every spare optics for each of them, neither could remote-hands safely re-program optics to match a specific vendor when needed.
- I have an established relationship with a trusted optics supplier, providing support, warranty and re-coding hardware for their entire (impressive) lineup. And this supplier is still 2-5x times cheaper than any vendor-labeled optics even with NFR-like discounts.
Based on these points, I discourage every customers of ever using locked-in equipments, and forbid them on my own network. Of course, Arista can't be pleased because their hardware never stepped chord in my customer's networks. But they seem to deliberatly miss my points every time the subject comes up.
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) ?
Did you ever experience a shift in a vendor's position regarding the use of compatible modules ?
Thanks !
If they really wanted to lock you in, they would have triangular modules instead of square... Or I suppose the vendors like to be able to shop around for modules, before they relabel and sell them to you at a 10x markup.
They want the ability to buy off the shelf components when they manufacture. They just don't want you to have the same privilege when you purchase. Your switches and routers are made of a bunch of OEM components with some custom programmed ASICS and some secret sauce. If they used non standard interface specs their costs would go through the roof as their power supplies, memory, storage, and NICS would be all custom development. Steven Naslund Chicago IL
On Nov 18, 2014, at 12:42 PM, "Baldur Norddahl" <baldur.norddahl@gmail.com> wrote:
If they really wanted to lock you in, they would have triangular modules instead of square...
Or I suppose the vendors like to be able to shop around for modules, before they relabel and sell them to you at a 10x markup.
I've found the best method of dealing with vendors like this is to treat them the same way they treat you. If they won't listen to technical arguments and act like stubborn children, then I act the same way. Threaten to take your ball and go home. Or buy everything used or from grey market vendors. It works pretty well. The vendor/client relationship is a two-way street, and they should be reminded of that. Especially when dealing with commodity whitebox switch vendors like Arista...who can easily be replaced with another whitebox switch vendor and $networkOS. -richard On Tue, Nov 18, 2014 at 7:05 PM, Naslund, Steve <SNaslund@medline.com> wrote:
They want the ability to buy off the shelf components when they manufacture. They just don't want you to have the same privilege when you purchase. Your switches and routers are made of a bunch of OEM components with some custom programmed ASICS and some secret sauce. If they used non standard interface specs their costs would go through the roof as their power supplies, memory, storage, and NICS would be all custom development.
Steven Naslund Chicago IL
On Nov 18, 2014, at 12:42 PM, "Baldur Norddahl" < baldur.norddahl@gmail.com> wrote:
If they really wanted to lock you in, they would have triangular modules instead of square...
Or I suppose the vendors like to be able to shop around for modules, before they relabel and sell them to you at a 10x markup.
On Mon, Nov 17, 2014 at 1:11 PM, Jérôme Nicolle <jerome@ceriz.fr> wrote:
I'm having a discussion with Arista, trying to explain to them why I _can't_ buy any hardware unable to run with compatible optical modules.
Hi Jérôme, Change "can't" to "won't", because you find it inconvenient and insulting to work around artificial and costly problems created by your vendor. If you can't use their equipment then they haven't lost any business but if you _won't_ then they have. Then schedule a call with the CEO, not your salesman. The CEO probably doesn't understand it, probably caused it, and probably won't understand it when you're done talking. He will understand "customer ditching us over some subordinate's stupid behavior," and will assign someone more technical with instructions to redress the error. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/> May I solve your unusual networking challenges?
You say lock in, they say loyalty.... Tell them loyalty is two ways, and you need them to help you remain a loyal customer. To start with, a fantastic CLA. Make sure it includes 15 minute new optics delivery in case of failure (since you can't keep spares on-site as they are too expensive.) Technicians available without wait time to help you focus/finish/program them. Not instant response to take a ticket, followed by a call within 4 hours, but instant response by a knowledgeable tech who finishes the call by filling out a ticket. Etc. If they want vendor focused thinking on your part with concomitant committing of resources ($$), they need customer focused thinking on theirs. They want your loyalty, awesome... let them know what it will take. Remind them of how much money you will spend this year if they can get your lock in. I'm just singing here. --p -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Jérôme Nicolle Sent: Monday, November 17, 2014 12:12 PM To: nanog@nanog.org Subject: [EXTERNAL]A case against vendor-locking optical modules Hello, I'm having a discussion with Arista, trying to explain to them why I _can't_ buy any hardware unable to run with compatible optical modules. My points are : - I need specific modules, mostly *WDM and BiDi, some still unavailable in their product line - I run at least two other vendors on every locations and can't stack up every spare optics for each of them, neither could remote-hands safely re-program optics to match a specific vendor when needed. - I have an established relationship with a trusted optics supplier, providing support, warranty and re-coding hardware for their entire (impressive) lineup. And this supplier is still 2-5x times cheaper than any vendor-labeled optics even with NFR-like discounts. Based on these points, I discourage every customers of ever using locked-in equipments, and forbid them on my own network. Of course, Arista can't be pleased because their hardware never stepped chord in my customer's networks. But they seem to deliberatly miss my points every time the subject comes up. 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) ? Did you ever experience a shift in a vendor's position regarding the use of compatible modules ? Thanks ! -- Jérôme Nicolle +33 6 19 31 27 14
I've asked the same question and got the answer that there is a REAL BIG chip manufacture that was having huge system issue and told the vendor that they were going to rip out all the manufactures routing / switching equipment if they didn't get it fixed. after the manufacture send engineering staff on site they found that the problem was not the routers or switches but the SFP's that the Chip manufacture had purchased. After replacing the SFP's they had no problems. So if you were the router manufacture you might also put in the locks....... Just say'n I hate it also, but I also really like a stable network. I also know that there are some OEM's for even Cisco that I have used in the past. Just my two cents. Scott On Mon, Nov 17, 2014 at 10:11 AM, Jérôme Nicolle <jerome@ceriz.fr> wrote:
Hello,
I'm having a discussion with Arista, trying to explain to them why I _can't_ buy any hardware unable to run with compatible optical modules.
My points are :
- I need specific modules, mostly *WDM and BiDi, some still unavailable in their product line
- I run at least two other vendors on every locations and can't stack up every spare optics for each of them, neither could remote-hands safely re-program optics to match a specific vendor when needed.
- I have an established relationship with a trusted optics supplier, providing support, warranty and re-coding hardware for their entire (impressive) lineup. And this supplier is still 2-5x times cheaper than any vendor-labeled optics even with NFR-like discounts.
Based on these points, I discourage every customers of ever using locked-in equipments, and forbid them on my own network. Of course, Arista can't be pleased because their hardware never stepped chord in my customer's networks. But they seem to deliberatly miss my points every time the subject comes up.
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) ?
Did you ever experience a shift in a vendor's position regarding the use of compatible modules ?
Thanks !
-- Jérôme Nicolle +33 6 19 31 27 14
That is their most popular argument. However this is no different from putting a NIC card. RAM, or hard drives in a server platform. For that matter, do you blame the network vendor if you have a faulty optical cable? In your example, can you be sure that the SFP was the issue? You can't be because someone obviously did not follow the standards for the SFP interface, was it the network gear or the SFP itself. Just because brand X does not work with switch Y does not make it brand Xs fault. Obviously if there is a flaw in the NIC, the server guys should not get blamed. Just as there are standards for USB, PCI, SATA, and other, there are standards for SFP and SFP+ interfaces. If the optic vendor is not compliant, that's their problem and if your network gear does not accept any optic that complies with the standard that is the network gear's fault. Consider how you would feel if HP servers only accepted HP hard drives or would not accept an Intel NIC, would you accept that? Steven Naslund Chicago IL
I've asked the same question and got the answer that there is a REAL BIG chip manufacture that was having huge system issue and told the vendor that they were going to rip out all the manufactures routing / switching equipment if >they didn't get it fixed.
after the manufacture send engineering staff on site they found that the problem was not the routers or switches but the SFP's that the Chip manufacture had purchased. After replacing the SFP's they had no problems.
So if you were the router manufacture you might also put in the locks....... Just say'n
I hate it also, but I also really like a stable network. I also know that there are some OEM's for even Cisco that I have used in the past.
Just my two cents.
Scott
there's a reason why cisco introduced "service unsupported-transceiver", which still remains an undocumented command. i have arista gear as well. kinda wish they had a similar undocumented command.
On Mon, Nov 17, 2014 at 1:09 PM, ryanL <ryan.landry@gmail.com> wrote:
there's a reason why cisco introduced "service unsupported-transceiver", which still remains an undocumented command. i have arista gear as well. kinda wish they had a similar undocumented command.
Arista does have it (at least in older codes, no idea if it still works). http://serverfault.com/questions/281534/what-is-the-command-to-enable-3rd-pa... One note: I did not have to reboot the switch for it to work. That took care of *most* 3rd-party optics, but I seem to recall it didn't cover 100%. Ken
Le 17/11/2014 21:09, ryanL a écrit :
kinda wish they had a similar undocumented command.
Well, there is a command, and you can automate it's application. See https://gist.github.com/agh/932bbd1f74d312573925 . Can't tell if DOM is supported on 3rd party. -- Jérôme Nicolle +33 6 19 31 27 14
Our experience using that command has been mixed enough to be unreliable for production. Problems include error disabled interfaces refusing to come back online and the command not surviving a power cycle. Use with caution. Steven Naslund Chicago IL
On Nov 17, 2014, at 2:11 PM, "ryanL" <ryan.landry@gmail.com> wrote:
there's a reason why cisco introduced "service unsupported-transceiver", which still remains an undocumented command. i have arista gear as well. kinda wish they had a similar undocumented command.
On Mon, 17 Nov 2014, 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) ?
Did you ever experience a shift in a vendor's position regarding the use of compatible modules ?
In the case of some vendors (yes, you again, Cisco), the shift has been in the wrong direction. Some vendors treat optics as just a tool to do a job, and price accordingly. Those vendors tend to have fairly relaxed policies re: working with non-$vendor optics, as well. Other vendors treat optics as a cash cow^H^H^H^H^H^H^H^Hprofit center, and also price accordingly. Those vendors tend to scream bloody murder if a non-$vendor optic is encountered. Beyond that, I'd say you've covered all of the logical reasons why vendor lock-in is a bad idea, but as others have mentioned in this thread, those attitudes tend to change at a ridiculously slow pace, and only when forced by market conditions. jms
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
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. -- TTFN, patrick
On Nov 17, 2014, at 16:19 , Nick Hilliard <nick@foobar.org> wrote:
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
Hello Patrick, Le 18/11/2014 00:17, Patrick W. Gilmore a écrit :
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.
You got my point : I do care about per-port cost, but the actual cost is a composite of : - kit price - licences - optics - spare optics - power per port over expected run time - collocation space
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.
Programmable optics are fine, but then you'd have to keep your programming gear available and train your techniciens on it, or keep pre-coded spares for every locked manufacturers. It's probably fine in a pure DC environment with few locations and only one SFP+ type, but it's rapidly a total mess when you have to manage 40 channels for 3 module types over dozens of locations AND the added manufacturer specific pain-in-the-ass. -- Jérôme Nicolle +33 6 19 31 27 14
On Mon, Nov 17, 2014, at 07:02 PM, Jérôme Nicolle wrote:
It's probably fine in a pure DC environment with few locations and only one SFP+ type, but it's rapidly a total mess when you have to manage 40 channels for 3 module types over dozens of locations AND the added manufacturer specific pain-in-the-ass.
-- Jérôme Nicolle +33 6 19 31 27 14
So my question is, to Patrick's point, if you factor in the costs of managing this versus the costs of going with someone else who does not lock you in, is it worth it? Insert comment about TCO and ROI here, etc. -- Ryan Pugatch rpug@lp0.org Boston, MA on the web: www.ryanp.com (homepage) www.lp0.org (blog)
On (2014-11-17 19:11 +0100), 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) ?
Did you ever experience a shift in a vendor's position regarding the use of compatible modules ?
Your points are valid, I actually prefer 3rd party, even if it's more expensive than 1st party, just to have simpler sparing reducing OPEX. On RFP all vendors consistently have replied that they won't forbid using 3rd party optics, and won't deny support contract because of them. They may add that if optic is suspected, we need to replace it to 1st party, before TAC continues to work on a case. 1st party does do more testing on the optics than what we typically do, so some obvious problems will be avoided by buying 1st party. But if you are somewhat careful at sourcing your 3rd party, you should be quite safe. I have two examples of major problems caused by 3rd party. a) one particular optic had slow i2c, vendor polled it more aggressively than it could respond. Vendor polling code didn't handle errors reading from i2c, but instead crashed whole linecard control-plane. Vendor claimed it's not bug, because it didn't happen on their optic. I tried to explain to them, they cannot guarantee that I2C reads won't fail on their own optics, and it's serious problem, but was unable to convince them to fix it. Now I am in possession of good bunch of SFP I can stick to your routers in colo, have them crash, and you won't have any clue why they crashed. b) particular vendor had bug in their SFP microcontroller where after 2**31 1/100 of a seconds had passed, it started to write its uptime to a location where DDM temperature measurements are read. This was obvious from graphs, because it went linearily from -127 ... 127, then jumped back to -127. These optics when seated on Vendor1 caused no problems, when seated on Vendor2 they caused link flapping, even two boxes away! (A-B-C, A having problematic optic, B-C might flap). Coincidentally Vendor2 is same as in case a), they didn't consider this was bug in their code. This was particularly funny, if you rebooted 100 boxes in a maintenance window, then the bug would trigger at same moment after 2**31 1/100th of a second, causing potentially major outage. If you source from bad broker, and you hit issue b), you're screwed, because the broker can't tell you which optic you have are impacted by this issue, because bad brokers don't keep tracks on where they source optics, what serial numbers they are, what parts are inside the optics etc. If you source from 1st party, and you hit issue b), 1st party will be able to tell exactly which serial number range is impacted. But this is also true if you use professional 3rd party. -- ++ytti
On Sat, Dec 06, 2014 at 11:51:56AM +0200, Saku Ytti wrote:
a) one particular optic had slow i2c, vendor polled it more aggressively than it could respond. Vendor polling code didn't handle errors reading from i2c, but instead crashed whole linecard control-plane. Vendor claimed it's not bug, because it didn't happen on their optic. I tried to explain to them, they cannot guarantee that I2C reads won't fail on their own optics, and it's serious problem, but was unable to convince them to fix it. Now I am in possession of good bunch of SFP I can stick to your routers in colo, have them crash, and you won't have any clue why they crashed.
b) particular vendor had bug in their SFP microcontroller where after 2**31 1/100 of a seconds had passed, it started to write its uptime to a location where DDM temperature measurements are read. This was obvious from graphs, because it went linearily from -127 ... 127, then jumped back to -127. These optics when seated on Vendor1 caused no problems, when seated on Vendor2 they caused link flapping, even two boxes away! (A-B-C, A having problematic optic, B-C might flap). Coincidentally Vendor2 is same as in case a), they didn't consider this was bug in their code. This was particularly funny, if you rebooted 100 boxes in a maintenance window, then the bug would trigger at same moment after 2**31 1/100th of a second, causing potentially major outage.
Who is Vendor2?
Hello, Since we are on the topic of vendor locked optics. Does anyone know if the IBM G8124 TOR Switches have a hidden menu option to over-ride the vendor lock optics ? -------- We are seeing something interesting... we have a couple of these in production networks, apparently one switch will accept only IBM Optics, while the other will accept any.... I am not able to find anything which can explain the different behavior on the two switches. If anyone can offer an insights that would be greatly appreciated. Many Thanks in advance. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support@Snappytelecom.net ----- Original Message -----
From: "Chuck Anderson" <cra@WPI.EDU> To: nanog@nanog.org Sent: Saturday, December 6, 2014 8:37:01 AM Subject: Re: A case against vendor-locking optical modules
On Sat, Dec 06, 2014 at 11:51:56AM +0200, Saku Ytti wrote:
a) one particular optic had slow i2c, vendor polled it more aggressively than it could respond. Vendor polling code didn't handle errors reading from i2c, but instead crashed whole linecard control-plane. Vendor claimed it's not bug, because it didn't happen on their optic. I tried to explain to them, they cannot guarantee that I2C reads won't fail on their own optics, and it's serious problem, but was unable to convince them to fix it. Now I am in possession of good bunch of SFP I can stick to your routers in colo, have them crash, and you won't have any clue why they crashed.
b) particular vendor had bug in their SFP microcontroller where after 2**31 1/100 of a seconds had passed, it started to write its uptime to a location where DDM temperature measurements are read. This was obvious from graphs, because it went linearily from -127 ... 127, then jumped back to -127. These optics when seated on Vendor1 caused no problems, when seated on Vendor2 they caused link flapping, even two boxes away! (A-B-C, A having problematic optic, B-C might flap). Coincidentally Vendor2 is same as in case a), they didn't consider this was bug in their code. This was particularly funny, if you rebooted 100 boxes in a maintenance window, then the bug would trigger at same moment after 2**31 1/100th of a second, causing potentially major outage.
Who is Vendor2?
participants (20)
-
Baldur Norddahl -
Chuck Anderson -
Darden, Patrick -
Faisal Imtiaz -
Jethro R Binks -
Justin M. Streiner -
Jérôme Nicolle -
Ken Matlock -
Max Tulyev -
Naslund, Steve -
Nick Hilliard -
Owen DeLong -
Patrick W. Gilmore -
Richard Hesse -
Ryan Pugatch -
ryanL -
Saku Ytti -
Scott Voll -
Valdis.Kletnieks＠vt.edu -
William Herrin