Subject: [rbridge] RBridge/bridge interaction

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Tue, 25 Oct 2005 11:44:13 -0300

Guillermo,

	Thank-you for the suggested text!

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org]On
--> Behalf Of Guillermo Ib??ez
--> Sent: Tuesday, October 25, 2005 5:56 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] RBridge/bridge interaction
--> 
--> 
--> Eric,  Radia :
--> 
--> According to Eric suggestion to include text, I have used 
--> Radia?s text 
--> (as clarifying as usual) to describe it and added a final 
--> sentence (not 
--> mandatory) on the default value for RBridges. Feel free to 
--> "improve" it.
--> Guillermo
-->  
--> 
--> RBridge indirect participation in bridged island spanning tree. 
--> ---------------------------------------------------------------
--> RBridges by default do not participate in spanning tree in 
--> other way than ignoring received BPDUs. It is an objective 
--> of RBridge specification to be independent of bridges 
--> specifications as much as possible.   
-->  However it may be convenient for RBridges in some 
--> circumstances to participate in the spanning tree and 
--> contend to be root bridge of the spanning tree formed in 
--> the bridged island they are attached to. In these cases it 
--> is possible to build a device that's logically the same as 
--> a bridge glued onto an RBridge. The following schema applies:
--> 
-->                         ?-----------?
-->        bridged island-----B1----RB1 ?
-->                         ?-----------?
--> 
-->                         RBridge/bridge box
--> 
--> where B1 is a bridge with two ports...a pt-to-pt link to 
--> RBRidge RB1, and a link to the bridged LAN. The "RB1" 
--> portion of this box acts as an standard RBridge, it neither 
--> forwards, nor initiates spanning tree messages. The "B1" 
--> portion acts as two-port standard 802.1D bridge, and does 
--> participate in spanning tree. Its priority for root 
--> election can be set in the standard way. To minimize 
--> configurafion, it may be convenient in some implementations 
--> to make the standard B1 bridge priority a function of the 
--> configurable RBridge priority for IS-IS Designated RBridge 
--> election. In this way Designated RBridge will participate 
--> and contend (as B1) to be elected also as root bridge of 
--> the bridged island and only one priority configuration is required. 
--> 
--> If (in environments using such implementations) the default 
--> bridge priority for B1 is lower than standard bridge 
--> priority, by default RBridges/bridges like B1 shown will 
--> become roots of their bridged islands, contending only with 
--> other RBridges connected to same island for root election. 
--> 
--> 
--> 
--> 
--> Gray, Eric wrote:
--> 
--> >I think we should leave that sort of determination to the
--> >supposed wisdom of the successful implementer. But I won't
--> >object to text along these lines if someone else wants to
--> >write it...
--> >
--> >--
--> >Eric
--> >
--> >--> -----Original Message-----
--> >--> From: rbridge-bounces at postel.org 
--> >--> [mailto:rbridge-bounces at postel.org]On
--> >--> Behalf Of Radia Perlman
--> >--> Sent: Saturday, October 22, 2005 4:59 PM
--> >--> To: Developing a hybrid router/bridge.
--> >--> Subject: Re: [rbridge] RBridge/bridge interaction
--> >--> 
--> >--> 
--> >--> And another thought. Although I don't think we should 
--> >--> include the notion of
--> >--> a combined bridge/RBridge in the spec for RBridges,
--> >--> just a suggestion for anyone that wants to build this beast...
--> >--> 
--> >--> It would be nice to minimize configuration, so especially 
--> >--> if the reason 
--> >--> for making a
--> >--> bridge/RBridge is to
--> >--> make an RBridge have higher priority for being bridge 
--> spanning tree 
--> >--> Root, have the priority for
--> >--> bridge Root be a function of the RBridge IS-IS DR priority, 
--> >--> so you only 
--> >--> have to set one
--> >--> of them.
--> >--> 
--> >--> We don't have to debate this, since this if it's not 
--> in the RBridge 
--> >--> spec, vendors can
--> >--> do whatever they want. But it's perhaps good to have 
--> >--> suggestions posted 
--> >--> publicly.
--> >--> 
--> >--> Radia
--> >--> 
--> >--> 
--> >--> 
--> >--> Peter Ashwood-Smith wrote:
--> >--> 
--> >--> >Likewise.
--> >--> >
--> >--> >  
--> >--> >
--> >--> >>-----Original Message-----
--> >--> >>From: rbridge-bounces at postel.org 
--> >--> >>[mailto:rbridge-bounces at postel.org] On Behalf Of Gray, Eric
--> >--> >>Sent: Friday, October 21, 2005 6:16 PM
--> >--> >>To: 'Developing a hybrid router/bridge.'
--> >--> >>Subject: Re: [rbridge] RBridge/bridge interaction
--> >--> >>
--> >--> >>
--> >--> >>I also agree that this is a quite feasible approach.
--> >--> >>
--> >--> >>--
--> >--> >>Eric
--> >--> >>
--> >--> >>--> -----Original Message-----
--> >--> >>--> From: rbridge-bounces at postel.org
--> >--> >>--> [mailto:rbridge-bounces at postel.org]On
--> >--> >>--> Behalf Of Guillermo Ib??ez
--> >--> >>--> Sent: Friday, October 21, 2005 6:01 PM
--> >--> >>--> To: Developing a hybrid router/bridge.
--> >--> >>--> Subject: Re: [rbridge] RBridge/bridge interaction
--> >--> >>--> 
--> >--> >>--> 
--> >--> >>--> Right. In this way both views are covered. I 
--> fully agree. 
--> >--> >>Guillermo
--> >--> >>--> 
--> >--> >>--> Radia Perlman wrote:
--> >--> >>--> 
--> >--> >>--> >Actually, here's a suggestion that may make us 
--> all happy.
--> >--> >>--> >
--> >--> >>--> >Keep the design of RBridge independent of bridges. 
--> >--> >>RBridges do not
--> >--> >>--> >participate
--> >--> >>--> >in spanning tree (other than throwing away BPDUs).
--> >--> >>--> >
--> >--> >>--> >However, to get the functionality that Guillermo
--> >--> >>--> wants....allow someone
--> >--> >>--> >to build a device that's logically the
--> >--> >>--> >same as a bridge glued onto an RBridge. To the 
--> rest of the
--> >--> >>--> world it
--> >--> >>--> >would look
--> >--> >>--> >like this:
--> >--> >>--> >
--> >--> >>--> >bridged island----B1----RB1
--> >--> >>--> >
--> >--> >>--> >where B1 is a bridge with two ports...a pt-to-pt link to
--> >--> >>--> RBRidge RB1,
--> >--> >>--> >and a link to the
--> >--> >>--> >bridged LAN.
--> >--> >>--> >
--> >--> >>--> >The "RB1" portion of this box does what the architecture
--> >--> >>--> of an RBridge
--> >--> >>--> >does...it neither
--> >--> >>--> >forwards, nor initiates spanning tree messages.
--> >--> >>--> >
--> >--> >>--> >However, the "B1" portion of the box acts like a vanilla
--> >--> >>--> bridge, and
--> >--> >>--> >does participate in
--> >--> >>--> >spanning tree. And it can be configured to have whatever
--> >--> >>--> priority people
--> >--> >>--> >want.
--> >--> >>--> >
--> >--> >>--> >If it's commercially important for RBridges to have the
--> >--> >>--> capability of
--> >--> >>--> >participating in
--> >--> >>--> >the bridge protocol, it can be done this way without
--> >--> >>--> defining it into
--> >--> >>--> >either the RBridge
--> >--> >>--> >or bridge functionality.
--> >--> >>--> >
--> >--> >>--> >Radia
--> >--> >>--> >
--> >--> >>--> >
--> >--> >>--> >
--> >--> >>--> >Guillermo Ib??ez wrote:
--> >--> >>--> >
--> >--> >>--> >  
--> >--> >>--> >
--> >--> >>--> >>Root bridge planning is something required in campus
--> >--> >>--> networks, it just
--> >--> >>--> >>means configure the 16 bit priority of the 
--> preffered root
--> >--> >>--> bridge (and
--> >--> >>--> >>perhaps a root reserve) with a low enough 
--> value under the
--> >--> >>--> default value.
--> >--> >>--> >>
--> >--> >>--> >>    
--> >--> >>--> >>
--> >--> >>--> >
--> >--> >>--> >
--> >--> >>--> >_______________________________________________
--> >--> >>--> >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
--> >--> >  
--> >--> >
--> >--> 
--> >--> _______________________________________________
--> >--> 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
-->