Subject: [rbridge] loops in trill networks

From: kreeger at cisco.com (Larry Kreeger (kreeger))
Date: Tue, 11 Oct 2005 11:52:25 -0700

This brings up another question.

What does the RBridge network look like to the 802.1 bridged network.
Does the RBridge network pretend it is a giant 802.1D bridge -
exchanging BPDUs at its edge ports with the 802.1 bridges and blocking
edge ports if it detects a loop?  What happens to the BPDUs sent by
802.1 bridges to the RBridges?

 - Larry 

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Joe Touch
Sent: Tuesday, October 11, 2005 8:26 AM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] loops in trill networks

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

The conventional bridges have a spanning tree, which is what already
prevents such loops currently.

Think of the path between two nodes (hosts, routers, etc. - anything
that sources/sinks L2 frames) as having three components (at most):

node--->(bridgepath1)----(rbridgepath)----(bridgepath2)--->node

the ingress (bridgepath1) and egress (bridgepath2) conventional bridge
paths use spanning trees, so they can't have loops.

The rbridge uses the TTL, so it can't have a loop at its layer. Even
when it tunnels over conventional bridges ('inside' the rbridge, in a
sense), those can't have loops because they're spanning-tree.

The combination of spanning tree in all bridge paths and TTL in the
rbridge logical path prevents loops in the node-node path.

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

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 11 Oct 2005 12:11:18 -0700

RBridges do not participate in the 802.1d spanning tree. The neither 
generate
nor forward spanning tree messages.

They look to bridges
like routers do today. If you had a big 802.1d broadcast domain, and 
partitioned
it into n pieces, with the pieces connected with RBridges (and not with 
bridges),
you'd wind up with n spanning trees that did not see each other.

Radia

Larry Kreeger (kreeger) wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Loa Andersson wrote:
>  
>
>>Oh, yes it is true ...
>>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDS9mbE5f5cImnZrsRAktMAJ9MjJKSh87vJbfpJ4K0i+VDGJVRAQCdEbOH
>krcExxOH/y9ZuHOYMynTEIA=
>=3VVZ
>-----END PGP SIGNATURE-----

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 11 Oct 2005 13:34:24 -0700

Radia Perlman wrote:
> like routers do today. 

Routers stop broadcasts; if rbridges do, then ARP won't work.

I was anticipating as Larry was - that a campus would act like a single
giant bridge.

> If you had a big 802.1d broadcast domain, and
> partitioned

That seems to cause the problem above, though.

Joe

---

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

Joe...you and I are not disagreeing about the technical intent...just 
getting hung up on terminology I think.

What I mean by "n spanning trees that do not see each other" is that the 
RBridges don't glue the
802.1d spanning tree together into a single 802.1d spanning
tree with one Root Bridge, etc.

They do, however, create a single broadcast domain, and ARPs go across
the RBridges. So indeed an ARP is carried over a spanning tree, but it's 
not THE spanning tree
calculated by the 802.1d spanning tree algorithm.

As far as IP nodes go, they can't tell whether what I call a campus is 
connected via bridges,
RBridges, repeaters, or any combination. It's all just a single 
broadcast domain. All the IP
nodes connected into this campus view it as a single link, a single IP 
subnet, where all
IP nodes on that campus view each other as direct neighbors.

The only message that is special to RBridges, in terms of
layer 2 multicasts, is the BPDU. That is not forwarded by RBridges. But 
all other
layer 2 multicasts get forwarded across the broadcast domain.

The collection of RBridges, bridges, and links DO form a single 
broadcast domain, together
with a spanning tree, but it's not the spanning tree calculated by 
802.1d spanning tree. It's
instead a spanning tree (or set of trees) calculated from the link state 
database.

However, there might still be 802.1d spanning trees on what an RBridge 
would think of
as single links.

Radia

Joe Touch wrote:

>iD8DBQFDTCHQE5f5cImnZrsRAn/bAJ9mD1R9reyuHG9vECvNNVelOTva6ACfVJLk
>50SX6s3uugIlvrf0O6DZnng=
>=720Z

---

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

> getting hung up on terminology I think.

Which is important - because that's where I am in the docs ;-)

> calculated by the 802.1d spanning tree algorithm.

Won't that create possible loops?

Joe

---

From: saikat at seas.upenn.edu (Saikat Ray)
Date: Tue, 11 Oct 2005 17:25:53 -0400

Joe

[Saikat] RBridges would broadcast over a spanning tree (of the graph
consisting of the RBridges), isn't it?

---

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

Let me try explaining it a different way.

You start with one giant bridged campus. There is one spanning tree.

Then you replace some of the bridges with RBridges.

Pretend that the RBridges don't forward ANY packets.

Now the campus is likely partitioned into several pieces, let's say 5, 
with no connectivity
between the pieces.

Each piece computes its own spanning tree, with its own Root bridge. So you
have 5 independent, disconnected spanning trees.

Now think of each of those 5 pieces as a single link. The fact that each 
piece
is glued together with spanning tree with bridges is invisible outside 
that piece. So we
can stop thinking about bridges, and now only look at the next layer 
up...the RBridges.

Now we have a topology of 5 links all interconnected in some rich 
topology (not necessarily
a tree) using RBridges.

The RBridges run a link state IGP. They know how to reach each other via 
shortest paths.
They might even compute multiple paths to each other. Data packets can 
use all the links,
so the actual topology for data packet forwarding need not be loop-free. 
Just like
routing IP packets over the same topology, if you replaced the RBridges 
with IP routers
and gave each of the 5 segments its own IP subnet prefix.

Using the link state database, the RBridges also calculate a spanning 
tree among themselves, in
order to forward multicasts/pkts to unknown destinations.

This spanning tree, when forwarded from RBridge to RBridge, might 
transit a bridged segment
with its own spanning tree. But it's a different tree.

Somehow...I'm not sure this will illuminate anything.

However, 5 minutes with interactive conversation and a whiteboard and 
I'm sure if there were
any remaining confusion it could be resolved.

Radia

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 11 Oct 2005 15:38:30 -0700

> Now the campus is likely partitioned into several pieces, let's say 5, 

That's not necessarily likely. That would only occur if the network were
wired as a spanning tree; if we could expect that, we wouldn't need to
generate one.

I.e., it's more likely that such partitioning might not occur - however,
the rbridge system might not provide a benefit in those cases. AFAICT,
an rbridge helps only where it does partition the bridges as above.

> can stop thinking about bridges, and now only look at the next layer 

Those links can touch the rbridge in multiple places - there's no reason
they necessarily connect to a single port. While this is OK for the
rbridge egress (it picks one designated rbridge on that link to send
things out), it's entirely possible that a broadcast will end up cycling
back over that link to another ingress port.

That's why the rbridge needs to be in the spanning tree protocol.
Otherwise the 'links' outside can loop back onto the rbridge.

Joe

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 11 Oct 2005 19:21:31 -0700

Re: Joe's comments about my scenario (first saying that
replacing some bridges with RBridges may not partition the campus, which 
is true but not relevant
to the point I was making, and second saying that RBridges have to join 
in the bridge spanning tree
or else there will be loops, which is not true, and it's important that 
we all understand that).

**********************
There's confusion here. Sorry if I'm not explaining properly.

Let's start over again with the steps I was saying:

***********
Perhaps you are quibbling with "likely partitioned". If the
topology is such that the particular bridges you've replaced with RBridges doesn't
partition things, then you will wind up with what looks to the RBridges like they
are all connected to the same link. One port of one will get elected Designated RBridge.
But it won't *do* anything. It won't decapsulate or encapsulate or forward any
data packets. It will just sit there unless there is another "link" in the topology.
But all the RBridges just see a single link. Even if they have multiple ports onto
the same link.

But I'm trying to explain a topology in which RBridges *will* do something. That
is when the topology, if you halted all the RBridges, *is* partitioned. So assume
you have replaced enough bridges with (for now halted) RBridges, so the world
is partitioned into 5 pieces.
**************

Back to the story I was telling. To reiterate, you've either partitioned 
things, or you haven't. If you haven't,
then the RBridges aren't doing anything. The bridges will all compute a 
single spanning tree that connects
all the segments that the RBridges see, so all the RBridges see is the 
simple topology of them all connecting
to a single link, and as I said, they won't be forwarding any data 
packets. The only thing they'll be doing is
transmitting LSPs and Hello messages. But none of them will forward 
anything. That's not a very interesting
topology. Let's get on to what happens in the interesting case.

So now let's assume you have managed to partition the campus. Then let's 
continue with what I was saying:

*************

The bridges in each partition compute their own spanning tree, with their
own Root bridge. The different spanning trees will not see each other, and will not merge (because we've said the RBridges are not forwarding the BPDUs).

Now let's turn on the RBridges, and let them do their thing.

Each of the pieces looks to the RBridges like a single link. The 
RBridges don't see the difference between
a single Ethernet segment, or a bridged Ethernet segment. Just like 
routers don't see the bridges.

So now we can ignore the bridges, and think of a topology consisting of 
5 links, and a bunch of
RBridges connecting the links. Some of the RBridges might have multiple 
ports onto the same link.

Now the RBridges are similar to routers, where they compute optimal 
paths between each other, over those
"links".

Everything works, just as it works to have routers connected in an 
arbitrary topology over an arbitrary
set of links.

***************

I hope I'm making things clearer...

Radia

Now you (Joe) said:

>they necessarily connect to a single port.
>
What happens if an RBridge has two ports onto what it sees as the same 
"link" is that only one of
the ports winds up Designated. So an RBridge will not decapsulate a 
packet onto port i and then
pick it up and encapsulate it on port j, if the RBridge things that port 
i and port j are the same link,
which it will, if port i and j are connected through a path of bridges.

It is most definitely the case that RBridges do not participate in, nor 
do they need to participate in,
the bridge spanning tree protocol. They need to have a forwarding entry 
for the multicast address
on which the BPDUs are sent, to *not forward* packets sent to that 
multicast address.

Radia

> While this is OK for the
>iD8DBQFDTD7mE5f5cImnZrsRAp+lAJ91dAP3vrxQDXiaU2gRHC1a+1slQwCg3Ssk
>UPKxoEu4qB+tJlVtDS8ylRo=
>=wc2h

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 11 Oct 2005 20:04:08 -0700

Radia Perlman wrote:
...
> is partitioned into 5 pieces.

AOK - I was thinking of this in particular for the applicability part of
the problem/applicability statement.

The catch is that this is going to be less useful if this is required
but cannot be detected or encouraged somehow.

...
> routers don't see the bridges.

You've said here and before that the rbridge looks like a router - but
it does not, because routers have ethernet addresses and source and sink
packets.

Routers and hosts are just nodes on a ethernet segment, nodes that have
802 addresses. Now if the rbridge has an 802 address, then we have a big
problem about how to cross the rbridge and come out the right place - we
need to do proxy ARP on all the external links, we need to rewrite the
packets we receive, and we potentially pollute the ARP caches of nodes
on the links that then move elsewhere in the system.

So we need to have some other analogy - e.g., it's a bridge that blocks
BPDUs.

Back to the key question...
...
> which it will, if port i and j are connected through a path of bridges.

OK. I'm understanding the trick -maybe.

Basically, there's effectively a phantom spanning tree inside the
rbridge. You just made one by saying there's exactly one 'designated' port.

So I *can* think of this as one big bridge. One that has internal logic
that makes sure that it touches each spanning tree it sees externally in
one place (isn't that what spanning tree does?) and then ends up acting
like a terminus on each spanning tree (again, what spanning tree does).
So although BPDUs aren't forwarded, the net effect of a spanning tree is
retained.

So maybe (***here's the interesting point, IMO - if I understand this
now***) this also works for bridges.

They don't strictly need to forward BPDUs either (by analogy). All they
need to do is act sufficiently like an rbridge campus and things will
work - and the spanning trees will be partitioned.

Can anyone explain to me why this won't work with a regular bridge if we
built it? And if it did, wouldn't it make the spanning trees a LOT
simpler at the edges?

All we have to do is make sure these 'magic bridges' are deployed in
ways that partition the existing bridges into non-connected stubs -
which we have to figure a way to do with rbridges too.

So does that work? (and if so, has anybody tried it?)

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/20051011/d0abf357/signature.bin

---

From: ssuryaputra at gmail.com (Stephen Suryaputra)
Date: Wed, 12 Oct 2005 11:56:16 -0400

Let's see if I understand this: only designated Rbridge port
encapsulate L2 packet, forward, and decapsulate Rbridge (shim) packet
back to its L2 format. So, from forwarding point of view, non
designated port is not connected to the L2 network.

Please see the attached network diagram (A text file. Sorry, it's hard
to draw a text diagram using my email client) for the following
description.
A, B, C and D are endnodes. RB1 is the designated Rbridge for segment 1
(with i as the designated port, noted by an asterisk). RB3 is the designated
Rbridge for segment 2 (j is the designated port).

D sends a broadcast frame. Only RB1 encapsulates the frame with the shim header
and forwards it unicast to the IS-IS spanning tree (to RB2, RB3 and RB4). RB2
and RB3 decapsulates the frame and send it to their endnodes, but RB4 does not
because it is not the designated Rbridge for segment 2.

If my understanding is correct, I agree that loops won't exist and
Rbridge does not need to participate in 802.1 spanning tree protocol.
The drawback is the broadcast frame is seen multiple times on segment
1. The description in section 2.3 of the draft on the role of
designated bridge and designated port must be clarified to avoid
confusion.

Stephen.

-------------- next part --------------
Physical topology
-----------------

                  segment 1
                  |
             D----+
                  |   *+-------+*
                  +----+i RB1 j+----A
                  |    +-------+
    *+-------+    |
C----+i RB2 j+----+                 segment 2
     +-------+    |    +-------+*   |
                  +----+i RB3 j+----+
                  |    +-------+    |
                  |                 +----B
                  |    +-------+    |
                  +----+i RB4 j+----+
                  |    +-------+    |

Topology from Rbridge point of view
-----------------------------------

                 D   A            
                 |   |
                 |   |
     +-----+    +-----+     +-----+
C----+ RB2 +====+ RB1 +=====+ RB3 +----B
     +-----+    +-----+     +-----+
                  ||
                  ||
                  ||
                +-----+
                + RB4 +
                +-----+