Subject: [rbridge] RBridge/bridge interaction

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

Guillermo,

	I think the point is that coordination between bridges
and RBridges means at least RBridges have to be aware of the
bridges.  I say this because having bridges be aware of the
RBridges - at least as RBridges - is not an option.

	Having even the RBridges being necessarily aware of all
bridges is unnecessary and would therefore add complexity to
RBridges.  If you would like to make the point that the root
election process is not complicated, first I would disagree 
(because - minimally - it adds complexity to a configuration 
process, which is something we're trying to avoid) and second
I would point out that any complexity that is unecessary is a
complication that should be avoided.

	The processes of IS-IS and multicast DR election are, of
course, completely independent of the existence of bridges.

--
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 8:26 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] RBridge/bridge interaction
--> 
--> 
--> I agree suboptimality is not the key issue, but 
--> coordination between STP 
--> and RBridges  regarding DR election (faster DR election 
--> IMMO, although I 
--> know nothing about IS-IS DR election) . Path optimization is a plus.
--> Guillermo
--> 
--> Gray, Eric wrote:
--> 
--> >Guillermo,
--> >
--> >	Actually, the thing about a spanning tree is that 
--> frames entering
--> >the tree will reach every node.  Hence the result of 
--> having an RBridge
--> >be something other than the root of the local spanning 
--> tree would be 
--> >that frame delivery might be sub-optimal.  In fact, it is not even
--> >necessary for the R-Bridge to be directly connected to the 
--> root of a
--> >local spanning tree.
--> >
--> >	That's part of the reason why an RBridge does not need to be a
--> >part of the local STP.
--> >
--> >	Given the way that spanning tree works in general, sub-optimal 
--> >delivery of frames would not be something new.  Having th
--> >
--> >--
--> >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 2:33 AM
--> >--> To: Radia.Perlman at Sun.COM; Developing a hybrid router/bridge.
--> >--> Subject: Re: [rbridge] RBridge/bridge interaction
--> >--> 
--> >--> 
--> >--> 
--> >--> 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 23:16:01 +0200

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. 
This effort is peanuts if you compare with VLAN configuration, and it  
has been accepted without any opposition.
The second point is how fast is the DR election process is actually.
The third point is that "being aware of bridges" just means that 
RBridges participate in the root election process, where only the 
RBridges will apply to be root. Not a real issue. It is much more 
complex to handle per VLAN spanning trees. So it  is only an  apparent 
complexity.  My feeling is that the "uncontrolled sbridge islands" will 
sooner or later require control. I understand that now is not wellcome 
to include the bridges in the design. Although we might like to make the 
RBridges fully independent of bridges, the whole is a system and must be 
slightly coordinated or we risk more unpredictable behaviour of specific 
situations that will at the end require more tight control of the 
spanning trees.
I now realiza that the difference in view probably derives from the fact 
that Radia perhaps tend to think on STP, that provides  timer-based 
convergence (slow), and I tend to think in RSTP (faster  than IS-IS I 
presume). I might agree that both situations are different and STP is 
not an alternative due to slow convergence, but the current IEEE 
standard is RSTP, so it will be dominant in the near term in networks, 
decisions should be based on RSTP performance.
Guillermo

Gray, Eric wrote:

>Guillermo,
>
>	I think the point is that .coordination between bridges
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Fri, 21 Oct 2005 14:48:23 -0700

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

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Sat, 22 Oct 2005 00:01:01 +0200

Right. In this way both views are covered. I fully agree.
Guillermo