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

From: saikat at seas.upenn.edu (Saikat Ray)
Date: Mon, 17 Oct 2005 11:21:51 -0400

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.

Do you have an example in mind where the previous scenario
(sbridges+rBridges) may end up in creating a loop?

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 17 Oct 2005 20:20:39 -0700

> network is simply one or more "link"s, and RBridges would ensure that there

Except that the rbridges add a 'link' between themselves - that's the
extra 'link' that can cause the loop.

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/20051017/d224d651/signature.bin

---

From: saikat at seas.upenn.edu (Saikat Ray)
Date: Tue, 18 Oct 2005 11:57:34 -0400

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...

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 18 Oct 2005 18:40:16 -0700

Saikat Ray wrote:
>>bridges, physical links etc., is simply a "link". In other words, the
> 
> entire
> 
>>could be replaced by a physical link. Thus even in this case, there would
> 
> be
> 
>>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.
> 
>>network is simply one or more "link"s, and RBridges would ensure that
> 
> there
> 
>>would be no loops.
> 
> 

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

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/20051018/c4528685/signature.bin

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Wed, 19 Oct 2005 09:57:00 -0700

The IS-IS Hello protocol is for electing a single unique switch per 
link. It doesn't matter which one it is.

On the other hand, the spanning tree protocol is picking a special 
single unique bridge per link...the
one that is closest to the root.

The spanning tree algorithm is choosing a tree of shortest paths from 
the root.

IS-IS is not trying to do that. It is just electing one guy on a link to 
do special link-specific things.

Radia

Joe Touch wrote:

>------------------------------------------------------------------------
>
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>  
>