Subject: [rbridge] Query on vlan-mapping

From: somnath chatterjee <[email-masked]>
Date: Fri, 9 Dec 2011 20:10:36 +0530

Hi Authors,

Please ignore my previous mail's question, as my understanding was
wrong regarding appointment of Appointed forwarder on a link when vlan
mapping is detected. Still, I do not understand why can't DRB
distribute the appointment of appointed forwarder to different RBs,
based on locality of RBs with respect to DRB?

According to base TRILL RFC 6325 whenever a Designated RBridge(DRB) on
a link detects that there is vlan mapping on the link, (by recieving
Hellos with with vlan mapping flag set or by inspecting outer vlan
mismatch with vlan tag in Hello) it revokes all appointment of vlan-x
forwarders and appoints one RBridge on the link to become appointed
forwarder for all vlans. So no load sharing of data frames are done on
a link if vlan mapping is detected on any link.

Assuming the following scenario where five RBridges are connected to
the same link which has a Vlan Mapping device and there are other end
stations connected to this link. Say RB1 is the DRB for the link. We
assume there are two regions one being the "DRB side of
link"(RB1,RB2,RB3 connected side) and other being the "Non DRB side of
link"(RB4,RB5 connected side).There is a vlan mapping device
separating the link into two regions. Why dont we loadshare data
traffic by distributing appointment of appointed forwarder to RBs in
the "DRB side of the link"? ie why can't RB1 appoint RB2,RB3 and
itself as appointed forwarder for different vlans?

   DRB side of link                                       Non DRB side of link

+--------------+           +-------------------------------+
+-----------+
+    RB1    + - - - - - + Vlan Mapping device+ - - - - -+   RB5  +
+--------------+   |    |  +-------------------------------+    |
+-----------+
                     |    |                                         |
         +-----------+ +----------+                  +------------+
         +  RB2   + +  RB3  +                  +  RB4   +
         +-----------+ +----------+                  +------------+

For DRB to identify whether a RB is on "DRB side of link" or on the
"non-DRB side of link"

1> If DRB recieves a Hello from RB with Outer vlan matching the vlan
tag in Hello and the vlan mapping flag is set in the Hello, the DRB
can assume the RB is on "DRB side of the link".

2> If DRB recieves a Hello from RB with Outer vlan different from the
vlan tag in Hello and the vlan mapping flag is set in the Hello, the
DRB can assume the RB is on "non-DRB side of the link".

Thank you,
Regards,
Somnath

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 9 Dec 2011 22:40:08 -0500

Hi Somnath,

There is always tension between simplicity and reliability on the one
hand and performance on the other hand. For TRILL, I would say
performance equates to better load spreading and better robustness in
the face of complex link (mis-)configurations.

The simplest thing, with the best performance, is just to replace all
your bridges with TRILL switches. After all, the whole Appointed
Forwarder feature is, as practical matter, to get better performance,
on links that appear multi-access to TRILL because they are bridged
LANs.

The next simplest thing would be to just have the DRB handle all
native frame traffic to and from a link via one port. This would be
pretty robust but wouldn't get you any load spreading.

TRILL adopts neither of the above simple strategies but instead tries
hard to load split and still be as robust as practical against
misconfigured bridges in a link. There are people who think that TRILL
already tries too hard.

What you are proposing is to make TRILL Appointed Forwarder logic even
more complicated so as to get some more load spreading in what I hope
would be a rare case of a multi-access TRILL link configured to do
VLAN mapping inside the link. Why not just fix the link? I imagine
most TRILL implementations will attempt to raise some sort of alarm
when VLAN mapping is detected inside a link.

A more detailed response to your specific suggestion is below.

> based on locality of RBs with respect to DRB?

Well, if the DRB had a map of the internal structure of the link and
understood how the VLANs were enable/disable/mapped on the ports of
the devices in the link, etc., then, if the DRB was clever enough, it
could sometimes get higher performance. But this seems like a
difficult problem.

> a link if vlan mapping is detected on any link.

Right. Detecting VLAN mapping within a link inside a TRILL campus
means that, from a TRILL point of view, the link configuration is
broken so, to be safe, TRILL stops load splitting. It is actually not
necessary for the DRB to decide itself to act as Appointed Forwarder
for all VLANs where native frame service is being provided. The DRB
can appoint some specific other RBridge on the link to be Appointed
Forwarder for all those VLANs. The important thing is that there be
one point of ingress/egress for all native frame traffic from/to the
link.

> itself as appointed forwarder for different vlans?

Part of the problem is your assumption that there are only two regions.
How can the DRB know that? (I re-drew your diagram assuming a
fixed width font.)

>     DRB side of link               Non-DRB side of link
>
> +-----+         +--------------------+     +-----+
> + RB1 +- - - - -+ Vlan Mapping device+ - - + RB5 +
> +-----+  |   |  +--------------------+  |  +-----+
>          |   |                          |
>     +-----+ +-----+                  +-----+
>     + RB2 + + RB3 +                  + RB4 +
>     +-----+ +-----+                  +-----+
>

What about the following network:

+-----+   +------+       +------+   +-----+
| RB1 |---| VMD1 |---+---| VMD2 |---| RB2 |
+-----+   +------+   |   +------+   +-----+
                     |
                  +--+--+
                  | ES1 |
                  +-----+

Assume that VMD1 (VLAN mapping device 1) and VMD2 are configured as
follows:

 VMD1     VMD1
  RB1     ES1
 side     side

VLAN1 <-> VLAN1
VLAN2 <-> VLAN3
VLAN3 <-> VLAN2

 VMD2     VMD2
  ES1     RB2
 side     side

VLAN1 <-> VLAN1
VLAN2 --> VLAN2
VLAN3 <-> VLAN2
VLAN2 <-- VLAN3

Say RB1 is the DRB and it announces VLAN 1, which is not mapped by
either VMD1 or VMD2, as the Designated VLAN.

Hellos sent by RB1 on VLAN 2 are VLAN 3 in the middle but arrive at
RB2 as VLAN 2. Hellos sent by RB1 on VLAN 3 are VLAN 2 in the middle
but VMD2 does not map that VLAN so they arrive at RB2 on VLAN 2, so
RB2 detects VLAN mapping and starts setting the flag indicating this
in all its Hellos. In the other direction, Hellos on VLANs 2 and 3
from RB2 get mapped twice, but the mapping cancel out so they arrive
on their original VLAN at RB1. Meanwhile RB1 and RB2 exchange Hellos
on the Designated VLAN, VLAN 1, and become adjacent.

So, according to your suggested rules, DRB RB1, seeing Hellos from RB2
on all of VLANs 1, 2, and 3, that have the VLAN mapping detected bit
on but are being received on the "right" VLAN, can conclude that RB2
is on the "DRB side" of the link and is safe to appoint a
forwarder. So, DRB RB1 appoints itself for VLAN 3 and appoints RB2 for
VLAN 2. Now, when ES1 (end station 1) sends a frame in VLAN 2, it
arrives at RB1 in VLAN 3 but at RB2 in VLAN 2, both RBs pick it up,
and it gets duplicated into the campus in different VLANs. But the
real problem is that a frame egressed by RB1 as VLAN 3 will be
ingressed by RB2 as VLAN 2. That means that you could have another
link elsewhere in the campus with the same structure but the VLANs
changed around where a frame egressed to VLAN 2 would be ingressed
from VLAN 3. Now you have a loop where a multi-destination frame could
cycle indefinitely since it is not protected by a hop count when it is
a native frame.

On the other hand, the TRILL base standard rules would, since VLAN
mapping has been detected, fall back to the known safe strategy of
using only one port for all native frame ingress and egress for the
link, making such a loop impossible.

No doubt you could suggest more complex rules and/or a more complex
VLAN mapping detected signaling. And perhaps I could find a more
complex counter-example. And so on.

How about if we just leave this part of the TRILL base protocol as it
is?

> Somnath

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: somnath chatterjee <[email-masked]>
Date: Sun, 11 Dec 2011 22:33:34 +0530

Hi Authors,

Thank you all for all the clear explanations, it was very helpful in
clearing my doubts regarding suspended state and vlan mapping.

Regards,
Somnath