A comment by Brad Hedlund has sent me studying the differences between TRILL and 802.1aq and one of the first articles I’ve stumbled upon was a nice overview which claimed that the protocols are very similar (as they both use IS-IS to select shortest path across the network). After studying whatever sparse information there is on 802.1aq (you might want to read Greg Ferro’s fascination with IEEE paywall) and the obligatory headache, I’ve figured out that the two proposals have completely different forwarding paradigms. To claim they’re similar is the same as saying DECnet phase V and MPLS Traffic Engineering are similar because they both use IS-IS.
Within the backbone, TRILL is a true layer-3 protocol: TRILL header has a hop count, RBridges have layer-3 addresses and the layer-2 header changes as the packet is propagated across the backbone. Even though TRILL still retains the bridging paradigm at the edges, its core properties ensure it behaves like any other (well designed) L3 protocol.
As you can see in the diagram, once the ingress RBridge receives the end-user’s MAC frame, the frame is encapsulated in a layer-3 TRILL header with layer-3 addresses of ingress and egress RBridge. The TRILL datagram gets a new MAC header, which is changed every time the packet is forwarded by an RBridge; the layer-3 addresses in the TRILL header obviously stay unchanged, just the hop count is decreased.
Drawbacks: TRILL cannot be implemented with those existing (low-cost) ASICs that are hard-coded to support only 802.1ad and 802.1ah. It can be implemented, however, with any forwarding architecture that is generic enough to be able to insert and remove L2/L3 headers on ingress/egress points and swap L2 headers and modify L3 headers while forwarding the datagrams.
802.1aq is actually a modified way of populating the bridging FIB (Forwarding Information Base), while the forwarding paradigm stays unchanged. 802.1aq can use 802.1ad (Q-in-Q) forwarding or 802.1ah (Provider Backbone Bridging or MAC-in-MAC) forwarding. I sincerely hope nobody will implement Q-in-Q forwarding (SPBV), as it’s a total confusion (on the other hand, troubleshooting that would be excellent job security), so let’s focus on MAC-in-MAC forwarding (SPBM).
The ingress PBB (Provider Backbone Bridge) takes the user’s MAC frame and encapsulates it in 802.1ah MAC frame. The destination MAC address in the 802.1ah MAC frame is the egress PBB and there’s no hop count that can be used to detect loops (or allow the network operator to traceroute across the network). The new frame is bridged across the 802.1aq backbone; because the FIB building mechanisms are modified, the backbone is no longer limited to a single spanning tree (which makes 802.1aq different from 802.1ah). Throughout the backbone forwarding process, the frame is unchanged (and the destination MAC address remains the address of the egress PBB).
Benefits: 802.1aq can use existing ASICs
Drawbacks: 802.1aq has no relation to routing and none of the routing functionality. A loop generated by the control-plane protocol (for example, due to buggy implementation or distributed nature of IS-IS computations) can cause a network meltdown.
According to the comment Brad made, the current FabricPath implementation does not change MAC header on every hop, so it seems to be aligned with the 802.1aq framework. Please allow me to refrain from commenting what this really means for the marketing claims about FabricPath.
And, last but not least, if you’d like to know more about L2/L3 switching in Data Center and emerging DC technologies, watch my Data Center 3.0 for Networking Engineers webinar (buy a recording or yearly subscription).