[rbridge] FW: Time to summarize "forward or block" BPDU thread

[Saikat Ray]

>>Now you can have an rbridge and an sbridge in the same L2 (how do you
>>know you don't?). They form an undetectable, uncorrectable loop.
>>
>>
>>[Saikat] I do not see how this happens. First I am assuming that if
>>"sbridges" are connected by physical links, then they know how to avoid
>>packet loops by some mechanism they choose to implement. Now, as far as
>>"sbridges" are concerned, the network consisting of RBridges, STP-running
>>bridges, physical links etc., is simply a "link". In other words, the
> 
> entire
> 
>>network (consisting of RBridges, STP-running bridges, physical links etc.)
>>could be replaced by a physical link. Thus even in this case, there would
> 
> be
> 
>>no packet loop in the steady state.
>>
>>Another way of looking at this argument is the following. Suppose you
> 
> remove
> 
>>all the RBridges from the network. sBridges and legacy bridges are left,
> 
> and
> 
>>the assumption is that in that case, at least, a loop-free network
> 
> results.
> 
>>Then when you add RBridges (in their original position), the rest of the
>>network is simply one or more "link"s, and RBridges would ensure that
> 
> there
> 
>>would be no loops.
> 
> 
> Except that the rbridges add a 'link' between themselves - that's the
> extra 'link' that can cause the loop.
> 
> Joe
> 
> [Saikat] We discussed this possibility before (Radia and I exchanged a
> couple of emails). When RBbridges add a "link" between themselves
(actually
> you need to consider only the scenario when "designated" RBridges add a
> "link" between themselves), there will be a temporary loop. Then the
> designated RBridges will start seeing each others' hello messages, and
they
> will know that there is a loop. In that case, all but one designated
> RBridges (who are connected to themselves by a single "link") will
> "de-designate" themselves. Thus in the steady state there would be no
loop.
> 
> Thinking more about the problem of "Lateral compatibility"---i.e. when
there
> is a third protocol (the one your imaginary "sBridge" implements) that do
> not know about RBridges and vice versa---I am quite convinced that *if*
all
> the protocols jointly converge to a steady state, there will be no loop in
> the system. This basically follows from the fact that in the steady state,
> each given protocol can view the rest of the network as one or more
"links".
> However, in the presence of 3 or more protocols, it is not clear to me
> whether joint convergence to a steady state is guaranteed in all cases (I
> posted a message regarding this before). I tend to believe that in
> "ordinary" cases it should, but there may exist special cases...

If all this is true, why not do this for ordinary bridges?

Joe

[Saikat] I just sent an email yesterday to the list regarding the situation
if ordinary bridges simply choose an arbitrary "designated" bridge per LAN
without regard to its distance from a given bridge (the "root"). Probably
you missed it. You can check it here.

http://www.postel.org/pipermail/rbridge/2005-October/000744.html

Basically, loops are avoided, but the network may end up disconnected! This
does not happen in RBridges because RBridges send *encapsulated* packets
without any restriction, which preserve connectivity. In other words, if you
allow ordinary bridges to encapsulate packets and send them without any
topological restriction, then you could as well use an arbitrary designated
bridge per LAN, but then ordinary bridges would simply become RBridges! In
other words, the critical difference between the ordinary bridge and RBridge
(in my mind, at least) is that ordinary bridges are not allowed to modify
the data packets in any way, but RBridges are.