Cisco's FabricPath and IETF TRILL: Cisco Can't Have Standards Both Ways

Standards are standards for a reason. Standards allow customers to interconnect products with a hope that they will all work together easily and simply. It's how the Internet was built, though not without some problems, and how all the networking vendors built their businesses. No vendor, not even Cisco or Hewlett-Packard, can go it alone in enterprise networking. Even the whisper that a vendor is not standards-compliant can ruffle feathers and get danders up, so vendors come up with ways to give lip service to standards compliance when they really want to push their proprietary protocols. Vendors should innovate and address customer needs, but they should do so in a way that doesn't force customers into choosing either proprietary methods or standard protocols, something that Cisco seems to be doing with FabricPath and Transparent Connection of Lots of Links (TRILL).

When Cisco announced FabricPath, its "pre-standard TRILL" implementation (read proprietary), it was quite open about what FabricPath was and its relation to TRILL. "Transparent" is the word I am looking for. But here is where it gets sticky. You see, when TRILL is ratified and Cisco supports it, the company will be standards compliant, but you will have to choose to run either FabricPath or TRILL. You won't be able to run both. I know this because I asked my Cisco public relations representative, "Will Cisco support FabricPath and TRILL simultaneously (once TRILL is ratified, that is), or will it be an either/or choice?" This question was passed inward and the answer was, "Once TRILL is ratified, Cisco FabricPath customers will have two options: They can continue to use FabricPath as it is configured now, or they can run FabricPath in TRILL-compliant mode."

After much poking and prodding, I got an overview on some of the enhancements that FabricPath provides above and beyond TRILL. One of the enhancements is support for vPC+, which is Cisco's proprietary multichassis link aggregation protocol. vPC+ is proprietary since there is no standard for multichassis link aggregation. In fact, all network vendors' multichassis link aggregation protocols are proprietary implementations. vPC+ lets you connect non-FabricPath devices to FabricPath ones. Brocade's Virtual Chassis Switch (VCS) does something similar to integrate its proprietary multipath Ethernet-capable switches to products that don't support multipath Ethernet. FabricPath also supports multiple topologies. For example, switches can be restricted to only viewing specific VLANs and conversational learning of MAC addresses, which simplifies MAC table management, particularly in cases where the number of MAC addresses can run into the tens of thousands. (Think virtualized data centers.) These seem like really useful and desirable features, and if you are running an all-Cisco shop, then you should absolutely make use of them if needed.

So what if you aren't a 100 percent Cisco shop? What if you wanted to use switches from some other vendor in a TRILL-based network, as well? Then you have to use TRILL and lose the features of FabricPath that I just described. Funny thing about computers--and that is what a router or switch is, a specialized computer--they do what we tell them. There is no technical reason that Cisco couldn't choose to support both FabricPath and TRILL at the same time. That would be supporting the standards and that would be good for customers. What Cisco is trying to do--like all the other vendors that are setting up either/or choices, such as Brocade--is force you, the customer, into buying only their stuff while, at the same time, being able to say, "Hey, you're not locked in! You have a choice!" Here's a nugget. In a recent survey [purchase and registration required] of 468 IT professionals on their data center networking purchasing preferences, adherence to industry standards was the No. 2 requirement behind virtualization support. Proprietary technology in advance of standards, like Cisco's FabricPath or Brocades VCS, was No. 15 out of 15. Dead last.

Once an enterprise goes down a proprietary path, it's hard to come back. Why do you think the Cisco Discovery Protocol (CDP) is still supported when Link Layer Discovery Protocol (LLDP) and LLDP-MED are ratified? Enhancements to CDP make it a better discovery protocol than LLDP-MED in an all-Cisco, or all-Cisco CDP-supported, environments. Cisco executives I spoke with at CiscoLive acknowledged that they can't get rid of CDP because their customers are using it. I think Cisco could wean customers off CDP, but it's not that big a deal since Cisco switches do support both CDP and LLDP-MED simultaneously. There are some operational details enterprises need to consider when using both CDP and LLDP-MED, which Cisco's documentation LLDP-MED and Cisco Discovery Protocol  describes, but Cisco did the right thing here: It supports both its proprietary protocol, CDP, and the standard protocol, LLDP, and provides guidance on deployment implications when using both. Cisco could, if it wanted to, support both FabricPath and TRILL simultaneously. That's not too much to ask, is it? Maybe it is.