[rbridge] Per-VLAN DRB elections?

[Eric Gray (LO/EUS)]

Radia,

	To add to what Silvano is saying, if the logical model is 
that RBridge interactions are only defined for a single VLAN, 
then it naturally follows that a DRB election will be for a 
single VLAN.

	The "instancing" implication implied by this logical model
means that an RBridge device may have more complicated things to
do, but the definition of those things is "compartmented" - i.e.
- there are clear distinctions between L2 routing (TRILL), L3 
routing and 802.1Q bridging.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Silvano Gai [mailto:sgai at nuovasystems.com] 
> Sent: Wednesday, May 09, 2007 1:00 PM
> To: Eric Gray (LO/EUS); Radia.Perlman at sun.com
> Cc: rbridge at postel.org
> Subject: RE: [rbridge] Per-VLAN DRB elections?
> Importance: High
> 
> 
> 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
>