[rbridge] (no subject)

[Dinesh G Dutt]

This is another reason for me to be nervous about making these changes 
now. The old method where we did DRB per VLAN, a single pseudo-node for 
all VLANs that the Rbridge was DRB for seemed sufficient to me and 
avoided all these issues. We've gotten into this mess because someone 
decided that sending multiple Hellos (one per active VLAN) is a huge 
burden on the CPU. I disagree with that assumption and would like to 
avoid all these issues by falling back to what we had earlier.



Dinesh
Eric Gray wrote:
> Folks,
>
> 	Here is the problem that occurs when VLAN state is inferred
> for one VLAN from connectivity provided by another.  This is a
> general problem, but has specific applicability to the current
> set of assumptions used in the protocol specification.  This came
> up in off-line discussions with Anoop Ghanwani (and others) at an
> IEEE meeting a couple of weeks ago.
>
> 	A key thing to understand in looking at this problem is it
> is a comparison between how a network works with 802.1Q bridges
> and the same network after some 802.1Q bridges have been replaced
> with RBridges.  The example shows a partial RBridge deployment
> and this is compared with how it will have worked with 802.1Q
> bridges where the example shows RBridges (i.e. - it is an after-
> the-fact comparison of L2 forwarding functionality).
>
> 	The network looks like this (initially):
>
>       \\\\|////   \\\\\|||/////   \\\|///
>         __|__         __|__        __|__
>        | B-1 |       | B-2 |      | B-3 |
>        |_____|       |_____|      |_____|
>           |  \       /     \_____ /  |
>           |   \_____/      | B-5 |   |
>           |   | B-4 |      |_____|   |
>           |   |_____|         |      |
>         __|__       \         |      |
>        | B-6 |_______\ _______|    __|__
>        |_____|        \___________| B-7 |
>           |                       |_____|
>           |                          |
>         __|___                     __|___
>        | RB-1 |                   | RB-2 |
>        |______|                   |______|
>               \         _         /
>                \__   __( )___   _/
>                   \_(  Core  )_/
>                   (_  RBridge _)
>                     (_ Cloud _)
>                       (_   _)
>                         (_)
>  
> 	In this figure, B-1, B-2 and B-3 are aggregation bridges with 
> multiple (lots and lots) of VIDs.  
>
> 	B-4 is a special purpose bridge used for VLAN-A only, and B-5 
> is a special purpose bridge used for VLAN-B only.  
>
> 	All remaining bridges are configured to participate in VLAN-A, 
> VLAN-B and an arbitrary set of zero or more other VLANs.  Since B-4 
> and B-5 are configured for specific VLANs only, the ports on their 
> adjacent bridging peers are configured only for those VLANs.  
>
> 	To be clear, the links between B-4 and B-7, and between B-6 
> and B-5 are not connected (they merely overlap in the drawing).
>  
> 	In this network, RB-1 and RB-2 are both RBridges and both have 
> access to VLAN A and VLAN B and each other (via both VLAN A and VLAN 
> B) - as well as the same arbitrary set of zero or more VLANs that 
> any of the other bridges in the drawing have.  However, the two 
> RBridges use another VLAN - say VLAN C - to exchange hellos.  Under
> the normal operating conditions intended, this works fine and RB-1 
> and RB-2 may separately be elected DRB for either of VLAN A or VLAN B.
>  
> 	If bridge B-4 fails, then VLAN A would be segmented, at least 
> temporarily.  Hellos continue to work, however, so the 2 RBridges 
> do not discover the partition and the DRB election remains unchanged.  
> In this case, part of the VLAN is orphaned - particularly from the
> perspective of any locally attached end-stations.  
>
> 	However, this is not acceptable behavior.  No misconfiguration
> exists and the ideal (and reasonably expected) behavior would be for 
> the RBridges to discover the partition and redo the DRB election - 
> making RB-1 the DRB for one partition and RB-2 the DRB for the other 
> partition.
>
> 	If (when) RB-1 and RB-2 were 802.1Q bridges, using MSTP for 
> multiple VLANs (in particular, for VLAN A and B), this failure will
> have resulted in re-running (M)STP for the affected VLAN connectivity
> and the segmentation (partitioning) would be healed.  In the same way,
> if the status of VLAN's A and B were derived directly from messages
> that use VLAN A and VLAN B (as opposed to using VLAN C), this same
> robust behavior would occur.
>
>
> --
> Eric Gray
> Principal Engineer
> Ericsson 
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>   

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan