Subject: [rbridge] loops in trill networks

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Wed, 12 Oct 2005 12:36:00 -0300

Joe/Radia,

	While the case in which a new RBridge does not partition 
the bridged network is uninteresting from the perspective that
we want to take to figure out how the presence of RBridges is
going to make networking more efficient, useful and exciting -
it is extremely interesting from the perspective of how does a
network continue to work while RBridges are in the process of
being deployed.

	For example, in the case Radia mentioned in which there
appears to be an unpartitioned network after replacing one or
more of the bridges with one or more RBridge(s).  From what 
Radia and others have been saying, the network still works for
all forms of traffic for which it previously worked. A ST will
be determined between bridges and the (one or more) RBridges
will sit there doing nothing interesting (or disruptive).

	This would also be the case when an RBridge is added to
a network topology where no previous bridge existed.

	Subsequently, one or more additional bridges are replaced
by Rbridges.  This time, the previously existing ST is segmented
(as would imediately be the case when the existing bridge was
removed, even before adding the RBridge).  Again, from what has
been said, the network will now work again for all forms of 
traffic for which it previously worked.  The difference is that
- as Radia said - the RBridges are now doing interesting stuff.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org]On
--> Behalf Of Joe Touch
--> Sent: Tuesday, October 11, 2005 11:04 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Earlier, Joe said...

Radia Perlman wrote:
...
> 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.

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.

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

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...
...
>>Those links can touch the rbridge in multiple places - there's no reason
>>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.

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

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 12 Oct 2005 10:14:16 -0700

> will sit there doing nothing interesting (or disruptive).

It *is* distruptive if it blocks previous spanning tree paths, since
it'd end up creating a detour in the spanning tree which might cause
paths to be much more circuitous.

> a network topology where no previous bridge existed.

That ought to do not much, AFAICT.

> - as Radia said - the RBridges are now doing interesting stuff.

Once the spanning tree is segmented; the trick is that I don't think we
can know where to deploy rbridges to *force* segmentation. We can know
where we disrupt the existing spanning tree, but not where we need to be
to partition it.

Joe