[rbridge] Arch Issue #2 and #3
touch at ISI.EDU
Thu Dec 8 13:48:56 PST 2005
-----BEGIN PGP SIGNED MESSAGE-----
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)...
> 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.
> --> - -------
> rbridge mailing list
> rbridge at postel.org
-----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