[rbridge] it's time to summarize things
Stewart Bryant
stbryant at cisco.com
Fri Dec 16 02:23:43 PST 2005
Gray, Eric wrote:
>Stuart,
>
> First, thank you very much for providing a concrete
>example of the "optimality issues" Guillermo brought up
>earlier.
>
> Let me try to address the figure below as follows:
>
>1) we have already talked about the fact that an RBridge
> implementation may include colocated bridge functionality
> and that this colocated bridge may be configured with a
> high priority so that it will become the root for any
> connected bridge spanning tree.
>2) we said that we will include a statement to this effect
> in RBridge/TRILL specifications. Based on the example
> you provide, I am even willing to concede that doing so
> should be recommended.
>3) The separation of RBridge _implementation_ into one or
> more logical bridges and a (central/hub) RBridge allows
> for specification of the RBridge component orthogonally
> relative to the specification of bridge behavior (which
> is a] done already and b] not under our purview anyway).
>4) Even though this scenario strongly implies the need for
> a colocated bridge, in fairness, the scenario is based
> on the topological assumption that there is a(t least
> one) bridge to the right of the figure shown.
>
>To show that you can get the exact same result without a
>colocated bridge, consider the following modification to
>your proposed scenario:
>
> +----+
> -----| | L1
> -----| B1 |----------> B3 <---> To RBridge campus <-+
> -----| | |
> +----+ |
> | |
> | L3 |
> | |
> +----+ |
> -----| | L2 |
> -----| B2 |----------> B4 <---> To RBridge campus <-+
> -----| |
> +----+
>
>Given that your scenario assumes the presence of at least
>one bridge to the right (core-ward), then this transform
>simply means that a few of those existing bridges will not
>be scrapped when the rest are. Configuring B3 and B4 with
>higher priority makes this work in exactly the same way
>that Guillermo's colocated bridge functionality would.
>
>
>
I do not see how this solves the problem.
Only one of B3 or B4 can become root, so S will appear
to the right of B3, or B4, but not both.
The only way to load share traffic if for root to appear
inside the RBridge cloud. Is that what we are doing?
- Stewart
>--
>Eric
>
>--> -----Original Message-----
>--> From: rbridge-bounces at postel.org
>--> [mailto:rbridge-bounces at postel.org] On Behalf Of Stewart Bryant
>--> Sent: Thursday, December 15, 2005 9:54 AM
>--> To: Radia Perlman
>--> Cc: Developing a hybrid router/bridge.
>--> Subject: Re: [rbridge] it's time to summarize things
>-->
>--> Radia Perlman wrote:
>-->
>--> > I think I might need a picture of what you're saying, but
>--> > I think it's just the opposite. RBridges can path split,
>--> > just like routers can, whereas if the spanning tree turns
>--> > off one of the links, then a bridge would only use one of
>--> > the paths.
>-->
>--> The SPT situation is as follows:
>-->
>--> +----+
>--> -----| | L1
>--> -----| B1 |---------->To core
>--> -----| |
>--> +----+
>--> |
>--> | L3
>--> |
>--> +----+
>--> -----| | L2
>--> -----| B2 |---------->To core
>--> -----| |
>--> +----+
>-->
>--> You want
>--> B1 to connect a bunch of systems to the main network via L1
>--> B2 to connect a different bunch of systems to the main
>--> network via L2
>-->
>--> So you set B1 and B2 with low priority, so the root is to the
>--> right in the main network, and the ports connecting B1 and B2 to L3
>--> go into blocking.
>-->
>--> Say most of the traffic is to some server S. This traffic will
>--> be load balanced over both links L1 and L2.
>-->
>--> Now replace the core with an Rbridge network, but leave B1 and B2
>--> running SPT (because you can't upgrade the wiring closets -
>--> there are too many of them)
>-->
>--> How does the traffic from B1 and B2 to S get load balanced
>--> via L1 and L2?
>-->
>--> - Stewart
>-->
>-->
>-->
>--> _______________________________________________
>--> rbridge mailing list
>--> rbridge at postel.org
>--> http://www.postel.org/mailman/listinfo/rbridge
>-->
>
>
>
>
More information about the rbridge
mailing list