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

From: petera at nortel.com (Peter Ashwood-Smith)
Date: Tue, 18 Oct 2005 16:16:01 -0400

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

  Unfortunately if you do it somewhere else you get the reverse
problem. Expertise at L2 but not as much understanding of L3 
protocols. 

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

  Well let's hope I did not add to the confusion.

  Peter

> 
> --
> 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
> --> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org http://www.postel.org/mailman/listinfo/rbridge
> 
>