Subject: [rbridge] loops in trill networks

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Tue, 11 Oct 2005 16:21:19 -0300

Larry,

	You've got the sense of Radia's reply reversed.  It's the
802.1 bridges that look like a single link to the RBridges.

	This is pretty much how I expected this to work.  A cloud
of 802.1 bridges MUST be completely enclosed in either RBridges
or routers. Rbridges - like routers - do not forward BPDUs.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org]On
--> Behalf Of Larry Kreeger (kreeger)
--> Sent: Tuesday, October 11, 2005 3:01 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> 
--> OK, it looks like I asked my previous question prematurely.
--> 
--> If I understand this response correctly, since an RBridge 
--> looks like a
--> single link to the 802.1 bridges, this implies that an 
--> RBridge receiving
--> a BPDU will flood the BPDU to all edge ports.
--> 
--> Now back to the previous message I sent about loops and 
--> TTL.  I think
--> this means that during an RBridge topology change, these 
--> BPDUs could get
--> duplicated as they loop around (before TTL expires).
--> 
--> How kindly will 802.1 bridges react to receiving duplicate BPDUs?
--> 
-->  - Larry
--> 
--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On
--> Behalf Of Radia Perlman
--> Sent: Tuesday, October 11, 2005 9:44 AM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> There's nothing an RBridge can do about loops consisting of just
--> bridges.
--> Which is why it's good to partition the spanning trees formed by the
--> bridges so that the remaining spanning trees are as small, 
--> and therefore
--> as stable, as possible.
--> 
--> RBridges are like routers. They sit at a layer above bridges. The
--> bridges form what looks like a single link to the RBridges. 
--> If there are
--> a bunch of bridges connecting a bunch of segments, all the RBridges
--> attached to that portion of the network see that bridged 
--> segment as a
--> single link.
--> 
--> Radia
--> 
--> Loa Andersson wrote:
--> 
--> >Oh, yes it is true ...
--> >
--> >but I thought that a trill network could consist of a 
--> mixed of rbridges
--> 
--> >and the type of bridges that exist today, if that is the 
--> case you can 
--> >possibly form the loop over only non-rbridges
--> >
--> >but I'm not up to speed on this, there might be a way to 
--> handle this 
--> >also
--> >
--> >/Loa
--> >
--> >Joe Touch wrote:
--> >  
--> >
--> >>There is, and that's what it's there for.
--> >>
--> >>Joe
--> >>
--> >>Mike Hughes wrote:
--> >>
--> >>    
--> >>
--> >>>--On 11 October 2005 15:23 +0200 Loa Andersson <loa at pi.se> wrote:
--> >>>
--> >>>
--> >>>
--> >>>      
--> >>>
--> >>>>this might be an old discussion, but it is some time 
--> since it look 
--> >>>>at it. What do we do in trill networks about transient 
--> loops, i.e. 
--> >>>>if use link state protocols there is a possibility that we have 
--> >>>>transient loops. With no TTL mechanisms those looping 
--> frames could 
--> >>>>cause quite a bit of problem.
--> >>>>        
--> >>>>
--> >>>Unless I've missed something, or things have changed 
--> overnight, there
--> 
--> >>>is a TTL provided in the SHIM header.
--> >>>
--> >>>Mike
--> >>>
--> >>>
--> >>>---------------------------------------------------------
--> ------------
--> >>>---
--> >>>
--> >>>_______________________________________________
--> >>>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: dino at cisco.com (Dino Farinacci)
Date: Tue, 11 Oct 2005 13:12:50 -0700

>> or routers. Rbridges - like routers - do not forward BPDUs.

    For the same token, should two routers connected to an RBridge network
    running IS-IS (at L3 for IP) not get their multicast frames to each other?

    Again, RBridges may be acting like routers, but they provide a single
    subnet to the edge nodes. So in this case and the BPDU case, the frames
    should be forwarded through the RBridge network.

    If this is not the case, then we are building solely a stub network.
    Is this really what we want to do?

Dino

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 11 Oct 2005 13:32:38 -0700

I don't think I'm disagreeing with what you're saying, Dino. Certainly 
if there is a layer 3 IGP
running on top of the RBridged link, then the RBridges (like any bridges 
contained in that
same IP subnet) would be forwarding the IGP messages, just like they'd 
be forwarding
anything they see as data packets traversing the "link".

As for providing glue to two broadcast domains in order to merge 
them...yes, an RBridged "campus"
could be used to tunnel packets from the two broadcast domains in order 
to merge them.

But in general an RBridge would not forward a native BPDU. It would 
recognize it as something
it shouldn't forward. Because RBridges intend to make the spanning trees 
smaller. But if someone
really wanted to glue the domains together, the BPDU could traverse the 
RBridges by being
tunneled and directed, as a data packet, to something on the other side.

Perhaps the right way to think of it is that a bunch of segments
connected with any mixture of RBridges and bridges would provide
the same functionality as today would be provided by those segments 
connected with bridges.
But it would just be safer, and more efficient (better paths, allow for 
path splitting).

Radia

Dino Farinacci wrote:

>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>  
>

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 11 Oct 2005 14:02:25 -0700

Gray, Eric wrote:
> or routers. 

I was expecting that to say "or there will be little or no benefit from
the rbridges" - i.e., topology restrictions can't be enforced per se if
we're expecting plug-and-play.

> Rbridges - like routers - do not forward BPDUs.

Let me propose a question. Let's say an rbridge campus looks like a
single giant bridge (humor me).

There are two cases:

	- the bridge participates in BPDU

	- the bridge does not participate in BPDU

Is it possible in existing systems to have a bridge that does not
participate in BPDU? Wouldn't this end up creating loops?

Joe

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 11 Oct 2005 14:38:16 -0700

RBridges will not participate in BPDUs. They will drop them.

It is possible to have a bridge that "does not participate" (some bridges
allow you to "turn off the spanning tree"), but in that case, the bridge
would forward a BPDU without processing it.

Bridges that do "participate in BPDUs" don't simply forward them. 
Instead they absorb them, and generate
their own, on links for which they are Designated Bridge.

RBridges will neither forward BPDUs, nor generate their own BPDUs.

In contrast, a bridge will either have spanning tree turned off (in 
which case it will forward all BPDUs on
all ports without processing them) or turned on (in which case it will 
process the BPDUs in order to
determine its distance to the Root bridge, and in order to determine 
which links it should be DB on,
and for those links, to generate its own BPDU).

Radia

>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDTChhE5f5cImnZrsRAkAqAKCrkBhoqAYQsRB1/W1OlhWtuOlg0QCgyfj7
>+kCndWeVdgjyigTPYUF4U3Y=
>=wt7Z
>-----END PGP SIGNATURE-----

---

From: dino at cisco.com (Dino Farinacci)
Date: Tue, 11 Oct 2005 17:10:23 -0700

>> could be used to tunnel packets from the two broadcast domains in order 

    Yes, agree.

>> it shouldn't forward. Because RBridges intend to make the spanning trees 

    So we have to put special checks in the hardware forwarding plane? I
    would rather not put this in the architecture and just document that
    bridges should not send BPDUs on links where rBridges exist. Just like
    bridges don't generally send BPDUs on host ports today.

Dino