[rbridge] SPF verses STP, straight across the board
sgai at nuovasystems.com
Thu Nov 2 18:28:45 PST 2006
Suppose that we have 5 RBridges, R1 to R5 and that R2 and R4 are
requesting a tree.
All the RBridges have the same LSA database propagated by ISIS.
They use Djikstra for the unicast core instance, putting themselves as
Then they also run two other instances of Djikstra, one using R2 as root
and one using R4 as root. As a result they put some port in forwarding
state and some in blocking state. Basically they compute 2 spanning
trees, one rooted in R2 (let's call it T2) and one rooted in R4 (T4),
without using the spanning tree protocol.
Each ingress RBridge can send multicast, broadcast and flooded frames
either on T2 or T4. It indicates its decision on the FTAG, which is
honored by all the other RBridges.
In this way the customer can get Shortest Path and also load balancing,
depending where he/she roots the trees. For example, in Fat Tree
networks, if you root the trees in the core, you get both.
> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
> Behalf Of Gray, Eric
> Sent: Thursday, November 02, 2006 2:34 PM
> To: rbridge at postel.org
> Subject: [rbridge] SPF verses STP, straight across the board
> There appears to be a late-blooming source of confusion relative to
> multicast, broadcast and flooded frame forwarding among RBridges.
> The question is - do the concerns about efficient link utilization
> via the use of SPF routing apply to multicast, broadcast and flooded
> traffic (as they do to unicast traffic), or do we simply use some
> variation of STP to determine "spanning trees" for the non-unicast
> I've been under the impression that the intention is to use SPF
> routing, straight across the board.
> rbridge mailing list
> rbridge at postel.org
More information about the rbridge