Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-vlan-mapping-01.txt

From: [email-masked]
Date: Thu, 10 Dec 2009 09:30:02 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF.

	Title		: RBridge VLAN Mapping
	Author(s)	: R. Perlman, D. Eastlake 3rd, D. Dutt
	Filename	: draft-ietf-trill-rbridge-vlan-mapping-01.txt
	Pages		: 12
	Date		: 2009-12-4
	
Some bridge products perform a feature known as "VLAN mapping" or
   "VLAN ID translation", in which a bridge translates a data frame's
   VLAN ID from one VLAN to another when it forwards a frame from one
   port to another. This feature facilitates scenarios such as combining
   two bridged LANs with overlapping VLAN IDs into one bridged LAN
   without merging two communities just because they have been given the
   same VLAN ID in the original two clouds. This document describes how
   RBridges can achieve the same functionality.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-vlan-mapping-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Radia Perlman <[email-masked]>
Date: Sat, 12 Dec 2009 15:12:31 -0800

A couple of things to bring to people's attention in fewer words than 
reading the VLAN mapping draft. :-)

a) if mappings are not invertible, as in, both VLAN A and VLAN B in East 
map to VLAN C in West,
then it's not clear what to map VLAN C to, when forwarding from West to 
East.

I'd say either make that a configuration error and don't let someone 
configure two VLANs that map
to the same thing, or say that when mapping from (West, VLAN C), if both 
A and B from East map to (West, C),
then map to the highest VLAN number, or the first one listed in the 
mapping configuration table. Other
suggestions?

b) if mappings are not invertible, same example as a). and the path goes 
from East to West and then East
again, VLAN A in East might wind up getting mapped to VLAN B in East.

I don't care -- I think noninvertible mappings should be illegal.

c) another form of noninvertible mapping is (East, VLAN A : West, null), 
meaning that VLAN A in East
should be dropped instead of being forwarded to cloud West. The 
surprising result of this, if the path
goes from East to West and back to East, is that VLAN A might become 
partitioned as a result.

I don't care, especially since I can't think of any good, simple 
solution to this.

Radia

---

From: [email-masked]
Date: Mon, 14 Dec 2009 09:28:17 -0500

I'd say it would be best to define it in such a way that, once a switch has
been given a VLAN mapping from one port to another, it either rejects a
different mapping or overrides the old one, depending on how the MIB is
defined. Which is to say, make it "invertible" always.

In practice, this sort of connectivity when desired by customers is done in
a way that doesn't require VLAN mapping: you'd define "overlapping VLANs"
which allow, in this example, VLAN A as well as VLAN B to reach the ports
of VLAN C, but do not allow VLAN A and VLAN B to talk to each other (if
that were the requirement.)

In another scenario, you may have 3 different sites East, West and South,
where West wants its VLAN A to be translated to VLAN C in the East and
South wants its VLAN B to be translated to the same VLAN C in the East
(vice versa for the opposite direction). In such a case you would have 3
switches (connecting East, West and South), each of which have invertible
mappings. This is a much more common application of VLAN mapping: site
administrators define their own VLANs, then their edge switches translate
when necessary to connect into VLANs in a different site.

Regards,
Anil

[email-masked] wrote on 12/12/2009 06:12:31 PM:

> Radia Perlman <[email-masked]>
> Sent by: [email-masked]
>
> 12/12/2009 06:12 PM
>
> To
>
> [email-masked]
>
> cc
>
> Subject
>
> [rbridge] VLAN mapping anonmolies...does anyone care?
>

Please consider the environment before printing this e-mail.
________________
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
is being sent by 3Com for the sole use of the intended recipient(s) and
may contain confidential, proprietary and/or privileged information.
Any unauthorized review, use, disclosure and/or distribution by any
recipient is prohibited.  If you are not the intended recipient, please
delete and/or destroy all copies of this message regardless of form and
any included attachments and notify 3Com immediately by contacting the
sender via reply e-mail or forwarding to 3Com at [email-masked].

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 14 Dec 2009 16:22:17 -0500

Hi Anil,

> defined. Which is to say, make it "invertible" always.

I guess I don't understand the first part of what you say above. Making it
always be invertible sounds safe but it seems to me there might be cases
where you can't do that.

Say that you have two LANs with 3,000 VLANs in common that need to be mapped
but each having 1,000 local VLANs that have no corresponding VLAN in the
other LAN. It seems to me that you can't make an invertible mapping to do
this. The best you can do is just to map most of the local VLANs to oblivion
at the border and arrange your networks so the probability is very low that
the shortest path between any two RBridges in of these LANs goes through the
other LAN.

So, my current thinking it that the mapping SHOULD be invertible.

> that were the requirement.)

That sounds like VLAN groups, which are touched on in Section 4.8.3 of the
-14 version of the base protocol draft. I don't see it as having much to do
with VLAN mapping (also known as VLAN ID translation).

> when necessary to connect into VLANs in a different site.

Sure, handling N different regions isn't a problem.

> Anil

Thanks,
Donald

PS: Please do not post to this list with one of these nonsense
confidentiality notices. Everything posted here is public and everyone is
welcome to re-distribute it as widely as they like. If you can't get 3com to
omit the notice, then you need to get a non-company email account to use for
your IETF participation.