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

From: petera at nortel.com (Peter Ashwood-Smith)
Date: Sun, 16 Oct 2005 21:10:16 -0400

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

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 17 Oct 2005 05:17:48 -0700

>   This lack of understanding of the DRs seems to be the cause of a lot

IMO, it's the belief that there will only ever be one DR or DR-like
(BLOCKing) device. I agree that this all works when it works.

> processing BPDUs [BLOCK] are also 'problems' when no STP is running.

'problems'? (why the quotes?)

OK, let's just shut off spanning tree in bridges and it all works just
fine now?

Now I'm *really* confused.

AFAICT, this all works when there is at most one rbridge campus in an L2.

WHEN (note the use of 'when', not 'if', since there's *nothing* that can
be done to enforce this) this isn't the case, the following problems arise:

	a) there is no way to detect the error

	b) loops *will* occur

If we want to say "BLOCK *MAY* work, but *MAY* silently fail", and
"PARTICIPATE and TRANSPARENT will always work with current standards",
that's fine (and, AFAICT, true), but I also don't see how we pick BLOCK
as a default in that case.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20051017/4d8444d5/signature.bin

---

From: saikat at seas.upenn.edu (Saikat Ray)
Date: Mon, 17 Oct 2005 08:31:24 -0400

[Saikat] I think that the assumption (definition) is that if two RBridges
are connected directly (i.e. no IP router in between), then they are parts
of a single campus, thus must talk to each other. If that is true, then how
would you have more than one campuses that are not separated by an IP
router?

---

From: harald at alvestrand.no (Harald Tveit Alvestrand)
Date: Mon, 17 Oct 2005 16:05:08 +0200

> 	a) there is no way to detect the error

You know, I really can't tell whether this is true or not without looking 
at the protocol specification that says how the RBridges detect each other.

Should this discussion wait for the drafts to come out?

                 Harald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://www.postel.org/pipermail/rbridge/attachments/20051017/ee23ef6f/attachment.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 17 Oct 2005 07:22:17 -0700

> would you have more than one campuses that are not separated by an IP

You won't - the rbridge campuses will merge.

But we're the IETF, and we're making 'rbridges', which will BLOCK.

Let's say the IEEE decides to allow another group to make 'sbridges',
which also decide to BLOCK.

Now you can have an rbridge and an sbridge in the same L2 (how do you
know you don't?). They form an undetectable, uncorrectable loop.

--

I.e. - this all works only if everyone plays by OUR rules. Since we're
NOT the IEEE, how is it that we can decide to create a protocol that
relies on us being the ONLY exception?

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20051017/46002920/signature-0001.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 17 Oct 2005 07:26:40 -0700

Harald Tveit Alvestrand wrote:
> You know, I really can't tell whether this is true or not without
> looking at the protocol specification that says how the RBridges detect
> each other.
> 

As someone trying to write the drafts, I'm trying to understand the
terminology that will determine this.

I have a MUCH better idea of how to explain things now - whether I agree
with them at all levels or not, so this discussion IS helping, FWIW.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20051017/f9925e75/signature.bin