TRILL Working Group Radia Perlman INTERNET-DRAFT Sun Microsystems Intended status: Proposed Standard Dinesh Dutt Cisco Donald Eastlake 3rd Eastlake Enterprises Expires: April 2009 October 2008 RBridge VLAN Mapping ------- ---- ------- Status of This Document By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Some bridge products perform a feature known as "VLAN mapping", 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. R. Perlman, et. al. [Page 1] INTERNET-DRAFT RBridge VLAN Mapping Table of Contents Status of This Document....................................1 Abstract...................................................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..........................5 5. Translation of VLAN IDs by Cut Set RBridges.............6 6. Reporting Attached VLANs by Cut Set RBridges in LSPs....6 7. Advertising of Multicast Groups by Cut Set RBridges.....6 8. Endnode Advertisements by cut set RBridges..............7 9. IANA Considerations.....................................8 10. Security Considerations................................8 11. Normative References...................................9 12. Informative References.................................9 Copyright, Disclaimer, and Additional IPR Provisions......10 Authors Addresses.........................................11 R. Perlman, et. al. [Page 2] INTERNET-DRAFT RBridge VLAN Mapping 1. Introduction Bridges perform a feature known as "VLAN mapping", 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 are 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 with bridges solely by configuring bridges on 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 RBridge 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 RBridge 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 field that a cut set RBridge, RB1, MAY include in its LSP, listing the VLAN mappings that RB1 is configured to be performing. Internal RBridges will ignore this 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 each 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. 4. Advertisement of VLAN Mappings To detect misconfiguration, a cut set RBridge RB1 MAY advertise its VLAN mappings. This would be done by assigning IDs to each of the clouds. 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 would report a set of mappings, including: {(1:A,2:B)} R. Perlman, et. al. [Page 5] INTERNET-DRAFT RBridge VLAN Mapping 5. Translation of VLAN IDs by Cut Set RBridges If RB1 is configured to believe port a is in "East" and port b is in "West", and RB1 is configured such that "East/VLAN A <----> West/VLAN B", then when RB1 forwards a data frame from port a to port b, if the received frame from port a has (inner header VLAN ID) VLAN x , then RB1 changes the VLAN tag from VLAN A to VLAN B as it forwards onto port b. Note: This is true whether RB1 is the appointed forwarder on port a for VLAN x 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 unicast or multicast. 6. Reporting Attached VLANs by Cut Set RBridges in LSPs If RB1 is configured to translate VLAN A to VLAN B, 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 multicast data frames for VLAN A originating in West will not get filtered before reaching RB1, and multicast 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 do one of the following, 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. 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. Thus, RB1 MUST do one of the following for each mapped VLAN. It may use different strategies for different VLANs. a) for all IP-derived multicast addresses that have been requested by any RBridges in East for VLAN A, RB1 reports connectivity to those multicast addresses in VLAN B. Likewise, for all IP-derived multicast addresses that have been requested by any RBridges in West for VLAN B, RB1 reports connectivity to those multicast R. Perlman, et. al. [Page 6] INTERNET-DRAFT RBridge VLAN Mapping addresses in VLAN A. b) RB1 reports connectivity to an IPv4 multicast router and an IPv6 multicast router. 8. Endnode Advertisements by cut set RBridges TRILL allows RBridges to optionally advertise attached endnodes. This endnode advertisement protocol uses special instances of IS-IS known as ESADI (End System Address Distribution Instance). 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 should transmit the ESADI advertisement tagged with VLAN A when forwarding onto ports labeled as "East", and transmit the same ESADI advertisement 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 7] INTERNET-DRAFT RBridge VLAN Mapping 9. IANA Considerations This document requires no IANA actions. This section should be deleted by the RFC Editor on 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. However, misconfiguration of VLAN mapping will not cause loops. R. Perlman, et. al. [Page 8] INTERNET-DRAFT RBridge VLAN Mapping 11. Normative References [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, draft-ietf-trill-rbridge-protocol-09.txt, work in progress. 12. Informative References None. R. Perlman, et. al. [Page 9] INTERNET-DRAFT RBridge VLAN Mapping Copyright, Disclaimer, and Additional IPR Provisions Copyright (C) The IETF Trust 2008. This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. R. Perlman, et. al. [Page 10] INTERNET-DRAFT RBridge VLAN Mapping Authors Addresses Radia Perlman Sun Microsystems 16 Network Circle Menlo Park, CA 94025 Phone: +1-650-960-1300 Email: Radia.Perlman@sun.com 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 Eastlake Enterprises 155 Beaver Street Milford, MA 01757 Tel: +1-508-634-2066 Email: d3e3e3@gmail.com R. Perlman, et. al. [Page 11]