TRILL – the future of switching?

STP works extremely well, but you lose operational links with it. i.e. you lose bandwidth. There are also quite a few other problems with STP (convergence speed being 1 of them)

TRILL seems to be the new technology coming in to resolve this. I’ve gone through the RFC: http://tools.ietf.org/html/rfc5556 and it looks pretty awesome stuff. I particularly like the following:

3.2. Zero Configuration and Zero Assumption
Both bridges and hubs are zero configuration devices; hubs having no
configuration at all, and bridges being automatically self-
configured. Bridges are further zero-assumption devices, unlike
hubs. Bridges can be interconnected in arbitrary topologies, without
regard for cycles or even self-attachment. Spanning tree protocols
(STPs) remove the impact of cycles automatically, and port
autolearning reduces unnecessary broadcast of unicast traffic.
A TRILL solution should strive to have a similar zero-configuration,
zero-assumption operation. This includes having TRILL solution
components automatically discover other TRILL solution components and
organize themselves, as well as to configure that organization for
proper operation (plug-and-play). It also includes zero-
configuration backward compatibility with existing bridges and hubs,
which may include interacting with some of the bridge protocols, such
as spanning tree.
VLANs add a caveat to zero configuration; a TRILL solution should
support automatic use of a default VLAN (like non-VLAN bridges), but
would undoubtedly require explicit configuration for VLANs where
bridges require such configuration.
Autoconfiguration extends to optional services, such as multicast
support via Internet Group Management Protocol (IGMP) snooping,
broadcast support via serial copy, and support of multiple VLANs.

and

3.4. Spanning Tree Management
In order to address convergence under reconfiguration and robustness
to link interruption (Section 2.2), participation in the spanning
tree (STP) must be carefully managed. The goal is to provide the
desired stability of the TRILL solution and of the entire Ethernet
link subnet, which may include bridges using STP. This may involve a
TRILL solution participating in the STP, where the protocol used for
TRILL might dampen interactions with STP, or it may involve severing
the STP into separate STPs on ‘stub’ external Ethernet link subnet
segments.
A requirement is that a TRILL solution must not require modifications
or exceptions to the existing spanning tree protocols (e.g., STP,
RSTP (Rapid Spanning Tree Protocol), MSTP (Multiple Spanning Tree
Protocol)).

Basically, even though TRILL sounds complicated, it very well could be plug and play (well about as plug and play as current STP mind you)