[rbridge] Emerging consensus to use STP for non-unicast? (was - Setting initial "hop count" value)

Erik Nordmark erik.nordmark at sun.com
Fri May 4 11:34:21 PDT 2007


Eric Gray (LO/EUS) wrote:
> TRILL-ers,
> 
> There appears to be a general acceptance of the idea of having 
> bi-directional trees used for distribution of multi-destination 
> frame traffic, at this point.
> 
> This means that there is necessarily a departure from the unicast
> forwarding scheme (based on SPF using IS-IS) for non-unicast and
> unknown unicast frame forwarding.
> 
> For reasons that have been beaten to death on this list, that is
> not necessarily a BAD THING.
> 
> Given this general trend, I agree with Joe that using existing STP 
> algorithms to establish these bi-directional trees is far better
> than starting from scratch with something else - however clever
> that something else may be.
> 
> The same arguments that hold for using IS-IS (as opposed to just
> starting with IS-IS and building something new, or developing an
> entirely new SPF routing algorithm), should hold for creation of 
> bi-directional L2 distribution trees as well.

 From what I can see there is no emerging consensus to do such a radical 
change, and it seems to be a complete departure from the TRILL charter 
which starts with 'using an existing link-state routing protocol 
technology.'

While layering or reusing 802.1D might be interesting to explore, I 
suspect there are some hard design issues (whether there is a single STP 
instance across the whole network, or a separate STP instance that just 
include the RBridge overlay.)
In any case, had we proposed that as the TRILL charter when TRILL 
started I am pretty sure the IESG would have just told us to go work in 
IEEE 802.

    Erik

> Note that while STP and RSTP would create a single spanning tree
> for all RBridges in the scope of a single VLAN, MSTP may be used
> to create multiple spanning trees - thereby effectively providing
> for the "multi-pathing" of multi-destination frames.
> 
> Thanks!



More information about the rbridge mailing list