Subject: [rbridge] Fwd: vlan mapping

From: rakesh kumar <[email-masked]>
Date: Mon, 12 Dec 2011 14:45:53 +0530

Hi,
In base RFC 6325 is not addressing things to be done with data frames on
detecting vlan mapping.
Consider the following topology,

End Device1 on vlan2--------------------RB1---------------Vlan
mapping-----------------------RB2--------------------------End devicevlan3
                                                 Access
Trunk         vlan2 -->vlan3                  Trunk             Acces

Port                Port           vlan3<--vlan2
Port               Port

+
                           +

Appointed
      Appointed

forwarder
forwarder

for
    for
                                              vlan2
                                                                      Vlan3

 If vlan2 data is sent by the end device  by 'End Device1' will be
encapsulated by access link of RB1 and it will sent on the  trunk linkwith
outer-vlan tag as designated vlan1 and inner-vlan tag vlan2 and this trill
encapsulated frame will be received on RB2 trunk  with outer-vlan tag as
designated vlan 1 and inner-vlan tag vlan 2,with out any mapping of inner
tag vlan2.As inner vlan is 2 RB2 access port wont be able to decapsulate
the trill encapsulated frame.

Apologies if i have missed something from RFC or any other ietf drafts
which might have addressed the above concern.

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

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 12 Dec 2011 10:46:22 -0500

Hi Rakesh,

> In base RFC 6325 is not addressing things to be done with data frames on

That's right. In TRILL there isn't anything "to be done" in this
case. If some link maps the Outer.VLAN, as long as the frame gets to
the next hop RBridge or RBridges, that mapping has no effect.

(I redrew yoru figure below because these typically come through
somewhat garbled. In the future please either send an image or do the
diagram in a fixed width font in a separate attached .txt file).

> ES1 on vlan2--------RB1---------Vlan mapping---------RB2-------ES2 vlan3
>               Access   Trunk   vlan2 -->vlan3   Trunk   Acces
>                 Port   Port    vlan3<-- vlan2    Port   Port
>                   +                                      +
>            Appointed                                    Appointed
>            forwarder                                    forwarder
>                  for                                    for
>                vlan2                                    Vlan3
>
> If vlan2 data is sent by the end station by 'ES1' will be
> encapsulated by access link of RB1 and it will sent on the trunk
> link with outer-vlan tag as designated vlan1 and inner-vlan tag
> vlan2 and this TRILL encapsulated frame will be received on RB2
> trunk with outer-vlan tag as designated vlan 1 and inner-vlan tag
> vlan 2, with out any mapping of inner tag vlan2. As inner vlan is 2
> RB2 access port won't be able to decapsulate the TRILL encapsulated
> frame.

Your description of what happens appears to be correct. That is how
TRILL is supposed to work.

TRILL considers a VLAN to be a Layer 2 community (RFC 6325, Section
2.5) and does what it can to connect all end station ports that are in
the same VLAN. It tries to do this regardless of what VLAN blocking or
mapping is being done by non-TRILL devices inside TRILL links. This is
a specific way in which RBridges are different from bridges (also
touched on in RFC 6325, Section 6.1). Since ES1 and ES2 above are in
different VLANs, they are not supposed to be able to talk to each
other (but see below) unless you are doing some sort of shared VLAN
thing in which case both VLANs would presumably be enabled on the RB2
port towards ES2.

For TRILL Data frames, TRILL considers the link to be purely a
transport mechanism and considers it a good thing that the TRILL
encapsulation, to some limited extent, armors the native frame against
devices inside the link messing with the native frame. The
Outer.MacDA, Outer.MacSA, and Outer.VLAN of a TRILL data frame are
just transport artifacts on Ethernet links to get a TRILL Data frame
to the right next hop RBridge or RBridges. All three of these fields
are logically discarded after the frame is accepted by the next hop
RBridge so changes made to the Outer.VLAN, including adding one if the
TRILL Data frame was untagged or completely removing the Outer.VLAN
tag, have no effect once the TRILL Data frame is accepted by the next
hop RBridge or RBridges.

Trying to allow TRILL-ignorant devices inside an Ethernet link to map
Inner.VLANs, or have that effect, has a number of problems:

- It's impossible in general. Since the device is TRILL ignorant, it
  can't touch anything after the TRILL Ethertype. And what do you do
  if you have a device that maps the Outer.VLAN but is then followed
  by a device tha strips VLAN tags so the frame arrives at the
  destination RBridge untagged and all signs of the Outer.VLAN mapping
  have already been discarded?

- It's somewhat dangerous. TRILL uses real routing and ECMP. There is
  no guarantee of symmetric paths. Inconsistent VLAN mappings on
  different routes might mess up address learning or lead to loops.

If you want to have different regions of your campus where VLAN IDs
(or priorities) mean different things than they do in other parts of
your campus, you need to use a TRILL aware mechanism such as in
http://tools.ietf.org/html/draft-ietf-trill-rbridge-vlan-mapping-06
which has safeguards in providing for the announcement of
configuration so there is at least some chance of detecing
inconsistent configurations of such mappings.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

> Apologies if i have missed something from RFC or any other ietf drafts which
> might have addressed the above concern.
>
> Regards,
> Rakesh