[rbridge] Per-VLAN DRB elections?

Silvano Gai sgai at nuovasystems.com
Wed May 9 10:00:07 PDT 2007 

The DR election MUST be per VLAN. There is no other way.

Given any two RBridges they may be connected on some VLANs and not on
others.

Let's suppose that RB1 and RB2 are connected on VLAN 1 and not on VLAN2.

One of the two needs to be elected as DR on VLAN1 and the other will be
blocked, but both will be DR on VLAN 2. See drawing below.

+---------+        +----------+
|  RB1    |--------|  RB2     |
+---------+        +----------+
     | p1                |p2
+---------+        +----------+
|   B1    |--------|   B2     |
+---------+    x   +----------+

All links are in VLAN 1 and 2 except link x that is only in VLAN 1.
On P1 RB1 is blocked on 1 and forwarding on 2.
On P2 RB2 is forwarding on both.

-- Silvano




> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Eric Gray (LO/EUS)
> Sent: Wednesday, May 09, 2007 9:07 AM
> To: Radia.Perlman at sun.com
> Cc: rbridge at postel.org
> Subject: Re: [rbridge] Per-VLAN DRB elections?
> 
> 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
> >
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge

More information about the rbridge mailing list