[rbridge] PS and ARCH issues
touch at ISI.EDU
Tue Dec 6 16:59:42 PST 2005
-----BEGIN PGP SIGNED MESSAGE-----
There have been a few responses, most recently Harald's, which suggest
we start a list of issues for the problem statement doc. Here's a first
cut - not intended to be complete, but a reasonable start (I hope).
I propose that if you want to discuss an issue, please post a note with
the following subject (e.g.):
PS issue #3
ARCH issue #4
That'll help us track things until (and if) we use a proper issues tracker.
PLEASE POST ANY ISSUES I MISSED as "PS issue NWE" or "ARCH issue NEW" ;
I will assign numbers to them and post the master list at
These lists are posted there (in a few minutes) as well...
#1 which version of ethernet is the baseline?
STP, RSTP, VLAN, provider bridges, wireless,
shortest path bridging, etc.
(this will help us determine what terminology to use)
#2 should the solution apply to current ethernet scales or not?
and if so, what are current ethernet scales?
Harald proposed as a starting point:
* 1000 end-hosts in a single bridged LAN of 100 bridges
* 100.000 end-hosts inside 1000 VLANs served by 10.000 bridges
#3 IF size is an issue...
what limits the size? STP/RSTP or broadcast traffic, or both?
#4 delivery requirements:
a) is in-order required?
b) is no-duplication required?
#6 address MSTP regions (esp sec 2.2)
as a way to limit STP scale/reconfiguration
IEEE 802.1Q Multiple Spanning Tree Protocol.
Tutorial available : "Understanding Multiple Spanning Tree Protocol" at
#7 differentiate between host reattachment effects
and bridge reattachment effects; the latter impact the STP more
#8 discuss broadcast vs. subnet broadcast vs. multicast support
who gets a copy of multicast? all ports, or just subscribed?
#9 which addresses are not forwarded? (related to ARCH #1)
Bridge Group Address 01-80-C2-00-00-00 , used for frames transporting
Pause Frame address 01-80-C2-00-00-01.
Besides I am not sure but addresses 01-80-C2-00-00-00 to 01-80-C2-00-00-0F
#10 use campus (seemed to be agreement at the meeting)
or use "pool" or "set"
#11 internal/external, inside/outside terminology
there is one objection to these terms as topological;
the draft intends to define them sufficiently
does this need to be addressed further?
#12 address VLAN configuration requirements
#13 need configuration time examples
e.g. references to published research and a summary that shows how
small changes can have large effects
#14 add risks of TRANSPARENT (larger trees, slower to converge, etc.)
#15 sec 2.3 should be more clear about referring to computing backups to
use in case of failure - not that extra links makes routing easier.
#1 resolve recommendations for the three modes of BSTP messages:
(is this part of the PS or ARCH?)
#2 is an rbridge the DR of the edge STPs?
#3 do rbridges have proxy bridges at their edges (see Radia's post of
(see Guillermo's text below)
#4 Giullermo's subcase?
address interior packets to egress rather than next-hop
(isn't egress also in there, in the inner shim header?)
#5 change 'external protocols' section to 'interaction with 802.1D'
Guillermo's text for ARCH #3:
RBridge indirect participation in bridged island spanning tree.
RBridges by default do not participate in spanning tree in other way
than ignoring received BPDUs. It is an objective of RBridge
specification to be independent of bridges specifications as much as
However it may be convenient for RBridges in some circumstances to
participate in the spanning tree and contend to be root bridge of the
spanning tree formed in the bridged island they are attached to. In
these cases it is possible to build a device that's logically the same
as a bridge glued onto an RBridge. The following schema applies:
bridged island-----B1----RB1 ¡
where B1 is a bridge with two ports...a pt-to-pt link to RBRidge RB1,
and a link to the bridged LAN. The "RB1" portion of this box acts as an
standard RBridge, it neither forwards, nor initiates spanning tree
messages. The "B1" portion acts as two-port standard 802.1D bridge, and
does participate in spanning tree. Its priority for root election can be
set in the standard way. To minimize configurafion, it may be convenient
in some implementations to make the standard B1 bridge priority a
function of the configurable RBridge priority for IS-IS Designated
RBridge election. In this way Designated RBridge will participate and
contend (as B1) to be elected also as root bridge of the bridged island
and only one priority configuration is required.
If (in environments using such implementations) the default bridge
priority for B1 is lower than standard bridge priority, by default
RBridges/bridges like B1 shown will become roots of their bridged
islands, contending only with other RBridges connected to same island
for root election. It is not mandatory for RBridges be
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the rbridge