[rbridge] Per-VLAN DRB elections?

[Eric Gray (LO/EUS)]

Radia,

	This gets back to "what is the logical model for RBridge
interactions with VLANs."

	If - as Joe has suggested at least once - the logical
model for an RBridge (instance) is specific to a single VLAN,
then this becomes very straight-forward.  All of the RBridges
in a single logical campus are necessarily in the same VLAN.

	There may be no VLANs - equating to a single logical
VLAN consisting of the untagged (default) VLAN.

	There may actually be an overlay of any number (up to
4K) of VLANs that use a deployment of RBridge devices, where
each device has at least one RBridge logical instance for any
VLAN in which it is configured to participate.

	The elegance of this logical model is that there is L2
connectivity between only those RBridge instances that are
configured to participate in a common VLAN.  Hence, there is
a DRB election process that only includes RBridges that are
in the same VLAN, on any shared connectivity link.

	The advantage of this elegance is that it allows us to 
define actual protocol interactions exactly as if there is 
only one VLAN (which may be the default, unconfigured and
untagged VLAN).  It then is up to the implementers to "do
the right thing" as far as implementing 802.1Q correctly.

	This - in my opinion - is the way things should be
done, and I am curious as to who finds this model to be
unacceptable, and why...

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia.Perlman at sun.com
> Sent: Wednesday, May 09, 2007 9:12 AM
> To: rbridge at postel.org
> Subject: [rbridge] Per-VLAN DRB elections?
> 
> I think we haven't discussed this one on the list yet.
> 
> Bridges can be configured to not forward certain VLANs on 
> certain links.
> So, a "level 2 cloud" (a bunch of links connected with 
> bridges) can be partitioned
> with respect to various VLANs. So, for instance, RBridges R1 
> and R2 can be
> neighbors on a cloud with respect to VLAN A, but not with 
> VLAN B. In other
> words, a packet tagged with "VLAN A" will get from R1 to R2, 
> but one tagged
> with "VLAN B" will not...even if both R1 and R2 think they 
> are connected to VLAN B.
> 
> Oh...this is somewhat related to listening instead of participating in
> the bridge spanning tree, which I will clarify in a separate thread.
> 
> 
> Some issues with bridges not forwarding all VLANs:
> 
> a) If the IS-IS DRB (Designated RBridge)
> election messages are tagged with VLAN B, then we will wind up
> with two DRBs for the link (scary)
> 
> b) if R1 is selected DRB for the link, it may not be able to 
> serve all endnodes (since
> R1 might not be able to reach certain endnodes on some VLANs
> 
> c) in theory, DRB election should be separately carried out 
> for each possible VLAN tag
> (4000 of them). That would be too much.
> 
> d) there was a suggestion that it might be a feature to allow 
> load sharing off a layer 2
> cloud by having separate DRBs for different VLANs
> 
> So...here's a first strawman proposal, partially based on my 
> memory of hallway conversations:
> 
> a) for the zero configuration case, assume that without 
> configuration, the DRB election
> is carried out once, tagged with VLAN 1. Whoever gets elected 
> DRB in the DRB election
> tagged with VLAN 1 is DRB for all VLANs on that link.
> 
> b) RBridges may be configured with other VLAN tags to also, 
> on the same port, participate
> in an IS-IS election with. DRB priority may be configured to 
> be different for different VLANs, so
> R1 might be configured, on port a, to participate in a DRB 
> election for VLAN A with priority 7,
> and VLAN B with priority 9
> 
> c) In the core instance of IS-IS, R1 announces not just which 
> VLANs it is attached to, but
> the Root bridge ID for that VLAN. That way, if R1 finds out 
> (by seeing R2's link state packets)
> that R2 claims to be DRB for VLAN A, with root bridge 89, and 
> R1 thinks that it is DRB for VLAN A,
> root bridge 89, then one of them should back off (using 
> system ID as a tie breaker), where
> "back off" means "stop acting as DRB", i.e., don't 
> encapsulate/decapsulate data packets
> to/from that port with respect to that VLAN
> 
> d) it is absolutely gross misconfiguration, and a disaster, 
> if within the layer 2 cloud, a VLAN tag
> can turn into another VLAN tag, because this could cause R1, 
> who is DRB for
> that link for VLAN A, to decapsulate a frame onto the link, 
> which might pop out to
> R2, who is DRB for that link for VLAN B, to see the packet as "VLAN B"
> 
> I *think* my proposal above has the following properties:
> 
> 1) if a link is genuinely partitioned with respect to VLAN A, 
> then there will be two DRBs elected
> for that link, and all endnodes on that link in VLAN A will 
> be reachable via one or the other
> DRBs, and no link will be formed
> 
> 2) as long as a VLAN tag can't get converted to another VLAN 
> tag within the layer 2
> cloud there will not be loops formed by having two DRBs on 
> the same layer 2 cloud
> 
> 3) we can do load sharing (R1 will be DRB for VLAN A and R2 
> will be for VLAN B)
> 
> 4) if R1 and R2 wind up both elected as DRB for VLAN A and 
> VLAN A is not actually
> partitioned (but R1 can't reach R2), then they'll discover 
> this through the core instance
> IS-IS announcements
> 
> 5) the common case can still be zero configuration
> 
> Comments?
> 
> Radia
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>