[rbridge] Arch Issue #2 and #3

[Joe Touch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Gray, Eric wrote:
> --> 
> --> #2 is an rbridge the DR of the edge STPs?
> 
> It may be.  This relates to architectural issue #3 - saee below.
> 
> --> 
> --> #3 do rbridges have proxy bridges at their edges (see Radia's post of
> --> 10/21/2005)?
> --> (see Guillermo's text below)
> 
> Radia explicitly suggested this in order to propose that this is 
> out of scope for the TRILL working group.

My impression was more that this was a way to implement PARTICIPATE...

or actually a variant of BLOCK (see my other message)

> An RBridge may be collocated with any number of bridges.  An RBRidge
> implementation may logically connect such a collocated bridge in-line
> with any of its interfaces.
> 
> In this case, it is possible to build an RBridge implementation that
> participates in STP/RSTP and it is possible to configure the in-line
> bridge in such a way as to guarantee that it will become the root of
> the STP.

Can you force a single bridge to be root of an STP? If so, what happens
when two such bridges are on the same segment? (that seems to be the rub)...

Joe

> 
> This is not required of an RBridge implementation - even if it were
> to turn out to be a common implementation case.  Rather, this is an
> offered example - by way of proof of concept - that we do not need 
> to define this behavior as part of base-line RBridge behavior.
> 
> Speaking of orthogonality, this discussion (below) will be included 
> in the next iteration of TRILL routing requirements, when it is 
> submitted.  Assuming that draft eventually becomes a WG draft, you 
> may want to simply refer to that document in the architecture draft.
> 
> --> - -----
> --> 
> --> 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 becombined bridge/
> --> RBridges.
> --> 
> --> - -------
> --> 
> 
> --
> Eric
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDmKpIE5f5cImnZrsRAs/tAKCRkMxmz15gopFBmeHSJ5xZOfz4owCeMznn
DIBxUhcFFdtcp5K3KvwZRWU=
=yueR
-----END PGP SIGNATURE-----