Subject: [rbridge] Per-VLAN DRB elections?

From: Radia.Perlman at sun.com ([email-masked])
Date: Wed, 09 May 2007 06:12:18 -0700

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

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Wed, 9 May 2007 11:07:00 -0500

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?
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Wed, 9 May 2007 09:39:47 -0700

rbridge-bounces at postel.org wrote:
> Radia,
> 
> 	This gets back to "what is the logical model for
> RBridge interactions with VLANs."
> 
> untagged VLAN).  It then is up to the implementers to "do the
> right thing" as far as implementing 802.1Q correctly.
> 
> done, and I am curious as to who finds this model to be unacceptable,
> and why... 
> 
> 

I agree with your approach, but differ on one very specific point.
The one aspect of this model that I think is unacceptable is that
it *requires* the RBridge to represent each VLAN instance separately.
As covered on prior threads this is not always desirable. But once
you allow RBridges that wish to support these features to do so 
(by allowing them to publish 'VLAN Group' information) then the
rest of the interactions can indeed follow the simple model of
thinking one VLAN at a time.

So taken as an absolute I do find exception to the model you propose,
but I believe it is an exception that is more of an asterisk than a
serious problem. If others have problems with the "per VLAN" approach
I'd encourage them to do something similar that allows the feature 
they are considering while allowing RBridges not involved with that
feature to keep the simple model of thinking about each VLAN separately.

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 9 May 2007 10:00:07 -0700

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

> 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,
>

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Wed, 9 May 2007 12:22:04 -0500

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  

> 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
> Subject: RE: [rbridge] Per-VLAN DRB elections?
> Importance: High
> 
> 
> > > Oh...this is somewhat related to listening instead of 
> participating
> in
> > > R2, who is DRB for that link for VLAN B, to see the 
> packet as "VLAN
> B"
> > >

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 9 May 2007 11:25:39 -0700

Caitlin,

On
> Behalf Of Caitlin Bestler
> Sent: Wednesday, May 09, 2007 9:40 AM
unacceptable,
> thinking one VLAN at a time.

There is no externally visible VLAN grouping information in legacy
bridges and I am against having any externally visible VLAN grouping
information in RBridges.

The fact that internally RBridges may group VLANs is an implementation
detail, exactly like in legacy bridges.

-- Silvano

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Wed, 9 May 2007 13:30:18 -0700

>> The one aspect of this model that I think is unacceptable is that it
>> *requires* the RBridge to represent each VLAN instance separately.
>> you allow RBridges that wish to support these features to do so (by
>> allowing them to publish 'VLAN Group' information) then the rest of
>> the interactions can indeed follow the simple model of thinking one
>> VLAN at a time.
> 
> There is no externally visible VLAN grouping information in
> legacy bridges and I am against having any externally visible
> VLAN grouping information in RBridges.
> 
> The fact that internally RBridges may group VLANs is an
> implementation detail, exactly like in legacy bridges.
> 

An RBridge that does support VLAN Grouping is not required to
do anything with this information. It is clearly of value and
leads to simpler configuration for RBridges that do support
VLAN Grouping. I don't see the value in excluding information
that has no real cost to other RBridges from the exchanged
information. We are talking about one extra VLAN-ID in the
per-VLAN instance (an optional VLAN ID of the master group).
It is easily initialized to NULL, and even more easily ignored.

If RBridge implementations are allowed to support VLAN Groups
*anyway* then the benefit of having this information available
in a standard way clearly outweighs the cost of two bytes of
storage per instance.

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Wed, 9 May 2007 14:11:06 -0700

Caitlin,

> From: Caitlin Bestler [mailto:caitlinb at broadcom.com]
> Sent: Wednesday, May 09, 2007 1:30 PM
> To: Silvano Gai; Eric Gray (LO/EUS); Radia.Perlman at sun.com
it
> It is easily initialized to NULL, and even more easily ignored.

If the VLAN grouping is FYI only, I don't have a big objection, but I
still don't understand why TRILL needs to deal with it in the basic
protocol draft. Why don't you write a separate draft that defines a
separate IS-IS TLV to carry this information?

It can still be done in the TRILL WG.

-- Silvano

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Thu, 10 May 2007 11:19:56 -0400

Hi Radia,

I don't completely understand your proposal point (d) where you say it
is fatal if VLAN tags are mapped between each other inside a bridged
LAN. Assuming the mapping in symmetric, wouldn't Hellos also get mapped
between VLANs so the two DRs you suggest would see each other and you
would only end up with only one DR?

Donald

-----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?

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.

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"

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

Comments?

Radia

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Thu, 10 May 2007 14:17:59 -0500

Donald,

	While I agree that symmetric mappings will prevent confusion 
of the type that Radia seems to be concerned about, it is (I believe)
generally felt to be a bad idea to have such mappings within a single
administrative domain.

	As I understand it, the issue is that there are other mechanisms
that are (or may be) aware of VLAN tags as they are locally used and
these mechansism will require "re-mapping" as well.

	Hence, while I am unsure of Radia's reasoning, I am okay with
her
conclusion that it is a really bad idea within an RBridge campus.

--
Eric Gray
Principal Engineer
Ericsson  

> [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Thursday, May 10, 2007 11:20 AM