Commit To Standards: Drop Proprietary Protocols

I'm a big proponent of standards and standards conformance, which open up the marketplace to innovation and competition. Standardization is good whether you are a user or producer, but standards development is slow compared to how quickly a company can create a product or feature. Once a standard is available, vendors should stop promoting their proprietary protocols and migrate to the standards implementation. That shows commitment to standards.

In a recent blog post, HP versus Cisco: to tag VM's or not to tag VMs, ex-Cisco VP Doug Gourlay related an exchange he had during a discussion with customers: "I was getting a lot of pressure from a university customer to stop any development on anything that was not an industry standard. A gentleman from a large manufacturing company interrupted him and said, 'I don't care what standard they support. As long as they solve business problems for me, I will vote with my wallet. My CIO doesn't care if its PAGP or LACP, he cares that the network runs.'"

Both are valid positions. Standardization is good. It means products from multiple vendors can work together more or less seamlessly but ultimately integration is what IT wants. We can gaze at our navel and discuss the merits of a Bentham/Mills utilitarian view where standards as the greatest good for the greatest number versus a more practical David Allen's "Getting Things Done" approach, which tries to find the most efficient and effective way to a goal. But navel gazing doesn't move things along. Both people Gourlay was talking to want products that integrate and work.

Vendors have a different goal: sales and making money. That's not a judgment, it's their job.  Vendors add features to products to make them more enticing to customers. Since adding features involves a significant investment in development, vendors have to make sure that their feature is going to help them sell more products. Not surprisingly, standards bodies like the IEEE, ISO, and IETF, want to make sure the work they engage in will result in useful standards. There's no sense in working on a standard just because it's cool. Standards bodies want the business case before committing resources to a standard. In this way, companies and standards bodies have similar goals.

Standards are proposed because there is a need for a protocol and there's no existing technology to fill it, like 802.1X. In other cases, many vendors are creating protocols with similar features and standardization makes sense. For example, the Link Layer Discovery Protocol (LLDP) standard, 801.11AB, was created in the IEEE because there was an obvious need for a discovery protocol. Other examples are existing protocols like Cisco's Discovery Protocol (CDP), Extreme's Discovery Protocol (EDP), or Nortel's Discovery Protocol (NDP), all of which can identify connected devices such as switches, IP phones, network cameras, etc. The whole idea of standardization is to unify competing protocols by agreeing on one way to do something, and then promote that approach.If LLDP was ratified in 2005, why hasn't Cisco, Extreme, or Nortel moved to LLDP exclusively? They will claim their own feature sets are "customer driven."  That may be true, but are customers demanding support for a particular protocol or for a standardized way to integrate their gear? That's the $64,000 question.

Device discovery is particularly illustrative of the dichotomy between standards and proprietary protocols. Device discovery is used to automate switch management, port management, VLAN management, power management, location services for E-911 and asset management. Device discovery, once you use it, is incredibly powerful. Vendors want to leverage a discovery protocol to automate management of their products and better integrate with the existing network.

So what are these party vendors to do? The business case for them is to implement, at the very least, the protocol that the market leader is using. In network switching, the market leader is Cisco and Cisco's discovery protocol is CDP. Yes, I know Cisco products support LLDP, but some IT folks tell me that Cisco field engineers promote the use of CDP over LLDP. This contributes to confusion in the marketplace and vendors that make VoIP phones, etc have to support both CDP and LLDP in order to play in the widest set of instances.

The phrase "customer driven" is often used as a shield to continue to promote a proprietary protocol where a standard protocol already exists. HP Procurve dropped all but basic support for CDP years ago, but that isn't surprising because HP didn't have a competing discovery protocol. In fact, HP used CDP until LLDP was finalized. HP Procurve owns 15% of the switch market while Cisco owns 60% to 70%, so HP dropping support CDP wouldn't have the same impact as Cisco doing the same. Had Cisco dropped support for CDP, with a migration plan for existing customers, the industry would be rallying around LLDP. But that isn't happening.

In an interview with Netgear about a new switch line, they told me they supported CDP and were surprised to hear that many IP devices support both CDP and LLDP. Netgear is not alone in thinking that way.

It's not just Cisco. Microsoft promotes its own Office Open XML (OOXML) document format even though ODF was already working its way through ISO. The storage industry is rife with examples making standards like FibreChannel proprietary enough to drive approved equipment lists and other silliness. In the end, continued use of proprietary protocols where standardized protocols exist hurts everyone by:

Vendors will tell you that they support standards by paying employees to participate standards committees and participating in bake-offs and plug fests to workout implementation details of the standards; however, when they continue to promote their own protocols, I have to question their commitment. This is the bitter pill. If a standard protocol is available, vendors should embark on an end-of-life program for any competing proprietary protocols. It's good for the industry. It's good for customers. It's good for vendors.