[rbridge] loops in trill networks

[Gray, Eric]

Dino,

	This potential "scaling problem" comes from mixing goals.
It should not - simultaneously - be a goal to both extend STP
across an L2 network and target a larger L2 network.  If we are
planning to keep the spanning trees simple and small, then we
might be able to achieve better performance with larger scale
layer two networks.

	In any case, I believe it has already been said that it 
is not necessarily a goal of RBridges to make LANs larger.  If
LANs get larger because of RBridges, it will be because they 
allow them to - not because they force them to.

	I've yet to see what the reasoning is for wanting to have
STP take place over the entire extended L2 network (overlay).
I've seen people argue that we could do so - but not why we 
would do so.  I've also seen people argue that we should do so,
but the argument seems to be based on a somewhat "purest" point
of view based on the belief that L2 networks do this.

	The entire discussions seems to have been initiated as a
result of confusing use of the term "spanning tree".  The fact
that a spanning tree may be determined in one way or another
does not mean, or even imply, that STP is always used.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org]On
--> Behalf Of Dino Farinacci
--> Sent: Thursday, October 13, 2005 8:17 PM
--> To: rbridge at postel.org
--> Cc: rbridge at postel.org
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> 
--> >> I think this is suboptimal, since the larger the 
--> spanning tree, the 
--> >> slower convergence would be.
--> 
-->     So that's a good point we should also decide on. If the 
--> introduction of
-->     RBridges causes traditional bridged networks to get 
--> larger, we could
-->     introduce a scaling problem by making STP work harder 
--> than it was
-->     originally designed for. 
--> 
-->     Now, yes, anyone could tunnel over any infrastructure 
--> and create an
-->     overlay topology (i.e. VPLS and L2 metro networks) but 
--> do we want to make 
-->     it more inherent in the architecture.
--> 
--> >> So I think it's a lot better to have RBridges not 
--> forward spanning tree 
--> >> messages, and keep the
--> >> bridge spanning trees really separate.
--> 
-->     I think I can go along with this too but we need to 
--> state that an RBridge
-->     network is not a traditional L2-based subnet. I think 
--> there are other
-->     reasons to claim this already (i.e. low incident 
--> forwarding loops and
-->     duplicate packets) so we wouldn't be setting a 
--> precedent for this case.
--> 
--> >> We could think of it as RBridges "participating" in 
--> 802.1d spanning tree 
--> >> by simply consuming
--> >> the messages (and not doing anything other than dropping them).
--> 
-->     Sure, makes sense.
--> 
--> Dino
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->