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

[Radia.Perlman@sun.com]

The simplest thing would just be to have RBridges send hellos fairly often all the time.
It would be a parameter, so people could set it.

One could use hints like topology change flags, but I'm not sure how helpful that
would be. It wouldn't hurt, but I don't think there would be that much overhead to
having hellos every, say, second.

Radia


----- Original Message -----
From: Saikat Ray <saikat at seas.upenn.edu>
Date: Monday, October 17, 2005 6:46 am
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread

> First of all, I totally agree with you that there should be 
> multiple small
> spanning trees glued by RBridge networks instead of a global huge 
> spanningtree. My point was slightly different, though. In the 
> mechanism you pointed
> out (hearing hallos from other RBridges), the amount of time a 
> temporaryloop persists would depend on the time interval between 
> hallo messages sent
> by RBridges (what is the default value?). If two RBridges are 
> connected by a
> physical link, then this is probably the only way the RBridges can 
> detectthe loop. However, if the underlying "link" is actually a 
> bridged network
> (spanning tree), then the RBridges would have more information. For 
> example,when RBridges see topology change BPDU's (or something 
> similar), then they
> may deduct the possibility of a loop formation and they may 
> increase the
> sending rate of hallo messages. In short, the RBridges are 
> privileged to be
> in a position to make additional observations (BPDUs) and, in my 
> humbleopinion, they ought to use it.
> 
> -----Original Message-----
> From: Radia Perlman [Radia.Perlman at sun.com] 
> 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", 
> therewould
> >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 [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
>