Subject: [rbridge] loops in trill networks

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Wed, 12 Oct 2005 16:45:38 -0300

Dino,

	No, actually, it is not like saying that.

	Given that we expect to have bridges between Rbridges
(though they're supposed to be invisible to RBridges), and
the fact that we expect to have Rbridges connected to each
other, it is not at all bizarre to expect that we might end
up with a bridge connected to an RBridge on the same port
that the RBridge is connected to another RBridge.  Like this:

	RB-1 ---+--- RB-2
              |
              |
             B-3
              |
              |
      RB-4 ---+

Moreover, there should be nothing problematic about this 
topology either as it will look to the RBridges like this:

      RB-1 ---+--- RB-2
              |
              |
            RB-4

And to B-3 like this:

       H-1 ---+--- H-2
              |
              |
             B-3
              |
              |
             H-4

As you implied, the normal case is that enclosing RBridges
- like routers - will look to enclosed bridges like hosts.
I merely stated that RBridges - like hosts - can ignore any
BPDUs they receive.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org]On
--> Behalf Of Dino Farinacci
--> Sent: Wednesday, October 12, 2005 3:08 PM
--> To: rbridge at postel.org
--> Cc: rbridge at postel.org
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> 
--> >> 	I believe that many of today's bridges can be configured
--> >> to not send BPDUs on specific ports, but we do _not_ want to
--> >> rely on this.  For example, what do we do if both a bridge and
--> >> an RBridge are connected to the same port of the bridge we are
--> >> talking about (imagine a simple Hub between three+ devices)?
--> 
-->     This is like saying if you run IS-IS on an interface 
--> you should not run
-->     OSPF on the interface. And to make sure you don't the 
--> IS-IS standard
-->     states you must drop all other protocol messages. Which 
--> it does not!
--> 
--> Dino    
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->

---

From: dino at cisco.com (Dino Farinacci)
Date: Wed, 12 Oct 2005 14:46:02 -0700

>> 	No, actually, it is not like saying that.

    I think the fundamental question that needs to be answered is does an 
    RBridge network proivde a layer-2 serivce. And I think the answer should
    be yes. Therefore any frames that are sent on such a network should be 
    forwarded.

    Two bridges connected via a cable or an RBridge-based network should 
    look no different. The two bridges should be able to run STP over it and 
    decide if the ports leading to such a network are in Blocked or Forward 
    state.

    The RBridges should forward such packets like any other frames. The only
    frames that RBridges will consume and process are IS-IS packets (which
    will be multicasted on a *new MAC group address*).

Dino

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Wed, 12 Oct 2005 19:42:41 -0700

Dino,

I don't claim to understand the tradeoffs between this approach and the 
approach when BPDUs are filtered (so that they are not encapsulated 
between the rbridges like other packets).

Does anybody want to take a crack at describing what the tradeoffs might be?

If the rbridge cloud is BPDU transparent, then we will end up with a 
single, large 802.1D spanning tree across the whole network. Does or 
does this not cause more disruption when there are failures/changes in 
the rbridge core? When there are failures/changes in the far side of the 
network? (on the other side of the rbridge core)

If the rbridge cloud does not let BPDUs transit, then each edge will run 
its own 802.1D spanning tree, so the trees will be smaller. But the 
handling of rbridge failures causing the bridges to sent things to a new 
designated rbridge might be slower or at least different.

These are just off the top of my head. As I said it would be good if 
somebody could try to pull together a comparison of the pros and cons of 
the different approaches.

    Erik