916 Words. Plan about 4 minute(s) to read this.
Cisco is suing Arista in a pair of actions that will be interesting to follow as they wind their way through the courts. See post entitled “Protecting Innovation” here.
In the thirteen years I’ve been General Counsel of Cisco, I can count on one hand the number of times we’ve initiated suit against a competitor, supplier or customer.
It’s therefore only after thoughtful and serious consideration that we are today filing two lawsuits to stop Arista’s repeated and pervasive copying of key inventions in Cisco products. These suits cover key Cisco proprietary patented features and Cisco’s copyrighted materials.
One particular reason for “why we are suing” is especially interesting to me…
Arista’s actions, if unstopped, will embolden others to seek to do the same
Well, YES. That is most certainly true. For example, it’s become a networking industry cliche to describe a Cisco-like CLI as an “industry standard” CLI. A point I’ve been fascinated by, wondering why the world was that way. Apparently, it isn’t that way. Also fascinating is the remaining list of the items Cisco has listed as suit-worthy: System Database, Zero-Touch Provisioning, On Board Failure Logging, Control Plane Policing, Spanning Tree Loop Guard, In-Service System Upgrades, Virtual Port Channels, Access Control Lists Improvements, Private Virtual Local Area Networks, Generic Command Interface, and CLI Command Data Translation. An interesting list, if you think about other vendors who have implemented many similar features.
The post further points out…
In addition, Arista lifted over 500 of our multi-word command line expressions identically and directly from our “IOS” into Arista’s “EOS”, comprising almost half of their entire command line interface.
Arista has copied more than 500 Cisco multi-word command expressions, while networking products from HP, Brocade, Alcatel-Lucent, Juniper Networks and Extreme each have only a small fraction of overlapping CLI commands. In the case of Juniper Junos, the overlap is less than 30 multi-word commands.
Folks, these suits are something to keep an eye on. These legal actions could result in a number of actual impacts to Arista customers and to the larger networking industry. Some speculative thoughts.
Let’s say Cisco wins here, and the result is a significant financial penalty to Arista. Arista would have to pay some large sum to Cisco. How this would impact Arista’s bottom line is hard to predict. I have a hard time believing it could be enough to put them out of business.
All Arista features deemed by the courts to be infringing might have to be changed or otherwise removed from the EOS feature set. My brain bleeds contemplating such a penalty. That would have to be a mammoth engineering effort.
Using “industry standard CLI” to describe the Cisco CLI will become taboo. Vendors that follow this approach will be on notice that if they are too Cisco-like, they’ll need to make some changes. This is perhaps the easiest element of the suit for media people to grasp, and is going to get talked up a bunch. Oddly, this is coming at a time when the CLI is waning in significance. I am already looking towards a configuration future where I use the CLI as little as possible. I’d rather be using a controller or calling an API directly. Anyone copying anyone else’s API’s? Now, that’s a more interesting question.
Assuming Cisco’s citation of Virtual Port-Channel condemns Arista’s Multichassis Link AGgregation (MLAG), that could have some broader implications across the industry. Many, many vendors have some sort of MLAG implementation, so in what way was Arista’s MLAG an issue for Cisco? This is not obvious to me, other than the end result is the same: you can run an LACP trunk split between two physical switches. As an engineer who has implemented both VPC and MLAG in real life, I know that the configuration process is not similar. But is the implementation under the covers similar enough to warrant this part of the lawsuit? I’m not sure. Cisco seems to think there’s something there. I’m sure all vendors will be watching this point specifically.
I don’t believe Cisco would have brought the actions if they didn’t think they had a decent shot at winning. Arista’s a big target. They went public recently. They have been chipping away at Cisco’s business for years now. Lots of customers like the value proposition. Many Arista sales have come at Cisco’s expense. No doubt Cisco has had quite enough.
If I’m a network architect who’s bet big on Arista, I’m a bit concerned…
- While it seems unlikely that Arista disappears from the market, it seems plausible that significant architectural changes might be required of EOS in the long-term. That’s something that will have to be taken stock of over time. What will the changes be, assuming there are some?
- Will features be lost?
- Will features be re-implemented, such that they exist, but perhaps with different (non-infringing) functionality?
- Will there be an operational impact, where new processes must be implemented to accommodate EOS changes?
- Will there be a price impact, either capex (cost to acquire) or opex (cost to run)?
- Are any of these things reason enough to consider a shift away from Arista? It’s all far too early to tell, but that’s what I find running through my brain as prior to the suits I had already been evaluating what to do about my own (very small) aging Arista infrastructure.
It will be entertaining to see if Arista fires up some sort of countersuit — not uncommon in these situations — and on what grounds. Popcorn.
about | subscribe | @ecbanks