I think it’s more accurate to say that TRILL uses IS-IS to carry routing information for RBridge reachability – not MAC addresses.  In essence, the information that IS-IS is passing is information on how to reach each RBridge in the network, not how to reach the end station MAC addresses.  This is an important distinction, because it shows that the IS-IS routing table does not grow as your end station count increases – it grows as your RBridge count increases – making the solution all the more scalable.

1) we don;t see any requirement for support of broadcast interfaces for NNI or shared NNI/UNI . We see the DC L2 fabric having lots of point to point links and probably 2-3 levels deep.

2) The UNI’s will need active / active support to finer flow than vlan so that negotiation protocols should probably be separate rather than bundled in. Look at things like MCLAG and VC+ etc. We don’t see the link state protocol running at the top of rack, it has trivial routing requirements and rarely has any horizontal connectivity. If you need to run the link state in the top of rack your DC topology is going to get too large and you’ll slow it down unnecessarily.

3) We require OA&M now and don’t really want to add a third undefined OA&M mechanism and/or respin hardware yet again to support it.

4) We require more than 4K vlans now for large numbers of tenants and that problem was solved ages ago by .1ah and we don’t want to respin hardware yet again to support it.

5) We require multi topology for teneant isolation. Tenants are isolated physically in a DC and routing isolation is also a requirement. the IS-IS MT mechanism which SPB incorporates transparently is ideally suited to this.

6) We believe that IP managment can also run at the same time in the SPB IS-IS instance so that you only need one link state protocol.

7) For cases where flatter L2 is not required IP can co-exist with the SPB IS-IS as just another NLPID.

Hope that helps a bit.

I’m not really interested in SPB as I currently believe that TRILL is a better solution. I’m not sure why the IEEE is even bothering to continue with the standard. Maybe I’m missing something on understanding what the purpose of the SPB is.

Happy to discuss, or even podcast about it if you have the time.

greg

http://www.ieee802.org/1/wp-content/uploads/public/docs2010/aq-ashwood-interop1-1110-v02.pdf

Basically real switches were tested in a topology of 37 devices, 5 real, 32 emulated. Hardware datapaths, equal cost, and OA&M were shown.

We will be doing much more Interop testing in the new Year so stay tuned and we will keep the Wikipedia entry for IEEE 802.1aq up to date as we go.

As for multicast flooding, it simply becomes better optimized, as separate distribution trees could be pre-calculated and used, compared to STP instances in classic Ethernet.

http://blog.ioshints.info/2010/08/trill-and-8021aq-are-like-apples-and.html

Thanks for your response! For scalability, I would say that TRILL does help quite a bit, as it reduces the impact of unicast/broadcast flooding. Of course, MAC address scalability problem is not completely resolved, though it is mainly pushed to the “Edge” devices.

As for multipathing, it looks like this feature could have been implemented by simply tunneling Ethernet over any existing packet switched technology e.g. VPLS with FAT or entropy labels or just OTV. TRILL applies tunneling concepts as well, but does that within the scope of Ethernet headers. I understand that OTV and VPLS could be mainly viewed as DCI solutions, but that does not prevent them from being used for intra-site connectivity as well.

I believe one main “real-world” argument of TRILL proponents is cheaper cost per port for Ethernet compared to the use of VPLS edge devices. However, using layer 3 ethernet switches with added functionality of Ethernet tunneling could keep costs low as well, and it adds approximately the same complexity in the control plane as using TRILL.

Now for multipathing again TRILL re-uses the well-known shortest-path routing concepts. The problem is, that unless specifically engineered topologies are in use, obtaining rich set of ECMP could be challenging. Optimal link utilization by means of link weight tuning for link-state protocol is an NP-complete task, which does not always results optimum utilization for every topology. Though, I should mention that it does achieve satisfactory performancy in many practical cases.

However, for true optimum bandwidth utilization it may happen so that explicit traffic engineering solution could be needed. This significantly boosts complexity as it requires serious changes in control and data plane. VPLS-based solutions could achiver that easier, of course

So these are my main issues with TRILL. To summarize:

1) Why reinvent routing for ethernet when we can tunnel ethernet over routed networks.
2) Shortest-path routing could not always yield optimum bandwidth utilization (though it’s better than STP) so additional traffic engineering could be needed.

I do understand that the trump card or TRILL is plug-and-play behavior. Using any sort of tunneling techniques (e.g. VPLS or OTV) adds extra operational overhead, but it could be kept to minimum using auto-discovery techniques. Plus, administrative overhead adds better control and security over simple plug-and-play behavior.

Thanks,

Petr

TRILL does *not* claim to scale lareger than classic bridged LANs, at least not to any significant extent. As you try to scale Layer 2, you have fundamental problems of growth in the broadcast domain and growth in the number of non-hierarchical MAC addresses. TRILL supports VLANs to help on the broadcast domain front and requires only “edge” RBridges to learn end-station MAC address, but there are other solutions with those advantages.

The real advantages of TRILL are support for multipathing of both unicast and multi-destination traffic (you can easily support hundreds of equal cost paths for unicast with TRILL), the safety of a TTL, easy incremental deployment into an existing bridged LAN composed of commodity classic 802.1Q bridges, an options feature, optional support for end stations doing the encapsulation to an egress RBridge located through a directory service, etc., etc.

Thanks,
Donald

Next, the problems of MAC address table growth and automatic learning has not been completely addressed. With TRILL, edge device MAC address tables will grow linearly as the number of endpoints grow. The root cause of the problem is that MAC addresses serve purpose of pure endpoints IDs and not the location identifiers and consequently are non-aggregatable. A solution would be to reuse IP layer for routable locator IDs while keeping MAC addresses for Endpoint IDs. To control EID address tables exposion, some sort of distributed hash table for EID to RLOC mapping storage could be used (similar to what SEATTLE protocol does).

To me TRILL seems like a good work but not a good solution – it doesn’t try to effectively reuse existing technologies not does solve all Ethernet scalability problems.

In particular the l2 multipathing work has progressed rather well and now allows 16 symmetric algorithms with additional opaque mechanisms for the addition of many more. What is very interesting about this work is that these are head end chosen so you get a lot of control over how traffic will be placed.

The TRILL base protocol specification is now quite mature and the latest version is available at
?http://tools.ietf.org/html/draft-ietf-trill-rbridge-protocol-14

Thanks,
Donald

Donald

I claimed that the IEEE is not open. You can’t get any material on what they are doing, or how they do it, or what the the current progress is. Which is quite annoying for ‘public’ standards.

I was easily able to access and evaluate material from the IETF. I agree, you could not be anymore open.

Greg

I don’t understand why you are having difficulties getting access to what is going on in the TRILL WG in the IETF. The charter, which I admit is a little out of date, is here:
http://www.ietf.org/dyn/wg/charter/trill-charter.html

That charter page has links to the one RFC the TRILL WG has had published and to the base protocol specification draft, currently at:
http://www.ietf.org/id/draft-ietf-trill-rbridge-protocol-13.txt

As drafts are updated in the IETF, the direct text link, as above, to the old version goes away and a new link with the version number incremented is created, but here is a link to an html-ized version of draft -13 which should continue to work even after draft -14 comes out:
http://tools.ietf.org/html/draft-ietf-trill-rbridge-protocol-13

As for what is happening in the TRILL WG itself, minutes of all its meetings, like those for every IETF working group, are published in the proceedings of the IETF meetings. The proceedings are all linked from here:
http://www.ietf.org/meeting/proceedings.html
TRILL did not meet at the 72nd or 75th IETF meetings and I think there is at least one earlier one it skipped but if you go look at, for example, the proceedings for the 73rd and 74th IETF meetings, it is not that hard to find the TRILL meeting minutes. In fact, if you can’t make it to an IETF meeting, most of the WG meetings are publicly broadcast by streaming audio and you can call in to ask questions and there is usually an IRC channel with someone posting summaries of what is happening in real time and relaying questions anyone on the IRC channel has.
In fact, I find it very hard to conceive of any practical way in which IETF working groups could be more open. (I haven’t even mentioned the IETF fundamental that all the working group mailing lists are open and anyone can subscribe.)

Thanks,
Donald

I do not believe the drafts are publically available, but most of the input to them is, check out:

http://www.ieee802.org/1/wp-content/uploads/public/docs2009/

If you want to go backwards in time, the directories are also there for previous years…enjoy!

IMO there has been steady progress since 802.1ah was in scope, as it was a more natural fit for what SPB was trying to achieve….

cheers
D

I also remain skeptical about the IEEE competence. Ethernet is a success in spite of IEEE procedures and processes when I consider the multiple Wireless LAN cockups. Not to mention VLAN tagging…. oh I could go on.

It’s a shame that it won’t be ready until 2H2010, it was originally promised in 2008, maybe early 2009.

Until the IEEE does it better, I will remain critical. Show me results and transparency.

The critique of IEEE is IMO ill-informed. IETF (for example) resolves conflicts by publishing multiple RFCs and letting the industry decide, which simply punts their problems onto all of us. IEEE at least has the concept of “distinct identity” for a given project. It may take a little longer to get a standard but any industry confusion is capped there….

BTW 802.1aq is progressing nicely, has numerous pre-standard deployments, and should be baked as a standard in 1H2010…