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

From: petera at nortel.com (Peter Ashwood-Smith)
Date: Tue, 18 Oct 2005 13:14:11 -0400

> One nit, on terminology...
> 
> Just making sure that someone who has recently studied 
> "minimum spanning 
> trees"
> doesn't get confused by your explanation, Peter.
> You're not wrong, but the terminology "minimum spanning tree" usually 
> refers to something different
> than what you're talking about...
> something where the total cost of all the links in the tree 
> is minimum.

  Yes, sorry, you are too kind, its technically wrong without
a macro substitution of the term "minimum spanning tree". That's 
what I get for trying to think past midnight ;)

  What I was trying to explain to Joe was that if he simply adopted
the DR mechanism from Rbridge in bridges and did away with BPDUS then
no form of optimization of the tree is possible since knowledge about
what goes on further away is lost. In particular you could not produce
a shortest path first tree to a preferred root.

  This I believe is what he was alluding too in his example. In
particular
he was asserting that if the DR mechanism can work without looking
at BPDUS then why can't it work in a regular bridge without BPDUS. The
answer I believe to that question is that it could but you would lose
the 
ability to compute a shortest path first tree to a preferred root. You'd
just converge on some tree.

  Hopefully some of this or the previous explanation is enough to 
convince folks that BLOCK does indeed work. .. if not ... well I'm 
out of ideas too.

  Peter

---

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

Hopefully nobody will interpret "out of ideas" as "giving in and 
accepting that we have
to have a single huge merged spanning tree because we've been convinced 
that BLOCK
won't work".

I'm assuming Peter is saying the same thing I am. But without speaking 
for him, let me say
a) RBridges have to block. That's a nice simple clean thing to do. It works
b) I don't understand why people think there is a problem, and I don't 
think they've
stated what they are worried about clearly enough, at least for me to 
understand it
c) It's really hard to argue when I don't understand what the issue is.
d) forwarding BPDUs is a really really bad, scary idea, and will have no 
advantages.

I'm guessing the anti-BLOCK folk are confused about where a packet 
enters a bridged island, and where it
leaves the bridged island. Perhaps there's no way to explain it in 
email, and perhaps it could be
all cleared up with a little off-list telephone conversation. If anyone 
wants to talk to me by phone, let me know,
since hopefully it will clear things up and we can get on to other 
issues, if there are any.

But I'll try to explain it yet another way.

Within the bridged island there is just a single tree. Traffic can enter 
that tree anywhere, and leave it
anywhere. The only job of bridges within that island is to make that 
happen....to accept traffic anywhere,
and let it leave anywhere. Just as if the link were a token ring, or
token bus. The magic inside the link is irrelevant
to anything working on top of the link. Just so long as the link creates 
a fully connected, broadcast domain.

So the bridged island can be thought of, to RBridges, as a single 
physical link.

Now try to imagine RBridges in a world without bridges, since the 
bridges are inside the links,
and successfully doing their job of creating a fully connected broadcast 
domain within the
bridged island. As long as BPDUs are blocked, and the island really is 
isolated from the rest
of the world except for devices that act as stations on that island 
(like RBridges or routers or endnodes),
any of the following are equivalent models of the link: a single wire, a 
bridged Ethernet, a token ring,
a bridged token ring, a token bus, ....

If there's a problem with providing service on top of a link which is a 
fully
connected broadcast domain, then IP routers have the same problem.

Radia

Peter Ashwood-Smith wrote:

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

---

From: saikat at seas.upenn.edu (Saikat Ray)
Date: Tue, 18 Oct 2005 19:39:07 -0400

This I believe is what he was alluding too in his example. In
Particular he was asserting that if the DR mechanism can work without
looking at BPDUS then why can't it work in a regular bridge without BPDUS.
The answer I believe to that question is that it could but you would lose
the ability to compute a shortest path first tree to a preferred root. You'd
just converge on some tree.

[Saikat] In the legacy network, if you choose an arbitrary bridge connected
to a LAN segment as its designated bridge, then you do avoid loops, but you
may end up in a disconnected network! I am not good at ASCII art, but I will
try to show an example.
                      ___
                      |_|
                       | 
                _______|_________
                       |
                      _|_
                      | |
                     /---\
      ______________/     \__________________
               _|_                _|__
               |_|                |__|

Assume that there are three LAN segments (the straight lines) and 4 bridges
(the boxes). One of the bridges is connected to all the 3 LAN segments; the
rest 3 bridges connect these three LAN segments to the rest of the network
(i.e. the network has more LAN segments). Now if there is an arbitrary
bridge designation process that does not look into the distance from root,
then all the three LANs may choose the middle bridge as their designated
bridge, and then this part of the network would be disconnected from the
rest because the other three bridges will not send/receive packets to/from
these LAN segments.

In the RBridge case, of course, the system works because RBridges send
encapsulated packets without restriction. Legacy bridges did not have that
luxury, I guess!

  Peter

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Wed, 19 Oct 2005 06:04:31 -0700

Thanks for doing the summaries.

> stated what they are worried about clearly enough, at least for me to 

Having caught up on trill email, it seems like the root of the concern 
that Joe has (and I haven't seen others express it) is that things are 
simple to understand if the rbridged cloud can be abstracted as a single 
bridge. I would agree that things are harder to understand if this is 
not the case.

My take is that there can be different abstractions in the data plane 
and the control plane. In the data plane I think we all want the 
rbridged cloud to behave as a single bridge (for instance, a packet to 
an unknown destination would be flooded to all ports of this conceptual 
bridge).

But for the control plane we have (at least) two choices:
  - make the rbridge cloud behave exactly as a single bridge from the 
perspective of an observer that can look at all the ports of this 
conceptual bridge
  - make the rbridge cloud behave in a way that interoperates with (does 
not violate any assumptions of) the bridged networks they interconnect.

My understanding is that Joe has been arguing for the former.
But this seems to lead to undesirable behavior due to the 
interdependency of 802.1D and RBridges. For instance, the bridges would 
pick a single root bridge for the whole campus, and should the root 
bridge fail it will affect the whole campus until 802.1D has converged.

    Erik