One document matched: draft-ietf-trill-rbridge-vlan-mapping-02.txt
Differences from draft-ietf-trill-rbridge-vlan-mapping-01.txt
TRILL Working Group Radia Perlman
INTERNET-DRAFT Intel Labs
Intended status: Proposed Standard Dinesh Dutt
Cisco Systems
Donald Eastlake 3rd
Stellar Switches
Expires: September 6, 2010 March 7, 2010
RBridges: VLAN Mapping
<draft-ietf-trill-rbridge-vlan-mapping-02.txt>
Abstract
Some bridge products provide 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.
Status of This Document
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent
to the TRILL working group mailing list.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
R. Perlman, et al. [Page 1]
INTERNET-DRAFT RBridges: VLAN Mapping
Table of Contents
Abstract...................................................1
Status of This Document....................................1
1. Introduction............................................3
1.1 Terminology............................................4
2. Internal RBridges and VLAN Mapping......................5
3. Configuration of Cut Set VLAN Mapping RBridges..........5
4. Advertisement of VLAN Mappings..........................6
5. Translation of VLAN IDs by Cut Set RBridges.............6
6. Reporting Attached VLANs by Cut Set RBridges in LSPs....7
7. Advertising of Multicast Groups by Cut Set RBridges.....7
8. Endnode Advertisements by cut set RBridges..............7
9. IANA Considerations.....................................9
10. Security Considerations................................9
11. Normative References..................................10
12. Informative References................................10
Appendix Z: Change Summary................................11
Changes from -00 to -01...................................11
Changes from -01 to -02...................................11
Authors' Addresses........................................12
Copyright, Disclaimer, and Additional IPR Provisions......13
R. Perlman, et al. [Page 2]
INTERNET-DRAFT RBridges: VLAN Mapping
1. Introduction
Bridges perform a feature known as "VLAN mapping" or "VLAN ID
translation", in which two or more layer 2 clouds are connected
together using a set of bridges, but in which the VLAN IDs are not
consistent in the different clouds.
The set of bridges interconnecting the clouds are known as the "cut
set", meaning that if that set of bridges is removed, the clouds are
separated.
Bridges in the cut set are configured to translate some set of VLAN
IDs in one cloud to different VLAN IDs when forwarding from one cloud
to the other.
One reason to do this is to intentionally not merge VLAN-A endnodes
in one layer 2 cloud with the community of VLAN-A endnodes in the
other cloud.
Another reason to do this is to intentionally merge two communities,
marked with different VLAN IDs in the different clouds.
This feature is accomplished solely by configuring bridges in the cut
set.
This document explains how to accomplish the same functionality with
RBridges. In this document we will assume there are two clouds
"East" and "West", and RBridges RB1, RB2, and RB3 that interconnect
the two clouds.
. . . +-----+ . . .
. . . + - - - - + RB1 + - - - - + . . .
. W . +-----+ . . E .
. e . . . a .
. s . +-----+ . s . .
. t . .+ - - - - -+ RB2 + - - - - - - +. t .
. . . -+-+---+ . . .
. C . . / | _ _ _ _ _ _+. C . .
l . + - - - | / . l . .
. o . . +-+---+ . o . .
u . .+ - - - -+ RB3 + - - - - - - - +. u . .
. d . . +-----+ d . .
. . . . . . .
We will refer to RBridges other than the cut set of RBridges as
"internal RBridges".
General familiarity with the base TRILL protocol [RFCtrill] is
assumed in this document.
R. Perlman, et al. [Page 3]
INTERNET-DRAFT RBridges: VLAN Mapping
1.1 Terminology
The same terminology and acronyms are used in this document as in
[RFCtrill].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
R. Perlman, et al. [Page 4]
INTERNET-DRAFT RBridges: VLAN Mapping
2. Internal RBridges and VLAN Mapping
Internal RBridges will not be aware that VLAN mapping is going on.
They will behave exactly as they would without VLAN mapping. The
only evidence they will have of VLAN mapping is the existence of an
optional TLV that a cut set RBridge, RB1, MAY include in its LSP
[layer2], listing the VLAN mappings that RB1 is configured to be
performing.
Internal RBridges will ignore this TLV field. It is only there for
detection of misconfiguration.
3. Configuration of Cut Set VLAN Mapping RBridges
If VLAN A in cloud "East" is to be translated into VLAN B in cloud
"West", a cut set RBridge RB1 MUST be configured, for every port, as
to whether that port is in East or West, and configured with VLAN
mappings, such as:
"East/VLAN A <----> West/VLAN B"
That mapping means that when RB1 forwards a frame on a port
configured to be in East to a port configured to be in West, with the
VLAN tag of A, it replaces the VLAN tag "A" with "B" in the inner
encapsulated frame.
Note that mappings are always symmetric, meaning that if RB1 is
translating tag "VLAN A" to tag "VLAN B" when forwarding from East to
West, it will translate tag "VLAN B" to tag "VLAN A" when forwarding
from West to East.
The complete rules for a cut set RBridge forwarding a frame from port
X in VLAN A to port Y are as follows:
1. If the ports connect to the same cloud, the frame is forwarded
without VLAN translation.
2. If the ports connect to different clouds then
2.a If there is a translation in effect for VLAN A frames arriving
from the cloud to which port X connects to the cloud to which
port Y connects, the VLAN ID is changed according to the
translation.
2.b If there is no translation in effect for VLAN A frames
arriving from the cloud to which port X connects to the cloud
to which port Y connects, the frame is forwarded without
translating the VLAN.
R. Perlman, et al. [Page 5]
INTERNET-DRAFT RBridges: VLAN Mapping
A cut set RBridge MAY be configured with a translation from a valid
VLAN A to VLAN ID zero, which means to drop frames in VLAN A at the
cut set RBridge, but this may result in partitioning VLAN A as
follows: In the diagram below, if the link between RBwest1 and
RBwest2 fails, then the shortest path from RBwest1 to RBwest2 may be
through RBcut1, RBeast1, and RBcut2. RBcut1 and RBcut2 might be
configured to map VLAN A to zero, dropping VLAN A frames, perhaps in
an attempt to keep VLAN A frames confined to the West region. If so,
the failure of the link between RBwest1 and RBwest2 partitions VLAN A
in the West region since the RBridges will try to forward the frames
via RBcut1-RBeast1-RBcut2 and they will be dropped at RBcut1 or
RBcut2.
---+
|
+--+------+ +--------+ |
---+ RBwest1 +-----+ RBcut1 +-------+ | +---
+-+---+---+ +--------+ | | |
| | +-+--+--+-+
---+ | | RBeast1 +---
| +-+--+--+-+
+-----+---+ +--------+ | | |
---+ RBwest2 +-----+ RBcut2 +-------+ | +---
+--+------+ +--------+ |
|
---+
4. Advertisement of VLAN Mappings
To detect misconfiguration, a cut set RBridge RB1 MAY advertise its
VLAN mappings in its LSP. This is done by assigning 16-bit IDs to
each of the clouds by manual configuration. All cut set RBridges
SHOULD be configured with the same IDs for the clouds. So, in our
example, if "East" is "1" and "West" is "2", and VLAN A in East is
mapped to VLAN B in West, the TLV [layer2] would report a set of
mappings, including:
{(1:A,2:B)}
5. Translation of VLAN IDs by Cut Set RBridges
If RB1 is configured to believe port X is in "East" and port Y is in
"West", and RB1 is configured such that "East/VLAN A <----> West/VLAN
B", then when RB1 forwards data frames from port X to port Y, if the
received frame from port X has Inner.VLAN (inner header VLAN ID) VLAN
A , then RB1 changes the VLAN tag from VLAN A to VLAN B as it
R. Perlman, et al. [Page 6]
INTERNET-DRAFT RBridges: VLAN Mapping
forwards onto port Y.
Note: This is true whether RB1 is the appointed forwarder on port X
for VLAN A and the frame arrives unencapsulated, or whether the frame
has arrived already encapsulated as a VLAN A frame.
Likewise, RB1 performs the same VLAN translation whether the frame is
known unicast or multi-destination.
6. Reporting Attached VLANs by Cut Set RBridges in LSPs
If RB1 is configured to translate VLAN A in east to VLAN B in west,
then RB1 reports, in its LSP, that it is connected to both VLAN A and
VLAN B, even if RB1 is not appointed forwarder for either or both
VLAN A or VLAN B.
The reason RB1 must claim to be attached to VLAN A and VLAN B is so
that multi-destination data frames for VLAN A originating in West
will not get filtered before reaching RB1, and multi-destination data
frames for VLAN B originating in East will also not get prematurely
filtered.
7. Advertising of Multicast Groups by Cut Set RBridges
If RB1 is configured to translate VLAN A in East to VLAN B in West,
then RB1 MUST take steps as described below in order to ensure that a
multicast packet for group G in VLAN A will not be filtered inside
the West cloud, if there are receivers for (VLAN A, group G) in East
and vice versa. If the cut set RBridges do nothing, then a multicast
for VLAN B, group G would be filtered inside the West cloud, since
RBridges inside the East cloud will only be requesting receipt of
VLAN A, group G.
To solve this problem RB1 MUST report connectivity to an IPv4
multicast router and an IPv6 multicast router for both VLANs A and B.
8. Endnode Advertisements by cut set RBridges
TRILL allows RBridges to optionally advertise attached endnodes. This
endnode advertisement uses the TRILL ESADI (End System Address
Distribution Information) protocol.
If cut set RBridge RB1 is translating VLAN A (in East) to VLAN B (in
West), and RB1 is doing ESADI for its attached endnodes in VLAN A, it
R. Perlman, et al. [Page 7]
INTERNET-DRAFT RBridges: VLAN Mapping
should transmit the ESADI advertisement inner tagged with VLAN A when
forwarding onto ports labeled as "East", and transmit the same ESADI
advertisement inner tagged with VLAN B when forwarding onto ports
labeled as "West". An East VLAN-A ESADI generated by any RBridge in
East will automatically get translated into a VLAN B ESADI when
forwarding into West, because ESADIs are handled just like ordinary
encapsulated data frames, the VLAN tag to which the ESADI belongs is
the VLAN tag on the inner data frame, and that VLAN tag will be
translated by (properly configured) cut set RBridges when forwarding
between East and West.
R. Perlman, et al. [Page 8]
INTERNET-DRAFT RBridges: VLAN Mapping
9. IANA Considerations
This document requires no IANA actions. This section should be
deleted by the RFC Editor before publication.
10. Security Considerations
See [RFCtrill] for general RBridge Security Considerations.
If cut set RBridges have misconfigured VLAN mappings, VLANs may be
inadvertently partitioned or inadvertently merged and frames may be
delivered in the wrong VLAN, which could violate security policies.
However, misconfiguration of VLAN mapping will not cause loops.
R. Perlman, et al. [Page 9]
INTERNET-DRAFT RBridges: VLAN Mapping
11. Normative References
[layer2] Banerjee, A., et al., "Extensions to IS-IS for Layer-2
Systems", draft-ietf-isis-layer2, work in progress.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[RFCtrill] R. Perlman, D. Eastlake, D. Dutt, S. Gai, and A. Ghanwani,
"RBridges: Base Protocol Specification", draft-ietf-trill-
rbridge-protocol-16.txt, work in progress.
12. Informative References
None.
R. Perlman, et al. [Page 10]
INTERNET-DRAFT RBridges: VLAN Mapping
Appendix Z: Change Summary
RFC Editor: Please delete this section on publication.
Changes from -00 to -01
1. Because RBridges can not tell what cloud other RBridges are in,
drop the "optimized" option for advertising multicast listeners
and require the advertisement of multicast router connectivity.
2. Specify that the cloud connectivity must be specified for all cut
set RBridges and that cloud IDs are manually configured and are 16
bit.
3. Expand rules for VLAN ID mapping/handling at a cut set RBridge so
as to drop frames that are for a VLAN ID to which another VLAN ID
is being mapped. (See Section 3.)
4. Add mention of "VLAN ID translation", the 802.1 name for VLAN
mapping.
5. Minor editing changes.
Changes from -01 to -02
1. Remove previous confused text about VLAN mapping (point 3 in
changes from -00 to -01).
2. Add text allowing mapping to zero to indicate frames should be
dropped. Add text and diagram explaining that this can lead to
VLAN partition.
3. Add normative reference to draft-ietf-isis-layer2.
4. Minor editing changes.
R. Perlman, et al. [Page 11]
INTERNET-DRAFT RBridges: VLAN Mapping
Authors' Addresses
Radia Perlman
Intel Labs
2200 Mission College Blvd.
Santa Clara, CA 95054-1549 USA
Phone: +1-408-765-8080
Email: Radia@alum.mit.edum
Dinesh G. Dutt
Cisco Systems
170 Tasman Drive
San Jose, CA 95134-1706 USA
Phone: +1-408-527-0955
Email: ddutt@cisco.com
Donald Eastlake 3rd
Stellar Switches, Inc.
155 Beaver Street
Milford, MA 01757 USA
Tel: +1-508-333-2270
Email: d3e3e3@gmail.com
R. Perlman, et al. [Page 12]
INTERNET-DRAFT RBridges: VLAN Mapping
Copyright, Disclaimer, and Additional IPR Provisions
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License. The definitive version of an IETF
Document is that published by, or under the auspices of, the IETF.
Versions of IETF Documents that are published by third parties,
including those that are translated into other languages, should not
be considered to be definitive versions of IETF Documents. The
definitive version of these Legal Provisions is that published by, or
under the auspices of, the IETF. Versions of these Legal Provisions
that are published by third parties, including those that are
translated into other languages, should not be considered to be
definitive versions of these Legal Provisions. For the avoidance of
doubt, each Contributor to the IETF Standards Process licenses each
Contribution that he or she makes as part of the IETF Standards
Process to the IETF Trust pursuant to the provisions of RFC 5378. No
language to the contrary, or terms, conditions or rights that differ
from or are inconsistent with the rights and licenses granted under
RFC 5378, shall have any effect and shall be null and void, whether
published or posted by such Contributor, or included with or in such
Contribution.
R. Perlman, et al. [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-23 11:31:01 |