ARCH issues	   J. Touch	12-08-2005 4:08pm

If you want to discuss an issue, please post a note with the following
subject (e.g.):

	ARCH issue #3

That'll help us track things until (and if) we use a proper issues tracker.

PLEASE POST ANY ISSUES MISSED as "ARCH issue NEW" 
Joe T. will assign numbers to them and post the master list at
www.postel.org/rbridge

----------------------------------------

#1 resolve recommendations for the three modes of BSTP messages:
   (is this part of the PS or ARCH?)
	participate
	forward
	block

#2 is an rbridge the DR of the edge STPs?

#3 do rbridges have proxy bridges at their edges (see Radia's post of
10/21/2005)?
(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'

#6 internal/external, inside/outside terminology
   formerly PS issue #11 - moved here 12/08/2005
   there is one objection to these terms as topological;
   the draft intends to define them sufficiently
   does this need to be addressed further?

-----

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

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

                        RBridge/bridge box

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
combined bridge/RBridges.

-------