[rbridge] (no subject)

[Eric Gray]

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