Subject: [rbridge] RBridge/bridge interaction

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Fri, 21 Oct 2005 14:06:49 -0300

Guillermo,

	I had to think about what Radia was saying to realize
that she is not objecting to merging one RBridge campus with
another.  If I understand correctly, what she is referring 
to is merging spanning trees between two islands (or pockets)
of 802/Ethernet bridges separated by a R-Bridge campus.

	There's nothing to resolve, if the RBridge campus does 
not participate in STP, or transparently pass it through the
campus from one island to another.

	So, I suspect that we are not looking for a way to solve
the problem, since there is a way to avoid it.

--
Eric Gray

--> -----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 8:14 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] RBridge/bridge interaction
--> 
--> 
--> 
--> 
--> Radia Perlman wrote:
--> 
--> >I don't think there's any reason, even if most of the 
--> traffic on the 
--> >link comes from the DR, for the
--> >DR to be the root of the spanning tree.
--> >What would be bad is if an RBridge, participating in two bridged 
--> >islands, winds up merging
--> >the islands into a bigger island.
--> >  
--> >
--> Good point, but I think it can be solved.
--> The merging of islands can be prevented if the RBridge 
--> acting as root 
--> limits to one port maximum in the Designated Port Role of 
--> spanning tree 
--> for sbridges.
--> 
--> >The whole point is to make the bridged islands as small as 
--> possible, so 
--> >most forwarding is done
--> >protected by hop count, and with optimal routes.
--> >
--> >  
--> >
--> I'll admit that having RBridges *initiate* BPDUs
--> 
--> >to vie for being Root is not as harmful as having them 
--> *forward* BPDUs 
--> >between
--> >bridged islands (provided an RBridge is careful not to 
--> merge two islands 
--> >that would
--> >have been separate if the RBridge had just been blocking BPDUs).
--> >
--> >We shouldn't make things more complex in an attempt to 
--> come up with a 
--> >"more optimal"
--> >spanning tree within the bridged islands.
--> >  
--> >
--> 
--> >With a bidirectional tree, as happens with bridges, 
--> there's nothing 
--> >special about the Root.
--> >Also, the traffic pattern might be such that most of the 
--> traffic is 
--> >between endnodes within
--> >the island. 
--> >
--> With the client server model, dominant traffic is to and 
--> from the core 
--> layer of campus network, so I think most of the traffic will flow 
--> from/into Rbridge, not withing the islands.
--> 
--> >So there's really no reason to believe that having the 
--> >RBridge DR be the
--> >spanning tree Root will result in better performance. And 
--> is certainly 
--> >complicates things.
--> >And it also certainly is dangerous because of the 
--> potential of merging 
--> >islands.
--> >
--> >  
--> >
--> I do not think is dangerous. The merging of islands is not 
--> convenient, 
--> but it can be prevented, limiting to one port the 
--> Designated Role in the 
--> root Rbridge.
--> Guillermo
--> 
--> >Radia
--> >
--> >
--> >
--> >Guillermo Ib??ez wrote:
--> >
--> >  
--> >
--> >>I see the standard root election mechanism of spanning 
--> tree islands as 
--> >>the fastest and simpler mechanism for DR Rbridge 
--> designation. I see the 
--> >>DR Rbridge as being necessarily the ROOT bridge of  that 
--> sbridged cloud 
--> >>(or "link"). The root bridge of a standard spanning tree is the 
--> >>"natural" source and sink point for the spanning tree.  
--> To do so, the DR 
--> >>must issue BPDUs to become the root bridge.  This is part 
--> of what I 
--> >>mentioned days ago as PARTICIPATE PER PORT, but may be we 
--> should call it 
--> >>SOURCE OR SINK (participate, do not forward BPDUs, only 
--> send own BPDUs 
--> >>to contend to be the root bridge of the link).
--> >>The consequence of this DR election mechanism is that the 
--> priority 
--> >>configured at Rbridges as bridge ID would determine their 
--> also their 
--> >>election priority as DRs. I think this keep both domains 
--> coordinated 
--> >>with a single mechanism.
--> >>Guillermo
--> >>
--> >>Radia Perlman wrote:
--> >>
--> >> 
--> >>
--> >>    
--> >>
--> >>>I don't believe there should be options here.
--> >>>It should be plug and play.
--> >>>RBridges should BLOCK bridge spanning tree messages,
--> >>>and isolate the bridged islands.
--> >>>
--> >>>I absolutely do not understand what people are
--> >>>worried about with BLOCK.
--> >>>
--> >>>I suggest someone that actually thinks there is
--> >>>some reason to do anything other than drop
--> >>>spanning tree messages start a thread with
--> >>>a subject line
--> >>>"why it is good for RBridges to forward BPDUs",
--> >>>and very very carefully explain from scratch
--> >>>what the reasoning is. Not with a long
--> >>>email quoting pieces of other emails, but
--> >>>with a carefully crafted, from scratch explanation
--> >>>of what you perceive as a problem with BLOCk, and
--> >>>what the perceived benefit of ever having
--> >>>RBridges forwarding BPDUs would
--> >>>be.
--> >>>
--> >>>Oh...and there was a much earlier thread of the
--> >>>thread about other devices that might forward
--> >>>or drop BPDUs. There have always been things we
--> >>>referred to as "simple bridges" that forwarded spanning
--> >>>tree messages. I was careful to ensure that the
--> >>>spanning tree would work with such devices. Of course
--> >>>the spanning tree would not prevent a loop of all
--> >>>simple bridges, but if there was at least one spanning
--> >>>tree bridge in the middle of every possible loop, then
--> >>>there would wind up being no loops.
--> >>>
--> >>>You can think of "simple bridges" (ones that mindlessly
--> >>>forward BPDUs) as a layer below bridges. They are
--> >>>invisible to bridges. Bridges see a bunch of
--> >>>segments connected by simple bridges as a single segment.
--> >>>(Just like RBridges will see a bunch of segments connected
--> >>>by bridges as a single segment).
--> >>>
--> >>>Devices that drop BDPUs work if they are really
--> >>>layered on top of bridges, i.e., they let the
--> >>>bridges do their own thing to create isolated
--> >>>broadcast domains, and then these other devices do
--> >>>their own thing to glue these islands together.
--> >>>Like routers do. And like RBridges will do.
--> >>>
--> >>>Radia
--> >>>
--> >>>
--> >>>
--> >>>Guillermo Ib??ez wrote On 10/20/05 14:35,:
--> >>>
--> >>>
--> >>>   
--> >>>
--> >>>      
--> >>>
--> >>>>Eric,
--> >>>>
--> >>>>
--> >>>>Gray, Eric wrote:
--> >>>>
--> >>>>
--> >>>>  
--> >>>>
--> >>>>     
--> >>>>
--> >>>>        
--> >>>>
--> >>>>>Guillermo,
--> >>>>>
--> >>>>>	During the discussion, the terms TRANSPARENT, 
--> PARTICIPATE
--> >>>>>and BLOCK were used (often in upper-case, exactly as I 
--> have used
--> >>>>>them here) as if these would ultimately be options 
--> that might be
--> >>>>>supported - either as a complete set, or as some subset.  
--> >>>>>
--> >>>>>	For example, one argument was that TRANSPARENT 
--> or PARTICIPATE 
--> >>>>>might be used, but BLOCK should not.
--> >>>>>
--> >>>>>	Also, at certain points in the discussion, 
--> there was some
--> >>>>>thought that these might be modes that applied at 
--> different states
--> >>>>>during transitions in a network.
--> >>>>>
--> >>>>>	From a practical stand-point - however - it 
--> would be best if
--> >>>>>we did not have to support all of these, either as 
--> options, or as
--> >>>>>modes.  The mere fact that they were brought up does 
--> not mean we
--> >>>>>are committed to including them.
--> >>>>>
--> >>>>>
--> >>>>>
--> >>>>>    
--> >>>>>
--> >>>>>       
--> >>>>>
--> >>>>>          
--> >>>>>
--> >>>>Agreed
--> >>>>
--> >>>>
--> >>>>  
--> >>>>
--> >>>>     
--> >>>>
--> >>>>        
--> >>>>
--> >>>>>	In particular, if we start talking about - for 
--> instance -
--> >>>>>having a per-interface option for all of these choices 
--> (and maybe
--> >>>>>others as well), then we either need to analyze proposals for 
--> >>>>>architecture and design to ensure that the "right things" will
--> >>>>>happen when an arbitrary combination of all of these 
--> options is in 
--> >>>>>effect, or we need to define caveats for network 
--> operators to avoid 
--> >>>>>specific combinations of options.  For example, we may 
--> need to say
--> >>>>>that the same option must be set throughout the 
--> network or this and
--> >>>>>that will (or may) happen.  That kind of design begs 
--> configuration
--> >>>>>errors to occur.
--> >>>>>
--> >>>>>
--> >>>>>
--> >>>>>    
--> >>>>>
--> >>>>>       
--> >>>>>
--> >>>>>          
--> >>>>>
--> >>>>If you refer as configuration options per interface to 
--> the PARTICIPATE 
--> >>>>PER PORT mode as an option per port, it is not the 
--> case. If  you refer 
--> >>>>to being the DR the root bridge of the sbridge domain, 
--> I think it must 
--> >>>>be analyzed as a real alternative, even if it is not 
--> the default 
--> >>>>configuration.
--> >>>>
--> >>>>
--> >>>>  
--> >>>>
--> >>>>     
--> >>>>
--> >>>>        
--> >>>>
--> >>>>>	In this case, the fact that we want to make the 
--> solution plug
--> >>>>>and play means that we can reduce the potential for 
--> disaster if we
--> >>>>>choose (and require) a specific default set of option 
--> choices.  If
--> >>>>>we can get away with it, however, we should simply 
--> avoid options.
--> >>>>>
--> >>>>>
--> >>>>>
--> >>>>>    
--> >>>>>
--> >>>>>       
--> >>>>>
--> >>>>>          
--> >>>>>
--> >>>>Agreed, but not for the root bridge problem because is 
--> a real, practical 
--> >>>>issue.
--> >>>>
--> >>>>
--> >>>>  
--> >>>>
--> >>>>     
--> >>>>
--> >>>>        
--> >>>>
--> >>>>>	While having these same values as modes that 
--> apply during 
--> >>>>>certain transitional states is cleaner, it would 
--> require a well-
--> >>>>>defined finite state-machine (not a particular problem) and a 
--> >>>>>genuine need for these behaviors under certain 
--> circumstances.  It
--> >>>>>may well be the case that this turns out to be true.
--> >>>>>
--> >>>>>
--> >>>>>
--> >>>>>    
--> >>>>>
--> >>>>>       
--> >>>>>
--> >>>>>          
--> >>>>>
--> >>>>RSTP port state machines are there, may be they should 
--> be taken into 
--> >>>>consideration to make a consistent and integrated, but 
--> not interwoven, 
--> >>>>design for Rbridges that work with RSTP trees.
--> >>>>Guillermo. 
--> >>>>
--> >>>>
--> >>>>  
--> >>>>
--> >>>>     
--> >>>>
--> >>>>        
--> >>>>
--> >>>>>--
--> >>>>>Eric
--> >>>>>
--> >>>>>--> -----Original Message-----
--> >>>>>--> From: rbridge-bounces at postel.org 
--> >>>>>--> [mailto:rbridge-bounces at postel.org]On
--> >>>>>--> Behalf Of Guillermo Ib??ez
--> >>>>>--> Sent: Thursday, October 20, 2005 4:19 PM
--> >>>>>--> To: Developing a hybrid router/bridge.
--> >>>>>--> Subject: Re: [rbridge] RBridge/bridge interaction
--> >>>>>--> 
--> >>>>>--> 
--> >>>>>--> I volunteer for some work on the capture, although my 
--> >>>>>--> english might be 
--> >>>>>--> not too understandable.  From what date should the capture 
--> >>>>>--> to be done?
--> >>>>>--> 
--> >>>>>--> Regarding PARTICIPATE PER PORT:
--> >>>>>--> Although I do not have a clear position, and it 
--> requires detailed 
--> >>>>>--> analysis, it seems to me that PARTICIPATE PER PORT is 
--> >>>>>--> better integrated 
--> >>>>>--> with spanning tree, while maintaining the basic decoupling 
--> >>>>>--> that BLOCK 
--> >>>>>--> provides.
--> >>>>>--> With PARTICIPATE PER PORT it would be possible to 
--> force the elected 
--> >>>>>--> Rbridge to become the sbridge root of the bridged 
--> domain by 
--> >>>>>--> modifying 
--> >>>>>--> its bridge priority when it gets elected as Designated by 
--> >>>>>--> IS-IS (this 
--> >>>>>--> could be an optimization). In this way the path length is 
--> >>>>>--> minimum  from 
--> >>>>>--> all bridges of bridged domain to the DR.
--> >>>>>-->  
--> >>>>>--> 
--> >>>>>--> Erik Nordmark wrote:
--> >>>>>--> 
--> >>>>>--> >We've had some useful discussion on this mailing list.
--> >>>>>--> >It would be good if somebody can capture the results 
--> >>>>>--> (perhaps as a long 
--> >>>>>--> >email) that we can fold into the draft(s) later. 
--> Any volunteers?
--> >>>>>--> >
--> >>>>>--> >I don't know if we will have additional issues in this 
--> >>>>>--> space or that it 
--> >>>>>--> >otherwise makes sense devoting agenda time to it 
--> in Vancouver.
--> >>>>>--> >
--> >>>>>--> >For instance, while I'm convinced that BLOCK works, I 
--> >>>>>--> wonder if there is 
--> >>>>>--> >something in PARTICIPATE PER PORT that can make the 
--> >>>>>--> interaction work better.
--> >>>>>--> >
--> >>>>>--> >Two cases to consider:
--> >>>>>--> >1. The elected forwarder dies and a new one gets elected. 
--> >>>>>--> How quickly 
--> >>>>>--> >can packets sent by stations in the bridged cloud fail 
--> >>>>>--> over to go to the 
--> >>>>>--> >new elected forwarder?
--> >>>>>--> >
--> >>>>>--> >  
--> >>>>>--> >
--> >>>>>--> My understanding is that if the forwarded dies, 
--> the sbridge domain 
--> >>>>>--> should handle  it as  a topology change 
--> notification, tables   of 
--> >>>>>--> sbridges should be  flushed according to the spanning tree 
--> >>>>>--> rules, so the 
--> >>>>>--> sbridge domain must know the DR will not forward frames as 
--> >>>>>--> it used to. 
--> >>>>>--> It seems Rbridge shall issue a Topology Change 
--> Notification 
--> >>>>>--> via sbridge 
--> >>>>>--> domain to flush MAC tables. Is a fast analysis, probably I 
--> >>>>>--> miss details.
--> >>>>>-->  
--> >>>>>--> 
--> >>>>>--> >2. We have two separate bridged domains, each 
--> with their elected 
--> >>>>>--> >forwarder. Somebody connects the two bridged domains 
--> >>>>>--> together with a 
--> >>>>>--> >wire. This can cause a temporary loop until a single 
--> >>>>>--> elected forwarder 
--> >>>>>--> >is picked by the RBridges.
--> >>>>>--> >
--> >>>>>--> >  
--> >>>>>--> >
--> >>>>>--> In this case the PARTICIPATE PER PORT seems superior, as 
--> >>>>>--> the two merged 
--> >>>>>--> bridged domains will merge their spanning trees into one 
--> >>>>>--> and both DRs 
--> >>>>>--> will compete to be the root of the merged tree, 
--> this mechanism will 
--> >>>>>--> likely be faster (via RSTP fast transit to 
--> forwarding state 
--> >>>>>--> over the 
--> >>>>>--> bridged domain)  than  Designation to select the 
--> unique DR. 
--> >>>>>--> In other 
--> >>>>>--> words , the mechanism of root election in sbridge could be 
--> >>>>>--> used to help 
--> >>>>>--> in DR designation and/or viceversa.
--> >>>>>--> So I see in PARTICIPATE PER PORT, some coupling between DR 
--> >>>>>--> status and 
--> >>>>>--> root status of sbridge domain that can be used
--> >>>>>-->  to speed up convergence and coherence of both domains. It 
--> >>>>>--> seems that 
--> >>>>>--> sbridge domains should be under the control of  
--> Rbridges, but the 
--> >>>>>--> sbridge mechanims should be used by Rbridges to 
--> keep the network 
--> >>>>>--> consistency and reconfiguration capabilities of RSTP.
--> >>>>>--> Guillermo
--> >>>>>--> 
--> >>>>>-->  
--> >>>>>--> _______________________________________________
--> >>>>>--> 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
-->

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Fri, 21 Oct 2005 19:49:43 +0200

My doubt is whether the DR Designation procedure is fast and reliable enough
for reconfigurations of the islands communicating the Rbridges. Using the DR
Rbridge as root bridge and linking the DR Designated role of Rbridge to the
role of root bridge  of the link, the root bridge election at the link
could be used also as a faster and reliable mechanism for DR designation, as
in fact the function is rather similar (although new: never a root bridge
had Root port to forward and receive packets). It may sound complicated, I
think in the long term it may be more complicated for Rbridges to be DRs of
a link that they do not control.
Guillermo 

-----Mensaje original-----
De: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] En nombre
de Gray, Eric
Enviado el: viernes, 21 de octubre de 2005 19:07
Para: 'Developing a hybrid router/bridge.'
Asunto: Re: [rbridge] RBridge/bridge interaction

Guillermo,

	I had to think about what Radia was saying to realize
that she is not objecting to merging one RBridge campus with another.  If I
understand correctly, what she is referring 
to is merging spanning trees between two islands (or pockets) of
802/Ethernet bridges separated by a R-Bridge campus.

	There's nothing to resolve, if the RBridge campus does 
not participate in STP, or transparently pass it through the campus from one
island to another.

--
Eric Gray

--> >>>referred to as "simple bridges" that forwarded spanning tree 
--> >>>messages. I was careful to ensure that the spanning tree would 
--> >>>work with such devices. Of course the spanning tree would not 
--> >>>prevent a loop of all simple bridges, but if there was at least 
--> >>>one spanning tree bridge in the middle of every possible loop, 
--> >>>then there would wind up being no loops.
--> >>>You can think of "simple bridges" (ones that mindlessly forward 
--> >>>BPDUs) as a layer below bridges. They are invisible to bridges. 
--> >>>Bridges see a bunch of segments connected by simple bridges as a 
--> >>>single segment. (Just like RBridges will see a bunch of segments 
--> >>>connected by bridges as a single segment).
--> >>>>design for Rbridges that work with RSTP trees. Guillermo.
_______________________________________________
rbridge mailing list
rbridge at postel.org
http://www.postel.org/mailman/listinfo/rbridge