[rbridge] loops in trill networks

[Peter Ashwood-Smith]

Agreed, this is why I said it is a SHOULD v.s. a MUST.

Peter

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Radia Perlman
Sent: Thursday, October 13, 2005 4:06 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] loops in trill networks


I'm travelling and not necessarily following this whole thread.

However...I think it actually would work to have RBridges forwarding 
spanning tree messages. It would
result in lots of little trees, partitioned because data traffic must 
not be forwarded mindlessly along
that super-tree, but all the little trees would think the same ID was 
Root bridge.

I think this is suboptimal, since the larger the spanning tree, the 
slower convergence would be.
So I think it's a lot better to have RBridges not forward spanning tree 
messages, and keep the
bridge spanning trees really separate.

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

Radia



Michael Smith (michsmit) wrote:

> 
>
>  
>
>>-----Original Message-----
>>From: rbridge-bounces at postel.org
>>
>>Dino,
>>
>>	The argument that an RBridge network provides a layer 2
>>service therefore any frames that are presented should be 
>>forwarded is a non sequitur.
>>
>>	This is not even true of bridges now.  Conditions under
>>which a bridge "should" forward frames are somewhat 
>>restricted, even if those conditions are typically satisfied 
>>under steady-state conditions, for most frames.  There are 
>>plenty of examples of situations in which a bridge must not 
>>forward frames and other in which a bridge should not forward frames.
>>    
>>
>
>For the most part, bridges only terminate their own control protocols, 
>link layer protocols, and local management traffic.  Since the rbridge 
>doesn't participate in STP, I see a valid argument that this protocol 
>should be passed.  This is basically what an 802.1ad bridge does, it 
>doesn't participate in the customer STP and simply passes the customer 
>BPDUs through and everything works fine.  On the other hand, since the 
>goal is to provide an alternative to spanning tree, this would imply 
>that the entire network will run both rbridging control plane and STP 
>until it is fully upgraded to rbridges.  If STP is terminated at the 
>rbridge, there would be incremental benefit of upgrading the network 
>with rbridges by localizing STP as rbridges are incrementally deployed.

>Personally, I feel passing or terminating STP can be equally justified 
>(and if this is used in the Metro space, we could end up doing both).
>
>Michael
>
>  
>
>>--
>>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 5:46 PM
>>--> To: rbridge at postel.org
>>--> Cc: rbridge at postel.org
>>--> Subject: Re: [rbridge] loops in trill networks
>>--> 
>>--> 
>>--> >> 	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
>>--> _______________________________________________
>>--> rbridge mailing list
>>--> rbridge at postel.org http://www.postel.org/mailman/listinfo/rbridge
>>--> 
>>_______________________________________________
>>rbridge mailing list
>>rbridge at postel.org http://www.postel.org/mailman/listinfo/rbridge
>>
>>    
>>
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org http://www.postel.org/mailman/listinfo/rbridge
>  
>

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