[rbridge] Arch Issue #2 and #3
Gray, Eric
Eric.Gray at marconi.com
Fri Dec 9 08:37:19 PST 2005
Joe,
Please see additional comments in-line below...
--
Eric
--> -----Original Message-----
--> From: rbridge-bounces at postel.org
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Joe Touch
--> Sent: Thursday, December 08, 2005 4:49 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] Arch Issue #2 and #3
-->
--> -----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 - see 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...
Actually, I cannot determine how it is possible to derive
that impression - at least within the RBridge context.
Radia's assumption in her description is that the RBridge
portion of the described hybrid _implementation_ would be
_blocking_ STP. Otherwise, there would be no requirement
to include the logical, in-line, bridge.
While you could argue that such an _implementation_ does
participate in STP, its participation is limited and aimed
at a single-minded purpose - i.e. - establishing itself as
the spanning tree root. Because the RBridge in this mode
would be blocking STP, the in-line bridge has nothing of
any topological significance to add to STP other than to
nominate itself (forcefully) as a root candidate for the
spanning tree.
The proposal was very clearly to demonstrate that what
Guillermo wanted could be _implemented_ orthogonally to
specification of base-line RBridge behavior.
-->
--> or actually a variant of BLOCK (see my other message)
Blocking of STP is assumed in this model. I believe if
you were to talk to Radia, you would discover that she
has assumed STP blocking behavior from the beginning and
has not seen any reason to change that assumption. But,
don't take my opinion on the matter, ask her...
-->
--> > 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)...
No rub to it, and this is precisely why Radia made this
proposal. I was objecting to the implied configuration
requirements and Guillermo was firm in requiring a way
to do it.
The way that you can "force a single bridge to be root
of an STP" is via configuration. Clearly it is possible
to configure two bridges on the same segment to have the
same priority in the root selection process and that is
why the process has tie-breaking provisions. That is
also the reason why it is (and MUST be) strictly a
configuration option.
-->
--> 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-----
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->
More information about the rbridge
mailing list