Subject: [rbridge] RBridge/bridge interaction

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Thu, 20 Oct 2005 18:02:47 -0300

Guillermo,

	During the discussion, the terms TRANSPARENT, PARTICIPATE
and BLOCK were used (often in upper-case, exactly as I have used
them here) as if these would ultimately be options that might be
supported - either as a complete set, or as some subset.  

	For example, one argument was that TRANSPARENT or PARTICIPATE 
might be used, but BLOCK should not.

	Also, at certain points in the discussion, there was some
thought that these might be modes that applied at different states
during transitions in a network.

	From a practical stand-point - however - it would be best if
we did not have to support all of these, either as options, or as
modes.  The mere fact that they were brought up does not mean we
are committed to including them.

	In particular, if we start talking about - for instance -
having a per-interface option for all of these choices (and maybe
others as well), then we either need to analyze proposals for 
architecture and design to ensure that the "right things" will
happen when an arbitrary combination of all of these options is in 
effect, or we need to define caveats for network operators to avoid 
specific combinations of options.  For example, we may need to say
that the same option must be set throughout the network or this and
that will (or may) happen.  That kind of design begs configuration
errors to occur.

	In this case, the fact that we want to make the solution plug
and play means that we can reduce the potential for disaster if we
choose (and require) a specific default set of option choices.  If
we can get away with it, however, we should simply avoid options.

	While having these same values as modes that apply during 
certain transitional states is cleaner, it would require a well-
defined finite state-machine (not a particular problem) and a 
genuine need for these behaviors under certain circumstances.  It
may well be the case that this turns out to be true.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org]On
--> Behalf Of Guillermo Ib??ez
--> Sent: Thursday, October 20, 2005 4:19 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] RBridge/bridge interaction
--> 
--> 
--> I volunteer for some work on the capture, although my 
--> english might be 
--> not too understandable.  From what date should the capture 
--> to be done?
--> 
--> Regarding PARTICIPATE PER PORT:
--> Although I do not have a clear position, and it requires detailed 
--> analysis, it seems to me that PARTICIPATE PER PORT is 
--> better integrated 
--> with spanning tree, while maintaining the basic decoupling 
--> that BLOCK 
--> provides.
--> With PARTICIPATE PER PORT it would be possible to force the elected 
--> Rbridge to become the sbridge root of the bridged domain by 
--> modifying 
--> its bridge priority when it gets elected as Designated by 
--> IS-IS (this 
--> could be an optimization). In this way the path length is 
--> minimum  from 
--> all bridges of bridged domain to the DR.
-->  
--> 
--> Erik Nordmark wrote:
--> 
--> >We've had some useful discussion on this mailing list.
--> >It would be good if somebody can capture the results 
--> (perhaps as a long 
--> >email) that we can fold into the draft(s) later. Any volunteers?
--> >
--> >I don't know if we will have additional issues in this 
--> space or that it 
--> >otherwise makes sense devoting agenda time to it in Vancouver.
--> >
--> >For instance, while I'm convinced that BLOCK works, I 
--> wonder if there is 
--> >something in PARTICIPATE PER PORT that can make the 
--> interaction work better.
--> >
--> >Two cases to consider:
--> >1. The elected forwarder dies and a new one gets elected. 
--> How quickly 
--> >can packets sent by stations in the bridged cloud fail 
--> over to go to the 
--> >new elected forwarder?
--> >
--> >  
--> >
--> My understanding is that if the forwarded dies, the sbridge domain 
--> should handle  it as  a topology change notification, tables   of 
--> sbridges should be  flushed according to the spanning tree 
--> rules, so the 
--> sbridge domain must know the DR will not forward frames as 
--> it used to. 
--> It seems Rbridge shall issue a Topology Change Notification 
--> via sbridge 
--> domain to flush MAC tables. Is a fast analysis, probably I 
--> miss details.
-->  
--> 
--> >2. We have two separate bridged domains, each with their elected 
--> >forwarder. Somebody connects the two bridged domains 
--> together with a 
--> >wire. This can cause a temporary loop until a single 
--> elected forwarder 
--> >is picked by the RBridges.
--> >
--> >  
--> >
--> In this case the PARTICIPATE PER PORT seems superior, as 
--> the two merged 
--> bridged domains will merge their spanning trees into one 
--> and both DRs 
--> will compete to be the root of the merged tree, this mechanism will 
--> likely be faster (via RSTP fast transit to forwarding state 
--> over the 
--> bridged domain)  than  Designation to select the unique DR. 
--> In other 
--> words , the mechanism of root election in sbridge could be 
--> used to help 
--> in DR designation and/or viceversa.
--> So I see in PARTICIPATE PER PORT, some coupling between DR 
--> status and 
--> root status of sbridge domain that can be used
-->  to speed up convergence and coherence of both domains. It 
--> seems that 
--> sbridge domains should be under the control of  Rbridges, but the 
--> sbridge mechanims should be used by Rbridges to keep the network 
--> consistency and reconfiguration capabilities of RSTP.
--> Guillermo
--> 
-->  
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Thu, 20 Oct 2005 23:35:20 +0200

Eric,

>are committed to including them.
Agreed

>that will (or may) happen.  That kind of design begs configuration
If you refer as configuration options per interface to the PARTICIPATE 
PER PORT mode as an option per port, it is not the case. If  you refer 
to being the DR the root bridge of the sbridge domain, I think it must 
be analyzed as a real alternative, even if it is not the default 
configuration.

>we can get away with it, however, we should simply avoid options.
Agreed, but not for the root bridge problem because is a real, practical 
issue.

>may well be the case that this turns out to be true.
RSTP port state machines are there, may be they should be taken into 
consideration to make a consistent and integrated, but not interwoven, 
design for Rbridges that work with RSTP trees.
Guillermo. 

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

---

From: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Thu, 20 Oct 2005 15:10:08 -0700

I don't believe there should be options here.
It should be plug and play.
RBridges should BLOCK bridge spanning tree messages,
and isolate the bridged islands.

I absolutely do not understand what people are
worried about with BLOCK.

I suggest someone that actually thinks there is
some reason to do anything other than drop
spanning tree messages start a thread with
a subject line
"why it is good for RBridges to forward BPDUs",
and very very carefully explain from scratch
what the reasoning is. Not with a long
email quoting pieces of other emails, but
with a carefully crafted, from scratch explanation
of what you perceive as a problem with BLOCk, and
what the perceived benefit of ever having
RBridges forwarding BPDUs would
be.

Oh...and there was a much earlier thread of the
thread about other devices that might forward
or drop BPDUs. There have always been things we
referred to as "simple bridges" that forwarded spanning
tree messages. I was careful to ensure that the
spanning tree would work with such devices. Of course
the spanning tree would not prevent a loop of all
simple bridges, but if there was at least one spanning
tree bridge in the middle of every possible loop, then
there would wind up being no loops.

You can think of "simple bridges" (ones that mindlessly
forward BPDUs) as a layer below bridges. They are
invisible to bridges. Bridges see a bunch of
segments connected by simple bridges as a single segment.
(Just like RBridges will see a bunch of segments connected
by bridges as a single segment).

Devices that drop BDPUs work if they are really
layered on top of bridges, i.e., they let the
bridges do their own thing to create isolated
broadcast domains, and then these other devices do
their own thing to glue these islands together.
Like routers do. And like RBridges will do.

Radia

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Fri, 21 Oct 2005 08:33:01 +0200

I see the standard root election mechanism of spanning tree islands as 
the fastest and simpler mechanism for DR Rbridge designation. I see the 
DR Rbridge as being necessarily the ROOT bridge of  that sbridged cloud 
(or "link"). The root bridge of a standard spanning tree is the 
"natural" source and sink point for the spanning tree.  To do so, the DR 
must issue BPDUs to become the root bridge.  This is part of what I 
mentioned days ago as PARTICIPATE PER PORT, but may be we should call it 
SOURCE OR SINK (participate, do not forward BPDUs, only send own BPDUs 
to contend to be the root bridge of the link).
The consequence of this DR election mechanism is that the priority 
configured at Rbridges as bridge ID would determine their also their 
election priority as DRs. I think this keep both domains coordinated 
with a single mechanism.
Guillermo

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Fri, 21 Oct 2005 00:25:40 -0700

I don't think there's any reason, even if most of the traffic on the 
link comes from the DR, for the
DR to be the root of the spanning tree.
What would be bad is if an RBridge, participating in two bridged 
islands, winds up merging
the islands into a bigger island.

The whole point is to make the bridged islands as small as possible, so 
most forwarding is done
protected by hop count, and with optimal routes.

I'll admit that having RBridges *initiate* BPDUs
to vie for being Root is not as harmful as having them *forward* BPDUs 
between
bridged islands (provided an RBridge is careful not to merge two islands 
that would
have been separate if the RBridge had just been blocking BPDUs).

We shouldn't make things more complex in an attempt to come up with a 
"more optimal"
spanning tree within the bridged islands.
With a bidirectional tree, as happens with bridges, there's nothing 
special about the Root.
Also, the traffic pattern might be such that most of the traffic is 
between endnodes within
the island. So there's really no reason to believe that having the 
RBridge DR be the
spanning tree Root will result in better performance. And is certainly 
complicates things.
And it also certainly is dangerous because of the potential of merging 
islands.

Radia

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Fri, 21 Oct 2005 14:14:19 +0200

>the islands into a bigger island.
Good point, but I think it can be solved.
The merging of islands can be prevented if the RBridge acting as root 
limits to one port maximum in the Designated Port Role of spanning tree 
for sbridges.

>the island. 
With the client server model, dominant traffic is to and from the core 
layer of campus network, so I think most of the traffic will flow 
from/into Rbridge, not withing the islands.

>So there's really no reason to believe that having the 
>RBridge DR be the
I do not think is dangerous. The merging of islands is not convenient, 
but it can be prevented, limiting to one port the Designated Role in the 
root Rbridge.
Guillermo

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Fri, 21 Oct 2005 14:36:08 -0700

>from/into Rbridge, not withing the islands.
If we buy that argument, then the same argument would say that routers 
should participate in
the spanning tree and attempt to become Root. And what if there are 
multiple routers?
If it's so vital for performance that one router is Root, then they'd 
all need to be Root within a bridged
network.

We shouldn't be trying to optimize that particular tree calculated by 
the bridged islands. Hopefully
those trees would become smaller and smaller. And even if we did care 
about some type of optimality,
I don't think trying to make one of the RBridges Root will make any 
difference. (Note "one of the
RBridges"...there can be several RBridges on the bridged island, so at 
most one of them can
be Root). People have lived for a long time without worrying about 
making one of the routers on
a bridged LAN be the Root in order to attempt more optimal delivery of 
traffic on/off the bridged LAN.
I don't think we should worry about it either.

Radia

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Fri, 21 Oct 2005 23:58:21 +0200

Root election would be, as now, planned according to expected traffic 
patterns. If routers have dominant traffic, they could be configured to 
act as roots.
Besides performance, nobody mentions arguments regarding independent 
IS-IS DR election vs DR election linked to root bridge election, which I 
think is a  more important advantage than performance and shortest path 
in the spanning tree. My impression is that convergence is slower for 
IS-IS for DR reconfiguration  than for an RSTP driven DR election. 
But perhaps we have discussed enough this subject. Time will tell if 
something like this is desirable.
Guillermo

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Mon, 24 Oct 2005 08:06:30 -0700

> election priority as DRs. I think this keep both domains coordinated 

But I don't think it is possible in 802.1D to guarantee that the 
RBridges become the 802.1D root bridges as seen from the bridges.
It could be that there is one or more bridges that are configured so 
that they are the most likely to be selected as 802.1D root bridges.

Presumably we'd want RBridges to function even when applied to such a 
network (even though the paths might not be "optimal").

    Erik

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Mon, 24 Oct 2005 21:24:22 +0200

-----Mensaje original-----
De: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] En nombre
de Erik Nordmark
Enviado el: lunes, 24 de octubre de 2005 17:07
Para: Developing a hybrid router/bridge.
CC: Radia.Perlman at sun.com
Asunto: Re: [rbridge] RBridge/bridge interaction

But I don't think it is possible in 802.1D to guarantee that the 
RBridges become the 802.1D root bridges as seen from the bridges. It could
be that there is one or more bridges that are    configured so that they are
the most likely to be selected as 802.1D root bridges.
GI> If priority is configured with very low value, this is unlikely to
happen. It is the network administrator who decides when setting the bridges
priorities. If nothing is configured, the default priority value is in the
middle of the range, so if the default priority value for Rbridges is lower,
one Rbridge will be always root if nothing specially configured.

GI> May be the term "necessarily" is excesive. The reason to contend as root
bridges is two fold: optimize paths and ensure  uniqueness and fast election
of DR Rbridge via root bridge election, linking both processes. This also
may improve 
network predictability and understability, although I do not know details on
the pros and cons of standar IS-IS DR election. My understanding is that it
is slower and requires the spanning tree established. Root bridge election
DOES NOT
Require the spanning tree established and forwarding frames. This might be
the MAIN argument in favour of using root bridge election for DR Rbridge
designation.   

GI> I agree, it can not be mandatory.

    Erik
GI> With Radia's proposal of an optional combined implementation Rbridge+
bridge, it can be set up this way. The bridge participates and contends to
be root.

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