Subject: [rbridge] Arch Issue #2 and #3

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Thu, 8 Dec 2005 13:54:15 -0500

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

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.

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

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 08 Dec 2005 13:48:56 -0800

> --> #3 do rbridges have proxy bridges at their edges (see Radia's post of

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

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

> bridge in such a way as to guarantee that it will become the root of

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

> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Fri, 09 Dec 2005 10:52:33 +0100

Joe Touch wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Gray, Eric wrote:
>  
>
>>--> 
The bridge (of the two)  with lower bridge identity= priority value + 
MAC address will be elected as root bridge.
Guillermo

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

-- 
Guillermo Ib??ez
Departamento de Ingenier?a Telem?tica
Universidad Carlos III de Madrid
1.1.B.11 Colmenarejo 91-6241393
4.1.F.13 Legan?s 91-6248794

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 09 Dec 2005 08:11:49 -0800

>> MAC address will be elected as root bridge.

Right. So absolutely NO way to *force* a single bridge to win root
election (if there were such a way, they'd conflict and need such a tie
break; there's no way for BOTH to win such a tie).

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20051209/edb31214/signature-0001.bin