idnits 2.17.1 draft-perlman-trill-rbridge-vlan-mapping-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 281. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 290. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 297. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 303. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2008) is 5643 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-16) exists of draft-ietf-trill-rbridge-protocol-09 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Radia Perlman 2 INTERNET-DRAFT Sun Microsystems 3 Intended status: Proposed Standard Dinesh Dutt 4 Cisco 5 Donald Eastlake 3rd 6 Eastlake Enterprises 7 Expires: April 2009 October 2008 9 RBridge VLAN Mapping 10 ------- ---- ------- 11 13 Status of This Document 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Distribution of this document is unlimited. Comments should be sent 21 to the TRILL working group mailing list. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 Some bridge products perform a feature known as "VLAN mapping", in 42 which a bridge translates a data frame's VLAN ID from one VLAN to 43 another when it forwards a frame from one port to another. This 44 feature facilitates scenarios such as combining two bridged LANs with 45 overlapping VLAN IDs into one bridged LAN without merging two 46 communities just because they have been given the same VLAN ID in the 47 original two clouds. This document describes how RBridges can achieve 48 the same functionality. 50 Table of Contents 52 Status of This Document....................................1 53 Abstract...................................................1 55 1. Introduction............................................3 56 1.1 Terminology............................................4 58 2. Internal RBridges and VLAN Mapping......................5 59 3. Configuration of Cut Set VLAN Mapping RBridges..........5 60 4. Advertisement of VLAN Mappings..........................5 61 5. Translation of VLAN IDs by Cut Set RBridges.............6 62 6. Reporting Attached VLANs by Cut Set RBridges in LSPs....6 63 7. Advertising of Multicast Groups by Cut Set RBridges.....6 64 8. Endnode Advertisements by cut set RBridges..............7 66 9. IANA Considerations.....................................8 67 10. Security Considerations................................8 68 11. Normative References...................................9 69 12. Informative References.................................9 71 Copyright, Disclaimer, and Additional IPR Provisions......10 72 Authors Addresses.........................................11 74 1. Introduction 76 Bridges perform a feature known as "VLAN mapping", in which two or 77 more layer 2 clouds are connected together using a set of bridges, 78 but in which the VLAN IDs are not consistent in the different clouds. 80 The set of bridges interconnecting the clouds are known as the "cut 81 set", meaning that if that set of bridges are removed, the clouds are 82 separated. 84 Bridges in the cut set are configured to translate some set of VLAN 85 IDs in one cloud to different VLAN IDs when forwarding from one cloud 86 to the other. 88 One reason to do this is to intentionally not merge VLAN-A endnodes 89 in one layer 2 cloud with the community of VLAN-A endnodes in the 90 other cloud. 92 Another reason to do this is to intentionally merge two communities, 93 marked with different VLAN IDs in the different clouds. 95 This feature is accomplished with bridges solely by configuring 96 bridges on the cut set. 98 This document explains how to accomplish the same functionality with 99 RBridges. In this document we will assume there are two clouds 100 "East" and "West", and RBridges RB1, RB2, and RB3 that interconnect 101 the two clouds. 103 . . . +-----+ . . . 104 . . . + - - - - + RB1 + - - - - + . . . 105 . W . +-----+ . . E . 106 . e . . . a . 107 . s . +-----+ . s . . 108 . t . .+ - - - - -+ RB2 + - - - - - - +. t . 109 . . . -+-+---+ . . . 110 . C . . / | _ _ _ _ _ _+. C . . 111 l . + - - - | / . l . . 112 . o . . +-+---+ . o . . 113 u . .+ - - - -+ RB3 + - - - - - - - +. u . . 114 . d . . +-----+ d . . 115 . . . . . . . 117 We will refer to RBridges other than the cut set of RBridges as 118 "internal RBridges". 120 General familiarity with the base TRILL protocol [RFCtrill] is 121 assumed in this document. 123 1.1 Terminology 125 The same terminology and acronyms are used in this document as in 126 [RFCtrill]. 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 2. Internal RBridges and VLAN Mapping 134 Internal RBridges will not be aware that VLAN mapping is going on. 135 They will behave exactly as they would without VLAN mapping. The 136 only evidence they will have of VLAN mapping is the existence of an 137 optional TLV field that a cut set RBridge, RB1, MAY include in its 138 LSP, listing the VLAN mappings that RB1 is configured to be 139 performing. 141 Internal RBridges will ignore this field. It is only there for 142 detection of misconfiguration. 144 3. Configuration of Cut Set VLAN Mapping RBridges 146 If VLAN A in cloud "East" is to be translated into VLAN B in cloud 147 "West", a cut set RBridge RB1 must be configured, for each port, as 148 to whether that port is in East or West, and configured with VLAN 149 mappings, such as: 151 "East/VLAN A <----> West/VLAN B" 153 That mapping means that when RB1 forwards a frame on a port 154 configured to be in East to a port configured to be in West, with the 155 VLAN tag of A, it replaces the VLAN tag "A" with "B" in the inner 156 encapsulated frame. 158 Note that mappings are always symmetric, meaning that if RB1 is 159 translating tag "VLAN A" to tag "VLAN B" when forwarding from East to 160 West, it will translate tag "VLAN B" to tag "VLAN A" when forwarding 161 from West to East. 163 4. Advertisement of VLAN Mappings 165 To detect misconfiguration, a cut set RBridge RB1 MAY advertise its 166 VLAN mappings. This would be done by assigning IDs to each of the 167 clouds. All cut set RBridges SHOULD be configured with the same IDs 168 for the clouds. So, in our example, if "East" is "1" and "West" is 169 "2", and VLAN A in East is mapped to VLAN B in West, the TLV would 170 report a set of mappings, including: 172 {(1:A,2:B)} 174 5. Translation of VLAN IDs by Cut Set RBridges 176 If RB1 is configured to believe port a is in "East" and port b is in 177 "West", and RB1 is configured such that "East/VLAN A <----> West/VLAN 178 B", then when RB1 forwards a data frame from port a to port b, if the 179 received frame from port a has (inner header VLAN ID) VLAN x , then 180 RB1 changes the VLAN tag from VLAN A to VLAN B as it forwards onto 181 port b. 183 Note: This is true whether RB1 is the appointed forwarder on port a 184 for VLAN x and the frame arrives unencapsulated, or whether the frame 185 has arrived already encapsulated as a VLAN A frame. 187 Likewise, RB1 performs the same VLAN translation whether the frame is 188 unicast or multicast. 190 6. Reporting Attached VLANs by Cut Set RBridges in LSPs 192 If RB1 is configured to translate VLAN A to VLAN B, then RB1 reports, 193 in its LSP, that it is connected to both VLAN A and VLAN B, even if 194 RB1 is not appointed forwarder for either or both VLAN A or VLAN B. 196 The reason RB1 must claim to be attached to VLAN A and VLAN B is so 197 that multicast data frames for VLAN A originating in West will not 198 get filtered before reaching RB1, and multicast data frames for VLAN 199 B originating in East will also not get prematurely filtered. 201 7. Advertising of Multicast Groups by Cut Set RBridges 203 If RB1 is configured to translate VLAN A in East to VLAN B in West, 204 then RB1 MUST do one of the following, in order to ensure that a 205 multicast packet for group G in VLAN A will not be filtered inside 206 the West cloud, if there are receivers for (VLAN A, group G) in East. 207 If the cut set RBridges do nothing, then a multicast for VLAN B, 208 group G would be filtered inside the West cloud, since RBridges 209 inside the East cloud will only be requesting receipt of VLAN A, 210 group G. 212 Thus, RB1 MUST do one of the following for each mapped VLAN. It may 213 use different strategies for different VLANs. 215 a) for all IP-derived multicast addresses that have been requested by 216 any RBridges in East for VLAN A, RB1 reports connectivity to those 217 multicast addresses in VLAN B. Likewise, for all IP-derived 218 multicast addresses that have been requested by any RBridges in 219 West for VLAN B, RB1 reports connectivity to those multicast 220 addresses in VLAN A. 222 b) RB1 reports connectivity to an IPv4 multicast router and an IPv6 223 multicast router. 225 8. Endnode Advertisements by cut set RBridges 227 TRILL allows RBridges to optionally advertise attached endnodes. This 228 endnode advertisement protocol uses special instances of IS-IS known 229 as ESADI (End System Address Distribution Instance). 231 If cut set RBridge RB1 is translating VLAN A (in East) to VLAN B (in 232 West), and RB1 is doing ESADI for its attached endnodes in VLAN A, it 233 should transmit the ESADI advertisement tagged with VLAN A when 234 forwarding onto ports labeled as "East", and transmit the same ESADI 235 advertisement when forwarding onto ports labeled as "West". An East 236 VLAN-A ESADI generated by any RBridge in East will automatically get 237 translated into a VLAN B ESADI when forwarding into West, because 238 ESADIs are handled just like ordinary encapsulated data frames, the 239 VLAN tag to which the ESADI belongs is the VLAN tag on the inner data 240 frame, and that VLAN tag will be translated by (properly configured) 241 cut set RBridges when forwarding between East and West. 243 9. IANA Considerations 245 This document requires no IANA actions. This section should be 246 deleted by the RFC Editor on publication. 248 10. Security Considerations 250 See [RFCtrill] for general RBridge Security Considerations. 252 If cut set RBridges have misconfigured VLAN mappings, VLANs may be 253 inadvertently partitioned or inadvertently merged and frames may be 254 delivered in the wrong VLAN. However, misconfiguration of VLAN 255 mapping will not cause loops. 257 11. Normative References 259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 260 Requirement Levels", BCP 14, RFC 2119, March 1997 262 [RFCtrill] R. Perlman, D. Eastlake, D. Dutt, S. Gai, and A. Ghanwani, 263 draft-ietf-trill-rbridge-protocol-09.txt, work in progress. 265 12. Informative References 267 None. 269 Copyright, Disclaimer, and Additional IPR Provisions 271 Copyright (C) The IETF Trust 2008. This document is subject to the 272 rights, licenses and restrictions contained in BCP 78, and except as 273 set forth therein, the authors retain all their rights. 275 This document and the information contained herein are provided on an 276 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 277 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 278 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 279 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 280 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 281 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 283 The IETF takes no position regarding the validity or scope of any 284 Intellectual Property Rights or other rights that might be claimed to 285 pertain to the implementation or use of the technology described in 286 this document or the extent to which any license under such rights 287 might or might not be available; nor does it represent that it has 288 made any independent effort to identify any such rights. Information 289 on the procedures with respect to rights in RFC documents can be 290 found in BCP 78 and BCP 79. 292 Copies of IPR disclosures made to the IETF Secretariat and any 293 assurances of licenses to be made available, or the result of an 294 attempt made to obtain a general license or permission for the use of 295 such proprietary rights by implementers or users of this 296 specification can be obtained from the IETF on-line IPR repository at 297 http://www.ietf.org/ipr. 299 The IETF invites any interested party to bring to its attention any 300 copyrights, patents or patent applications, or other proprietary 301 rights that may cover technology that may be required to implement 302 this standard. Please address the information to the IETF at ietf- 303 ipr@ietf.org. 305 Authors Addresses 307 Radia Perlman 308 Sun Microsystems 309 16 Network Circle 310 Menlo Park, CA 94025 312 Phone: +1-650-960-1300 313 Email: Radia.Perlman@sun.com 315 Dinesh G. Dutt 316 Cisco Systems 317 170 Tasman Drive 318 San Jose, CA 95134-1706 USA 320 Phone: +1-408-527-0955 321 EMail: ddutt@cisco.com 323 Donald Eastlake 3rd 324 Eastlake Enterprises 325 155 Beaver Street 326 Milford, MA 01757 328 Tel: +1-508-634-2066 329 Email: d3e3e3@gmail.com