FRAMINGHAM, Mass. – Two high-profile specifications winding their way through the Internet Engineering Task Force (IETF) promise to boost data centre switching and service provider routing, but advances from Cisco Systems Inc. and Juniper Networks Corp. raise questions about how much the specs are even needed.
For switching, the IETF is working on Transparent Interconnection of Lots of Links (TRILL), which is intended to overcome limitations of the Spanning Tree protocol in scale and topology reconvergence. For routing, the IETF is investigating the Locator/ID Separation Protocol (LISP), which is designed to improve addressing and load balancing for enterprises working with multiple ISPs.
While these may seem like solutions to long overdue networking problems, they may also be redundant with capabilities already or soon to be on the market. In the case of TRILL, Ethernet switch market leader Cisco will soon be shipping FabricPath for its Nexus 7000 switch that accomplishes the same tasks TRILL is intended to address while providing many more capabilities.
And Cisco, the original author of LISP, acknowledges there are other techniques available today that accomplish some of the same goals as LISP. Rival Juniper concurs, enough so that it is holding off on pledging support for LISP — as well as TRILL.
“We’ve already been doing this for the last two and a half years,” says Dhritiman Dasqupta, senior product marketing manager for data centre technologies at Juniper. “What else does TRILL bring to the table? Honestly, we can’t find much.”
TRILL — IETF RFC 5556 — was authored by Joe Touch, research associate professor at the University of Southern California’s Information Sciences Institute, and Radia Perlman, a software engineer at Intel Corp. who also created Spanning Tree. TRILL is intended to be a Layer 2 protocol with link state routing enhancements to enable shortest path multihop routing so users can build large-scale Ethernet and FibreChannel-over-Ethernet data center networks.
Link state routing allows the Ethernet network to discover and calculate shortest paths between TRILL nodes called Routing Bridges, or RBridges. TRILL is designed to overcome the slow topology reconvergence times associated with Spanning Tree, which limits scale and is more susceptible to link failures, but also backward compatible with existing Spanning Tree implementations.
Donald Eastlake, a principal engineer at Cisco and co-chair of the TRILL working group within the IETF, says the final TRILL RFC document will be published once a companion document that specifies IS-IS code points and data structures is agreed upon. He expects that sometime “fairly soon,” while analysts expect products to populate the market in the first half of 2011.
In the meantime, vendors are implementing and testing preliminary versions of TRILL. The University of New Hampshire InterOperability Laboratory hosted a TRILL Plugfest last week; announced participants were components suppliers Broadcom and JDS Uniphase, and database giant Oracle, according to the UNH-IOL Web site.
Eastlake concurs that TRILL is essentially Layer 2 routing.
Don’t be surprised if that TRILL RFC is missing from Juniper’s data sheets on its EX or upcoming Project Stratus data centre switches, however. Juniper claims its Virtual Chassis technology, which interconnects 10 Juniper fixed-configuration switches into a single “switch” supporting hundreds of Gigabit Ethernet ports, accomplishes the same goals as TRILL — chiefly, to collapse layers of switching in a data center network and facilitate more “east-west” communication between servers than “north-south.”
“What we are doing today is way beyond what TRILL is doing,” Dasqupta says. “It’s trying to focus on just one problem in isolation, which is Layer 2 multipathing. There’s multiple other things happening in the data center.”
Some of those other things are lossless transmission and LAN/SAN convergence, requirements being addressed by other standards activities — the IEEE’s Data Center Bridging/Converged Enhanced Ethernet work, and ANSI T11’s FibreChannel-over-Ethernet specification among them.
TRILL lacks a holistic data center vision, Dasqupta says, in that it limits a data center fabric to Layer 2 — interdomain communication has to go through a Layer 3 port, such as that on a router, which add cost, latency and a bottleneck in the network.
With Virtual Chassis and Stratus “you don’t need to step outside the fabric and then come back in,” Dasqupta says. “We can handle all of it within the same fabric.”
The only advantage to TRILL then is for interoperability, Dasqupta says. Juniper’s Virtual Chassis and Stratus fabrics will not be interoperable with Cisco’s FabricPath and Brocade’s VCS, so TRILL will be the least common denominator for fabric interoperability between those approaches.
Another issue complicating TRILL’s potential is an alternative standard being developed by the Institute of Electrical and Electronics Engineers (IEEE). The 802.1AQ Shortest Path Bridging specification is an extension to the Multiple Spanning Tree Protocol that also uses a link state routing protocol to allow switches to learn the shortest paths through an Ethernet fabric and dynamically adjust to topology changes.
Eastlake calls Shortest Path Bridging a “competitor” to TRILL.
“Currently, Shortest Path Bridging is limited to a maximum of 16-way multipathing,” Eastlake says. “TRILL has no limits — people are talking about 100-way multipathing.”
Yet another possible obstacle to TRILL’s potential is Cisco’s FabricPath. Cisco describes FabricPath as a “pre-standard superset” of TRILL that includes TRILL but extends its capabilities, particularly in MAC address learning and topology computation. But with Cisco’s dominance in Ethernet switching and FabricPath’s market lead time over a final TRILL standard, the case for TRILL could be marginalized.
“Initially, customers will gravitate toward FabricPath,” says Zeus Kerravala, an analyst at The Yankee Group. “They have such large share that you almost put yourself at a competitive disadvantage by not supporting it.”
Eastlake, however, doesn’t see FabricPath as a threat to TRILL.
“There has been Cisco involvement [in TRILL] pretty much all along,” he says. “The fact that Cisco is endorsing this whole concept…is generally a boost for the technology. It makes it a mainline technology.”
Ritesh Mukherjee, a Cisco product manager, says: “Customers can use FabricPath and only have the TRILL capability [active]. That would be fine. I don’t think it will be a step down, but you aren’t using all of the capabilities provided by FabricPath.”
Mukherjee is the product manager for LISP at Cisco. Cisco authored the original LISP IETF document last year and the IETF formed a working group on it shortly thereafter.
LISP was initially designed to help scale the Internet by reducing the number of routing table entries in core routers operated by ISPs. LISP would logically separate a block of IP addresses that a company advertises out to the global Internet into two functions: one for identifying the systems using the IP addresses, and the other for locating where these systems connect to the Internet.
This separation allows LISP to aggregate the location information, so less of it needs to be stored in the core routers. LISP proponents also say the technique would make it easier for companies to switch carriers without having to acquire new IP addresses because the identification function would remain constant even if the location information changes.
It is beneficial for enterprises deploying multihoming — using multiple ISPs for Internet access service — and can also be used to balance traffic loads destined for multihomed enterprises as well as other traffic engineering applications.
LISP would operate in conjunction with the Border Gateway Protocol and any other routing protocol, and with both IPv4 and IPv6, Mukherjee says.
“We look at LISP as a new routing architecture, which enables enterprises and service providers to simplify multihomed routing, provide data center virtual machine mobility and to reduce complexity,” Mukherjee says.
“We can get the current [routing] system to run but reduce the pressures on it from multihoming and other issues,” says Joel Halpern, co-chair of the LISP working group in the IETF. Halpern says that only customer edge routers would need a software upgrade in order to implement LISP.
LISP will be published as experimental or informational RFC documents, Halpern says, not standards track documents.
Mukherjee says Cisco will release LISP software early next year, and there is a test bed already underway.
There are other alternatives and activities underway in the IETF for addressing core route system scaling, Halpern says. One of these is the Identifer-Locator Network Protocol (ILNP) proposal in the Routing Research Group of the Internet Research Task Force.
Even though LISP was initially authored by Cisco, it is not facing any significant resistance from Cisco competitors, Mukherjee says. Indeed, the LISP working group is populated by representatives from other vendors and is co-chaired by Halpern, who is with Ericsson.
But again, Juniper, the No. 2 vendor to Cisco in routing, says LISP reinvents the wheel.
“It is a single vendor authorship,” says Mehdi Sif, director of technology marketing in Juniper’s Infrastructure Products Group. “There is a question out there on whether this is a vendor-specific solution to a vendor-specific problem.
“[There are] existing standardized mechanisms — route aggregation, route summarization, FIB/RIB compression mechanisms — widely deployed today, even for legacy platforms. I would see LISP as a subset of much broader conversations that are happening across the board — and which involve all of the vendors, by the way.”
