[rbridge] seeking input on abstract for problem and applicabi lity statement

[Joe Touch]

Gray, Eric wrote:
> Joe,
> 
> 	You said: The edges are individual spanning trees. The rbridge 
> 	can have more than one internal path between two edge trees, 
> 	but that's it, that's all the redundency that's provided. 
> 	Turning off ports on the outside edge of the rbridge has no 
> 	effect on the internal multipath potential.
> 
> 	And then later, you also said: Yes [STP would be disabled by 
> 	default]. And not to forward ingress frames until internal 
> 	routing (IS-IS in this case) is established. At that point, 
> 	STP should be enabled at the 'edges', STP PARTICIPATEd, and 
> 	-then- ingress enabled.
> 
> 	What's the problem?
> 
> "Internal" and "external" are not meaningful terms.  How would an
> RBridge distinguish an "internal" bridge from an "external" bridge?

Internal and external traffic is easy to distinguish (internal has the
shim header). Bridges can be either or both, of course. It doesn't
matter, though - both can set their spanning trees before the rbridge is
configured.

> You suggest that this would occur as a result of recognizing that
> another RBridge exists on the local bridged network.  That appears
> to assume that the only way to keep RBridges from being part of the
> same campus is to put a router between them.  That - in turn - has
> some interesting implications with respect to colocation of router
> and RBridge functionality.

That was Radia's assertion. I had always thought an L2 could have more
than one rbridge campus, but that would imply that there was a way to
indicate which campus an rbridge was part of (e.g., via override).

> The key reason why I don't think that the presence of other RBridge 
> on a port makes it an "internal" port is that there is a distinction
> between reaching other RBridges in certain extended topologies and
> reaching them in other densely interconnected topologies.  But that
> may simply be a terminology issue.
> 
> The same applies to "ingress" and "edge".
> 
> But there's a larger issue.  I am not at all convinced that it is
> ever necessary to differentiate the behavior of "internal" verses
> "external" interfaces.  Consequently, I think it is an unecessary
> complication, especially given that - if it is indeed based on the
> presence of another RBridge on the same link - it is something that
> can change very quickly, causing an RBridge to change operational
> modes.  There's no reason I can see for taking on the additional 
> complexity.

I agree that interfaces aren't internal or external. Let's put it this way:

	rbridges ingress/egress functionality is disabled until the
	spanning trees of other bridges is completed (it basically has
	to be; otherwise, stuff falls on the floor).

	once the other spanning trees are set, the rbridge can
	enable ingress/egress (which is when it would anyway, since
	that's the point at which traffic would flow.

> 	You also said: Rbridges have nothing to do with the convergence 
> 	of the spanning tree external to them, IMO. All they do is have 
> 	their INTERNAL routing converge faster than spanning tree would
> 	have - that's where the benefit comes from. I never thought it 
> 	had anything to do with an effect on the external trees.
> 
> 	And then later said: That's an interesting question - [a longer 
> 	initial convergence time] may be the result of having an internal 
> 	routing protocol that isn't setup ahead of time. [That is], maybe
> 	rbridges DO take longer to *initially* converge the STP of an 
> 	existing net, but react faster *afterwards* to changes.
> 
> This is only true if RBridges do not participate in STP with the
> bridges in a local bridged network. If they do participate, then
> the STP will not converge until after the RBridges have determined
> forwarding paths among themselves, which will not occur until any
> bridges between RBridges have converged on their STP.
> 
> So, the bridges between RBridges do STP.  The links between RBridges
> come up.  The RBridges "hello" each other, peer, exchange link state
> and reachability information, and then announce a topology change to
> at least all ports that they have not heard other RBridges on (though
> this is not sufficient, let's assume for simplicity that it is).  Now
> the bridges on the affected links re-start STP - only now the network
> of bridges is very much larger, because it includes at least bridges
> that hang off of the RBridge's peer's other interfaces.
> 
> How is it that this does not take longer than if the RBridges didn't
> exist?  Also, there appears to be a misconception that STP takes a
> long time in comparison with routing.  Given that STP must complete 
> before routing can begin, this is a bit of a misleading concern, at
> best.

This is a startup issue; I have already agreed that this would take
longer with rbridges in the loop, with the hope that later cahnges could
be propagated more quickly.

> Let's take a specific case: An "internal" bridge goes down, taking
> one or more links between RBridges with it.  The RBridges lose a
> forwarding path and make the corresponding LSDB updates. Further,
> let's assume that this partitions the RBridge campus temporarily.
> 
> The link is redundant, so a neighbor will announce a topology change 
> and STP will re-run to switch port forwarding states so that the 
> redundant path is now available.  
> 
> The link returns and IS-IS reconverges.  Now the RBridges might be 
> clever and recognize that the net change (no pun intended) is NIL - 
> assuming that all of this happened fast enough that the RBridges
> have not previously announced a topology change to "external" bridges.
> 
> In this case, nothing else happens.  
> 
> However, let's assume that the re-establishment of the "internal" 
> link did not happen fast enough.  In that case, the "external" 
> bridges will see two topology change notifications and STP will be 
> run each time.  If the second topology change occurs before the STP 
> completes for the first topology change, it will be as if the whole 
> system is being restarted from scratch.

I'm not sure I followed all of that, but yes, there are cases where
changes in the internal paths available to an rbridge due to
partitioning could affect edge STPs.

> 	You also said: [STP convergence is] just like adding a bridge 
> 	to an existing bridged system. The new bridge doesn't forward 
> 	frames until STP finishes, but the existing bridges can finish 
> 	just fine. The rbridge is the 'new' bridge. 
> 
> 	All the other bridges are the existing bridge system. No chicken 
> 	and egg, AFAICT; the sequence is determined by rbridge's reliance 
> 	on bridges.
> 
> I think that in this case (and maybe in others) we're not talking
> about the same kind of convergence problem. I am talking about the
> time that initial convergence takes and you're (apparently) talking 
> about the time it take to re-converge after a minor topology change.

I had been talking about both cases (at least in later emails), and
already agreed they were different.

> Also, STP convergence - as explained above - is different if a 
> bridge goes down.
> 
> I think - even so - that there's a flaw in your reasoning that is
> based on a mistaken assumption that you specifically state below.
> 
> 	Also, you said: Again, I'm back to 'what would a bridge do'. 
> 	Either this is a bridge (PARTICIPATE) or a link (e.g., hub, 
> 	which means TRANSPARENT). Those are the only two options that 
> 	have correlaries in existing L2.
> 
> That's simply not true.  Hosts exist at L2.  Routers exist at L2.
> Neither of them do either of these.

Yes. And - sorry to shout but this point apparently isn't being
appreciated - BOTH HAVE L2 SOURCE/SINK ADDRESSES.

Rbridges - at least as far as ingress/egress links are concerned - do
NOT. Their addresses are ONLY for rbridge-rbridge traffic.

So - this is equally important:

	to conventional nodes (hosts/routers are the same thing in L2)
	on the L2, the rbridge MUST act like a link/hub or switch

	to other rbridge nodes (and only to them), the ingress/egress
	look like conventional nodes (sources/sinks)

> 	Finally, you also said: [RBridges] can't make redundent paths 
> 	in the non-rbridge portion of an L2 net. They can only do so 
> 	within the rbridge.
> 
> This is a flawed assumption.
> 
> Note that even bridges can carry L2 traffic for more than one VLAN.
> It's a simple matter - if you're starting from scratch to implement
> a bridge - to allow an RBridge (for instance) to use one port in a
> local bridged network to forward frames associated with one set of
> VLANs, and another port in the same local bridged network to forward
> frames associate with another set of VLANs.

Different ports for different VLANs aren't redundent paths, unless
you're going to move frames from one VLAN to another.

> Also note that there is no possibility of looping traffic introduced
> by this behavior.
> 
> Also note that the same would obviously apply if another RBridge
> in the same RBridge campus had a port in the same local bridged
> network.
> 
> Participation in the local STP would mean that the local bridges 
> would determine that the RBridge campus had a redundant path.  As
> a result, certain of the local bridges would put their ports in a
> non-forwarding mode - making use of the redundant path impossible.

Isn't that just an STP per VLAN?

> Clearly this can be applied to other mechanisms for differentiating
> frame-streams than by VLAN-ID, but it should be sufficient to show
> a single example of when participating in local STP is a bad idea.
> 
> Finally, note once again that all of this applies equally to both
> "internal" and "external" ports.

FWIW, nobody has answered the basic question:

	replace an rbridge in BLOCK mode with a bridge

	run whatever rbridges run internally within the bridge
	(i.e., emulate it)

	would THAT device be able to replace a bridge?
	would THAT device be able to partition the STPs of its leaves?
	
So far, the ONLY reason I can see that the rbridge *might* get away
doing anything different from a bridge is the requirement/assumption
that all rbridge devices in an L2 aggregate into a single campus.

If that IS the case, there *might* be a way it can do something other
than TRANSPARENT or PARTICIPATE, but it's not clear how different it
ends up being from PARTICIPATE (it seems like it still has to be roots
on each STP - how does it do that?)

If that IS NOT the case, someone needs to show how these behaviours
couldn't be used to augment a conventional bridge to result in
partitioned, faster-converging STPs.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20051014/3fa2acd0/signature.bin