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.