Subject: [rbridge] Time to summarize "forward or block" BPDU thread

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Tue, 18 Oct 2005 16:50:57 -0300

Peter,

	Privately I agree strongly with your first statement and
would extend it to include understanding of STP, bridge learning
and a slew of other things.  I have this understanding from my 
days working at Cabletron, and I suspect that a few of the other
people in this discussion do as well.  But I don't think it is
ever going to be true generally in this venue.  And this was why 
I questioned the wisdom of trying to do this in the IETF - and 
especially trying to do it in the IETF in the Internet Area.

	I also want to thank you for fielding Joe's questions in
the last few days.  I have been unable to get connected to my
company network (and it's Exchange server) for the last couple
days...

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org]On
--> Behalf Of Peter Ashwood-Smith
--> Sent: Sunday, October 16, 2005 9:10 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] Time to summarize "forward or block" 
--> BPDU thread
--> 
--> 
--> 
-->   This lack of understanding of the DRs seems to be the 
--> cause of a lot
--> of this debate. 
--> 
-->   Also, the 'problems' that people are attributing to 
--> blocking and not
--> processing BPDUs [BLOCK] are also 'problems' when no STP is running.
--> In the case where two broadcast domains are rbridged 
--> together in such a
--> way
--> as to create a loop, the DR mechanism will detect and 
--> prevent it, so it
--> works
--> even when BPDUs are not present. 
--> 
-->   So far the only reason I can think of to allow BPDUs to 
--> passively pass
--> is for migration purposes. To keep the tree from changing 
--> 'just yet' but
--> it certainly won't speed anything up, fix anything or do 
--> more to prevent
--> loops than blocking will.
--> 
-->   Peter Ashwood-Smith
--> 
--> > -----Original Message-----
--> > From: rbridge-bounces at postel.org 
--> > [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
--> > Sent: Sunday, October 16, 2005 8:46 PM
--> > To: saikat at seas.upenn.edu; Developing a hybrid router/bridge.
--> > Subject: Re: [rbridge] Time to summarize "forward or block" 
--> > BPDU thread
--> > 
--> > 
--> > The scenario you mention is where there is temporarily 
--> two Designated 
--> > RBridges (DRs), because
--> > two links were merged.
--> > 
--> > The DRs will notice this when they start seeing each other's 
--> > IS-IS Hello 
--> > messages, and that
--> > will break the loop.
--> > 
--> > I don't think this case is that much of a problem, and 
--> > certainly would 
--> > not be helped by trying to run a big
--> > global spanning tree. The big global spanning tree would 
--> > converge much 
--> > slower than the RBridge
--> > DR election protocol would. So attempting to avoid a 
--> > temporary loop when 
--> > two bridged domains
--> > are merged, by running a big global instance
--> > of the spanning tree algorithm, will not solve the 
--> problem, and will 
--> > actually
--> > make things worse.
--> > 
--> > Radia
--> > 
--> > 
--> > 
--> > 
--> > Saikat Ray wrote:
--> > 
--> > >It is probably a standard scenario in IS-IS protocol (and 
--> > consequently 
--> > >a standard solution is known), but I was thinking that if 
--> > the RBridges 
--> > >disregards BPDUs entirely, then in some situations loops may 
--> > form for 
--> > >some period. For example, suppose $T_1$ and $T_2$ are 
--> disjoint trees 
--> > >formed entirely by legacy elements. $R_1$ and $R_2$ are the 
--> > designated 
--> > >RBridges for the "links" $T_1$ and $T_2$, respectively. At 
--> > this point, 
--> > >there is no loop in the system. Now suppose that a physical 
--> > link (or a 
--> > >legacy bridge) is added that connects a legacy bridge of 
--> $T_1$ to a 
--> > >legacy bridge of $T_2$. This addition will trigger a new 
--> > Spanning tree 
--> > >computation, which will result into a single spanning tree 
--> > that spans 
--> > >the nodes of $T_1$ and $T_2$. At this point, effectively the 
--> > RBridges 
--> > >$R_1$ and $R_2$ are connected by a single "link" and until 
--> > one of the 
--> > >RBridge gets "de-designated", there would exist a loop. Two 
--> > questions 
--> > >arise in my mind: (i) how fast would that "de-designation" 
--> > process be? 
--> > >And (ii) would it be useful (i.e. would it accelerate the 
--> > convergence) 
--> > >if RBridges "listen" to the BPDUs?
--> > >
--> > >-----Original Message-----
--> > >From: rbridge-bounces at postel.org 
--> > [mailto:rbridge-bounces at postel.org] On 
--> > >Behalf Of Radia Perlman
--> > >Sent: Sunday, October 16, 2005 7:12 PM
--> > >To: Developing a hybrid router/bridge.
--> > >Subject: [rbridge] Time to summarize "forward or block" 
--> BPDU thread
--> > >
--> > >It looks like this thread was discussed with two 
--> different subject
--> > >lines, and it's also
--> > >gone on long enough it's time for someone to summarize it.
--> > >
--> > >I strongly believe that things will be more stable if 
--> RBridges do NOT
--> > >forward BPDUs...that
--> > >we decouple the protocols.
--> > >
--> > >That TRILL is kind of like a layer between bridging and routing.
--> > >
--> > >If RBridges do not forward BPDUs, then whether or not 
--> the TRILL link
--> > >state protocol is
--> > >converged, it won't affect the little spanning tree inside a 
--> > particular 
--> > >bridged segment.
--> > >
--> > >That way, the little spanning trees will converge as quickly as 
--> > >possible
--> > >(because it's small),
--> > >and cannot possibly be disrupted by RBridges wormholing BPDUs.
--> > >
--> > >I do not understand the reasons why people want to 
--> forward BPDUs. I
--> > >think the arguments (which
--> > >I may not be presenting fairly because I don't 
--> understand them) are:
--> > >a) you'll get a more optimal combined spanning tree on which 
--> > >unknown/broadcast frames will
--> > >be sent if it is one global spanning tree, rather than little 
--> > >independent spanning trees hooked together
--> > >by the independently computed spanning tree calculated by IS-IS.
--> > >b) forwarding BPDUs, and having a global spanning tree, will 
--> > prevent loops.
--> > >
--> > >I strongly disagree with both those arguments. For a) 
--> What do people
--> > >think is more optimal about a tree
--> > >computed that way vs having independent trees inside 
--> each bridged 
--> > >island? And besides, there isn't
--> > >a single spanning tree...it's a spanning tree per 
--> ingress RBridge.
--> > >For b) no...I believe that having both the RBridge 
--> algorithm and the 
--> > >bridge algorithm feeding into
--> > >each other will create much slower convergence.
--> > >
--> > >If I haven't summarized correctly, then someone else can try 
--> > to capture
--> > >the arguments, but I do
--> > >think we should merge discussion under one subject line, 
--> and restart 
--> > >with a summary.
--> > >
--> > >Radia
--> > >
--> > >_______________________________________________
--> > >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
-->