[rbridge] Arch Issue #2 and #3

[Guillermo Ibáñez]

Joe Touch wrote:

>-----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
>  
>
The bridge (of the two)  with lower bridge identity= priority value + 
MAC address will be elected as root bridge.
Guillermo

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

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