The TRILLing brain split

The split personality Cisco has exposed at Cisco Live 2010 is amazing: on one hand you have the Data Center team touting the benefits of Routing at Layer 2 (an oxymoron if I’ve ever seen one), on the other hand you have Russ White extolling the virtues of good layer-3 design in the CCDE training (the quote I like most: “It all meets at Layer 3 ... that’s why CCDE is layer-3 centric”). If you’re confused, you’re not the only one

Read more ... (this time @


  1. I'd be interested to hear your thoughts on the proposal that LISP be used to help enable virtual machine mobility across traditional layer-3 boundaries.
  2. TRILL really is routing at layer 2. Using a well established routing protocol, ISIS. If switches had the horse power to run TRILL 20 years ago, people (like me) might not despise network designs that require layer 2 loops.

    That being said, it is way too new to interest me. I'll let other people find the bugs. I'll stick with routing as my go-to way to go :)
  3. TRILL is bridging across a routed infrastructure. It's not (conceptually) much different from VPLS or OTV. In the end, IS-IS is used only to build the inter-rbridges infrastructure and flooding-like mechanism is used to discover MAC addresses.

    Now, if they would advertise MAC addresses as TLVs in IS-IS, and stop flooding the unknowns, that would be routing. Today, it's not. ESADI is a step in the right direction, but they couldn't make it authoritative, because the whole thing is still ... guess what, bridging.
  4. You don't need LISP for VM mobility across L3 infrastructure. You can easily do that with LAM, probably also with DHCP forwarding ... assuming the # of VMs does not exceed your TCAM limits.

    LISP is useful when you need to shift the DC ingress point for a particular IP address to a different site when the VM is moved.
  5. Speaking of bridging and routing here, how is briding different from routing? Take SRB for example: is it more routing or bridging? Of course, calling bridging a "transparent" bridging makes things more clear, but it would be nice to have a better characteristic.

    To me, the essential property is that bridged domain being treated as a single link with all nodes directly attached (physically, or virtually like in TRILL/OTV). Essentially all endpoints are unaware of the undelying domain structure and assume they can reach any other endpoint directly by referring to its ID.

    Next problem is that traditional routing protocols base their scalability on routing information aggregation, which requires hierarchical structures. Bridging assumes flat structure with no aggregation and hence is you leak endpoint identifiers into IGP/BGP you end up with unscalable/unstable system. Of course you may handle thousands of MAC addresses more or less reliable with ISIS, but asymptotically this "edge" design simply wont work.

    This problem could be alleviated by changing the IGP/BGP-based endpoint information distribution to a technology that can deal with mobile and flat endpoint labels. There is a number of approaches here, similar to some protocols found in MANETs. I'm saying "some" since the area of MANET routing is huge and easily encompasses a few tens of protocols and their variations.
Add comment