idnits 2.17.1 draft-ietf-trill-rbridge-vlan-mapping-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document date (January 4, 2014) is 3736 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Radia Perlman 2 INTERNET-DRAFT Intel Labs 3 Intended status: Proposed Standard Anil Rijhsinghani 4 HP Networking 5 Donald Eastlake 6 Huawei 7 Ayan Banerjee 8 Insieme 9 Dinesh Dutt 10 Cumulus 11 Expires July 3, 2014 January 4, 2014 13 TRILL: Campus Label and Priority Regions 14 16 Abstract 18 Within a TRILL campus, the data label (VLAN or Fine Grained Label) 19 and priority of TRILL encapsulated frames is preserved. However, in 20 some cases it may be desired that data label and/or priority be 21 mapped at the boundary between regions of such a campus. This 22 document describes an optional TRILL switch feature to provide this 23 function. 25 Status of This Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Distribution of this document is unlimited. Comments should be sent 31 to the TRILL working group mailing list. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 45 Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 Table of Contents 50 1. Introduction............................................3 51 1.1 TRILL Campus Regions...................................4 52 1.2 Terminology............................................5 54 2. Internal and Cut Set Configuration and Mappings.........6 55 2.1 Multiple Crossings.....................................7 56 2.2 Native Frame Considerations............................8 57 2.3 More than Two Regions..................................8 58 2.4 Mapping Implementation.................................9 60 3. End Node Address Learning Between Regions..............11 61 4. Cut Set Attraction of Labels and Multicast.............12 62 5. Advertisement of Label and Priority Mappings...........13 64 6. IANA Considerations....................................13 65 7. Security Considerations................................13 66 8. Normative References...................................14 67 9. Informative References.................................14 69 Appendix Z: Change Summary................................15 71 Authors' Addresses........................................18 73 1. Introduction 75 The IETF TRILL protocol provides transparent forwarding, with a 76 number of additional features, by use of link state routing and 77 encapsulation with a hop count as specified in [RFC6325] [RFC6327bis] 78 [RFCclear] and [RFCfgl]. 80 Devices implementing the TRILL protocol are called TRILL switches or 81 RBridges (Routing Bridges). A TRILL campus is an area of TRILL 82 switches and possibly bridges bounded by and interconnecting end 83 stations and Layer 3 routers, analogous to a customer bridge LAN 84 (which is an area of bridges interconnecting end stations, Layer 3 85 routers, and TRILL switches). In a TRILL campus, native frames (as 86 defined in [RFC6325]), when they arrive at their first or ingress 87 RBridge, are encapsulated, routed in encapsulated form via zero or 88 more transit TRILL switches, and finally decapsulated and delivered 89 by their egress TRILL switch or switches. 91 TRILL switch ports have some features specified in IEEE 802.1Q as 92 described in [RFC6325], with TRILL being implemented above those 93 ports. Such ports provide for the association of incoming frames with 94 a particular frame priority and customer VLAN (see Appendix D of 95 [RFC6325]) or, in TRILL, 24-bit Fine Grained Label [RFCfgl]. 97 Bridge ports can map frame priorities, a process called "priority 98 regeneration" in IEEE 802.1. In addition, some bridge ports/products 99 provide a feature to map the customer VLAN of incoming VLAN tagged 100 frames, a process of the type called "VLAN ID translation" in IEEE 101 802.1. 103 Using such port features, it is possible to configure RBridge ports 104 to map the priority and/or VLAN of native frames being received for 105 ingress or to map the priority and/or VLAN of the frame inside a 106 TRILL Data packet after it has been decapsulated for egress through 107 an output port. But priority and/or VLAN mapping of the outer 108 priority and VLAN (Outer.VLAN) of a TRILL Data packet on Ethernet 109 links has no effect on the Data Label (Inner.VLAN or Inner.FGL 110 [RFCfgl]) in the encapsulated frame. In TRILL, the Data Label gives 111 the real label and priority of the data and these are unaffected by 112 any Ethernet port features that change only the Outer.VLAN priority 113 or VLAN ID. 115 (Note: VLAN mapping is also referred to in [RFC6325]. However, that 116 reference concerns Outer.VLAN mapping within an Ethernet link between 117 neighbor TRILL switches, a condition that may require the TRILL 118 switches connected to such a link to take precautions as described in 119 Section 4.4.5 of [RFC6325].) 121 The default for TRILL is to provide connectivity between all end 122 station and Layer 3 router ports in the same Data Lable. However, 123 there are cases where it may be desirable to have the same Data Label 124 in different regions of a TRILL campus mean different things. In that 125 case, it would be necessary for end stations or Layer 3 routers in 126 that label not to be connected if they are in different regions. It 127 might also be desirable to have connectivity between end stations in 128 different regions that are in different Data Labels if those 129 different labels in their different regions actually indicate 130 membership in the same Layer 2 community. Similar circumstances can 131 arise for priority. This document describes how to achieve this 132 though an optional TRILL switch feature. 134 An example of where this feature might be useful would be the merger 135 of two organizations which previously had separate networks. They 136 might desire to combine these networks into a new unified network 137 under unified control; however, for some period of time, there might 138 be disagreements between the previously separate networks as to Data 139 Label and/or priority assignments requiring mapping at any points of 140 interconnection. If these were Layer 2 networks, and particularly if 141 they were TRILL campuses, combination into a single unified TRILL 142 campus would be natural; but, this would probably require mapping 143 facilities, such as those specified herein, between the regions of 144 the new unified campus that had previously been separate networks. 146 Considerations related to service or S-VLANs are beyond the scope of 147 this document but are an obvious extension. 149 1.1 TRILL Campus Regions 151 The set of TRILL switches interconnecting different regions of a 152 TRILL campus are known as the "cut set", meaning that if that set of 153 switches is removed, the regions are disconnected from each other. 155 TRILL switches in the cut set can be optionally configured to 156 translate some set of Data Labels in one region to different Data 157 Labels when forwarding from that region to another region and/or to 158 block TRILL data packets with certain labels. They can be similarly 159 configured for priority. 161 This feature is accomplished solely by configuring TRILL switches in 162 the cut set. No other TRILL switches need even be aware that the 163 feature is in use. In particular, use of this feature has no effect 164 on the path (sequence of RBridges) followed by TRILL Data packets 165 (except that for multi-destination packets, tree pruning may be 166 affected). The TRILL features of optimum routing and of optional 167 multi-pathing of both unicast and multi-destination frames are 168 unaffected. 170 This document explains how to implement this feature in TRILL 171 switches (RBridges). We will usually assume there are two regions, 172 "East" and "West", and RBridges RB1, RB2, and RB3 that interconnect 173 the two regions and constitute the cut set as shown in Figure 1. 174 Extension to more than two regions is straightforward and will also 175 be briefly described. 177 . . . +-----+ . . . 178 . . . + - - - - + RB1 + - - - - + . . . 179 . W . +-----+ . . E . 180 . e . . . a . 181 . s . +-----+ . s . . 182 . t . .+ - - - - -+ RB2 + - - - - - - +. t . 183 . . . -+-+---+ . . . 184 . R . . / | _ _ _ _ _ _+. R . . 185 e . + - - - | / . e . . 186 . g . . +-+---+ . g . . 187 . i . .+ - - - -+ RB3 + - - - - - - - +. i . . 188 . o . . +-----+ o . . 189 . n . . . n . . 191 Figure 1. 193 General familiarity with the TRILL base protocol standard [RFC6325] 194 and with Fine Grained Labels [RFCfgl] is assumed in this document. 196 1.2 Terminology 198 The same terminology and acronyms are used in this document as in 199 [RFC6325] and [RFCfgl] with the following additions. 201 "Cut set" is defined in Section 1.1. 203 "Data Label" means VLAN or FGL. 205 "FGL" means Fine Grained Label [RFCfgl]. 207 "Internal RBridges" are TRILL switches other than the "cut set". 209 "label" means "Data Label" unless the context requires some other 210 meaning. 212 RBridge - an alternative name for a TRILL Switch. 214 TRILL Switch - a device which implements the TRILL protocol. 216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 217 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 218 document are to be interpreted as described in [RFC2119]. 220 2. Internal and Cut Set Configuration and Mappings 222 Internal RBridges will not be aware that label and priority mapping 223 is going on and require no configuration. They will behave exactly 224 as they would without mapping. The only evidence they might have of 225 label or priority mapping is the existence of an optional 226 informational sub-TLV that a cut set RBridge, RB1, MAY include in its 227 LSP, listing the mappings that RB1 is configured to be performing. 228 Internal RBridges will ignore this information field. It is there for 229 detection of misconfiguration. 231 Cut set RBridges are configured as follows: 233 If label A in region "East" is to be translated into label B in 234 region "West", each cut set RBridge MUST be configured, for every 235 port, as to whether that port is in East or West, and configured with 236 label mappings, such as: 238 "East/Label A -----> West/Label B" 240 That mapping means that a TRILL Data frame with an Data Label of A 241 received by RB1 on a port configured to be in East and forwarded to a 242 port configured to be in West is forwarded with the Data Label 243 changed to B. It is possible to configure asymmetric mappings; 244 however, such asymmetric mappings have negative consequences as 245 described below. For the above mapping to be symmetrically 246 configured, it would be necessary to also configure the cut set 247 RBridge in question so that frames arriving from West in Data Label B 248 would also be mapped to label A if they are destined for East, that 249 is 251 "West/Label B <-----> East/Label A" 253 Figure 2. 255 Data Labels A and B may be both VLAN IDs, both FGLs, or one a VLAN ID 256 and one an FGL. 258 Mappings of the inner priority of TRILL Data packets are configured 259 in the same way. 261 The requirement that every port of a cut set RBridge MUST be 262 configured as to which region it is in applies even to ports for a 263 link between cut set RBridges such as the link between RB2 and RB3 in 264 Figure 1. The TRILL Data packets on that link have a normal Data 265 Label and priority. In a campus with multiple regions, a label and 266 priority are, in general, meaningless unless you know the region in 267 which they occurs. So some specific region must be chosen for such a 268 link. 270 All cut set RBridges between a pair of regions SHOULD be configured 271 similarly if, as is normally the case, it is desired that the mapping 272 of a TRILL Data packet going between those regions will be 273 independent of which cut set RBridge the packet traverses. 275 The default Data Label and priority mapping is the mapping that 276 leaves labels and priorities unchanged. If a mapping has been 277 specified for both the label and priority of a frame, both mappings 278 are applied. 280 2.1 Multiple Crossings 282 Under some circumstances, a TRILL Data packet could pass through cut 283 set RBridges between a pair of regions more than once and thus have 284 its Data Label and priority mapped more than one. This is true of 285 both known unicast and multi-destination packets. For example, in 286 Figure 3, if the link between RBwest1 and RBwest2 fails, then the 287 shortest path from RBwest1 to RBwest2 may be through RBcut1, RBeast1, 288 and RBcut2. In addition, multi-destination packets are sent via a 289 distribution tree which might constrain such packets going between 290 RBwest1 and RBwest2 to be routed through RBeast1. 292 ---+ 293 | | 294 +--+------+ +--------+ | 295 ---+ RBwest1 +------+ RBcut1 +-------+ | +--- 296 +-+---+---+ +--------+ | | | 297 | | +-+--+--+-+ 298 ---+ | | RBeast1 +--- 299 | +-+--+--+-+ 300 +-----+---+ +--------+ | | | 301 ---+ RBwest2 +------+ RBcut2 +-------+ | +--- 302 +--+------+ +--------+ | 303 | | 304 ---+ 306 Figure 3. 308 If all of the mappings at RBcut1 and RBcut2 are symmetric then the 309 label and/or priority of such packets going from west to west via 310 east might get mapped twice but the second mapping would restore them 311 to their original value. Symmetric means, for example, that if RB1 is 312 translating from "label A" to "label B" when forwarding from East to 313 West, it will translate "label B" to "label A" when forwarding from 314 West to East (see Figure 2). 316 However, assume that RBcut1 and RBcut2 are configured with asymmetric 317 mappings. Then multiple cut set transit may cause problems. For 318 example, if label A in west is mapped to label B in east and label B 319 in east is mapped to label C in west, then the above scenario could 320 lead to frames in label A from west to west being unexpectedly mapped 321 to label C causing connectivity between labels A and C in west and 322 failure to deliver the frame as intended. Similar considerations 323 apply to priority mappings. The probability of such situations can 324 be minimized by providing rich interconnectivity within each region 325 and increasing the cost of links to cut set RBridges, so that packets 326 internal to a regions will be routed internally to that region except 327 in cases of low probability multiple failures. It is generally safest 328 to configure symmetric mappings. 330 2.2 Native Frame Considerations 332 If the processing model described in [RFC6325] is followed, then no 333 special handling is necessary for the case where a cut set RBridge 334 receives or transmits a native data frame, that is, where the cut set 335 RBridge is also an ingress or egress RBridge. In particular, the 336 processing model used in [RFC6325] provides that an ingressed native 337 frame is always encapsulated, even if it is to be immediately 338 decapsulated and delivered out a different port of the same RBridge 339 in native form. (Of course, implementers are free to handle this in 340 other ways provided the external behavior is the same.) Thus, 341 following this processing model, no changes are needed in an 342 implementation model of Data Label and priority mapping described 343 entirely in terms of the manipulation of the Data Label and priority 344 of TRILL data packets. 346 On the other hand, if there are no internal RBridges in a region, say 347 region West in Figure 1, then all frames will arrive from that region 348 at the cut set RBridges as native frames and all native frames sent 349 into that region will be unencapsulated. Under these limited 350 circumstances, traditional bridge port VLAN and priority mapping 351 could work to assist in performing the inter-regional mappings 352 described in this document. 354 2.3 More than Two Regions 356 A TRILL campus may have more than two regions. An RBridge is in the 357 cut set between any pair of such regions if and only if it has at 358 least one port in each of the regions. There may be pairs of regions 359 that, because of other intervening regions, have no cut set RBridges 360 connected to them both. 362 Every RBridge that is in any cut set MUST have every port configured 363 as to which region that port is in. Every RBridge port on a link 364 between two or more cut set RBridges, such as that shown between RB2 365 and RB3 in Figure 1, SHOULD be configured to be in the same region. 366 The mappings performed on TRILL Data packets transiting a cut set 367 RBridge that has ports in three or more regions depend only on the 368 region of that packet's input and output ports and are unaffected by 369 what region any other ports of that RBridge might be connected to. 371 It is RECOMMENDED that not only should any mappings be symmetric at 372 every cut set RBridge in a campus that implements the label and 373 priority mapping feature but that all cut set RBridges in the campus 374 should be configured so as to be transitively symmetric and similar. 375 That is, the mapping of the label and priority in a packet going from 376 region A to region Z should be independent of the path that frame 377 follows in the campus and symmetric with the mapping to which any 378 packet going from region Z to region A would be subjected. 380 2.4 Mapping Implementation 382 If RB1 is configured to believe port X is in "East" and port Y is in 383 "West", and RB1 is configured such that "East/Label A ----> 384 West/Label B", then when RB1 forwards data packets from port X to 385 port Y, if the received packet from port X has Data Label A, then RB1 386 changes that from label A to label B before it forwards out port Y. 387 Similarly, if priority mapping has been configured, the inner 388 priority field is mapped. In the case of FGL, the first priority, the 389 priority which affects the packets propagation through the campus, is 390 mapped. The second priority field, which is restored on egress, is 391 unaffected. 393 This mapping is performed whether RB1 is the appointed forwarder on 394 port X for VLAN A and the frame arrives unencapsulated, or whether 395 the traffic has arrived already in TRILL Data packet form. Likewise, 396 RB1 performs the same label and priority mapping, depending on input 397 and output port, whether the packet is to a known unicast address or 398 is multi-destination. 400 RBridges may implement campus region label and priority mapping in 401 any way desired so long as the externally visible behavior matches 402 this specification. Two example models of processing, forwarding- 403 oriented and port-oriented, are described below. 405 In the forwarding-oriented model, label and priority mappings 406 occur once as part of the inter-port forwarding process within a 407 TRILL switch and depend on the ordered pair { input-port-region, 408 output-port-region }. 410 In the port-oriented model, label and priority mappings occur once 411 or twice associated with input and/or output port. For example, 412 for Data Labels, each input port of a cut set RBridge could (after 413 encapsulation in the case of a native frame) map the Data Label to 414 a value in an RBridge specific generic label space, with the 415 mapping dependent only on the region to which that input port was 416 assigned. Then, the output port through which the packet was sent 417 would map from that generic label space to a specific Data Label 418 with the mapping depending only on the region to which the output 419 port was assigned. Either mapping could be the mapping that did 420 not change the label. A similar model could be used for priority 421 mapping with similar considerations. 423 These two processing models are logically interchangeable. 425 3. End Node Address Learning Between Regions 427 TRILL switches by default learn end node MAC addresses and labels 428 from the observation of ingressed native frames and the decapsulation 429 of native frames at egress, as described in [RFC6325] and [RFCfgl]. 430 This process requires no modification at internal RBridges to 431 accommodate Data Label mapping as described herein as the label will 432 be appropriate for the region where it is observed. 434 For a cut set RBridge, each port is specified to be in a particular 435 region. For such an RBridge, the Data Label portion of the addresses 436 learned at a port providing direct end station service will be that 437 label in the region to which the cut set RBridge has assigned the 438 port. Care must be taken within a cut set RBridge when using such 439 learned information. For example, if a native frame is received in 440 label X from region Y destined for MAC address Z, then address Z can 441 be looked up in the address information learned for other regions 442 only after applying any mapping for label X to that region. 444 TRILL also allows RBridges to optionally advertise attached end 445 nodes. This end node advertisement uses the TRILL ESADI (End System 446 Address Distribution Information) protocol [RFCesadi]. Because TRILL 447 ESADI packets do not include the label to which they are applicable 448 anywhere except in their Data Label and ESADI packets are forwarded 449 just like ordinary multi-destination TRILL Data packets, the label 450 mapping described above works for ESADI learning. Because of this, 451 any future ESADI extensions MUST NOT require label fields inside the 452 ESADI packet payload. 454 4. Cut Set Attraction of Labels and Multicast 456 The above described mechanisms are all that is required for Data 457 Label and priority mapping of frames sent to known unicast addresses. 458 However, to correctly handle multi-destination traffic, additional 459 steps are required. In particular, unless cut-set RBridges take 460 additional action, multi-destination packets that they need to 461 forward from one region to another might not reach the cut set 462 RBridge due to the optional pruning of distribution trees by internal 463 RBridges. 465 If RB1 is configured to translate Data Label A in East to label B in 466 West, then RB1 MUST report, in its LSP, that it is interested in both 467 label A and label B data, even if RB1 does not actually have a port 468 for which it is ingressing to or egressing from either either label A 469 or label B. If it did not do this, a multi-destination frame in 470 label A in East might be pruned before reaching RB1 and not mapped to 471 label B and forwarded to West as it should. 473 If RB1 is configured to translate label A in East to label B in West, 474 then RB1 MUST take steps to ensure that a multicast packet for group 475 G in label A will not be filtered inside the East region. To solve 476 this problem RB1 MUST report that it is connected in label A to an 477 IPv4 and IPv6 multicast router so it will get all multi-cast traffic 478 in label A and can forward appropriate multicast frames mapped to 479 label B. While this increases traffic to cut set RBridges, it does so 480 to an extent no worse that an RBridge connected to an actual Layer 3 481 multicast router or routers. 483 Because all the regions operate as a single TRILL campus with a 484 unified IS-IS link state database, it is not possible to confine the 485 above required announcements to a subset of the RBridges in the 486 campus. 488 Cut set RBridges and the links connecting them to the rest of the 489 network should be appropriately engineered for any additional traffic 490 load these requirements impose. 492 5. Advertisement of Label and Priority Mappings 494 To help detect misconfiguration, a cut set RBridge RB1 MAY advertise 495 its label and priority mappings in its LSP. To enable this, a 16-bit 496 unsigned ID is assigned to each of the regions by manual 497 configuration. All cut set RBridges SHOULD be configured with the 498 same IDs for the regions but means of accomplishing this are outside 499 of the scope of this document. So, in our example Figure 1, if 500 "East" is "1" and "West" is "2", and Data Label A in East is mapped 501 to Data Label B in West, and vice versa to be symmetric, the LSP 502 would report a set of mappings, including: 504 {label: (1:A,2:B), (2:B,1:A)} 506 Data Labels must include the type such as VLAN-42 or FGL-1234. 508 Illegal VLAN IDs (VLAN-0 or VLAN-4095 (0xFFF)) should never appear as 509 a Data Label in an LSP advertising label mappings but if they do, the 510 mapping where they appear are ignored for consistency checking. 512 Priority mappings can be similalry advertised. 514 The actual encoding of this information and the Type or sub-Type 515 values for any new TLV or sub-TLV data elements are specified in a 516 separate document 518 6. IANA Considerations 520 This document requires no IANA actions. RFC Editor: Please delete 521 this section before publication. 523 7. Security Considerations 525 See [RFC6325] for general TRILL Security Considerations and [RFCfgl] 526 for Fine Grained Label Security Considerations 528 If cut set RBridges have misconfigured Data Label mappings, labels 529 may be inadvertently partitioned or inadvertently merged and frames 530 may be delivered in the wrong label, which could violate security 531 policies. However, misconfiguration of label or priority mappings 532 cannot cause loops because mappings of labels and/or priority have no 533 effect on unicast frame routing, shortest path calculations, 534 distribution tree construction or selection, or the like. 536 8. Normative References 538 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 539 Requirement Levels", BCP 14, RFC 2119, March 1997. 541 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 542 Ghanwani, "Routing Bridges (RBridges): Base Protocol 543 Specification", RFC 6325, July 2011. 545 [RFCfgl] - D. Eastlake, M. Zhang, P. Agarwal, R. Perlman, D. Dutt, 546 "TRILL (Transparent Interconnection of Lots of Links): Fine- 547 Grained Labeling", draft-ietf-trill-fine-labeling, in RFC 548 Editor's queue. 550 9. Informative References 552 [RFC6327bis] - Eastlake, D., R. Perlman, A. Ghanwani, H. Yang, V. 553 Manral, "Routing Bridges (RBridges): Adjacency", draft-ietf- 554 trill-rfc6327bis, work in progress. 556 [RFCclear] - D. Eastlake, M. Zhang, A. Ghanwani, V. Manral, A. 557 Banerjee, draft-ietf-trill-clear-correct, in RFC Editor's 558 queue. 560 [RFCesadi] - H. Zhai, F. Hu, R. Perlman, D. Eastlake, O. Stokes, 561 "TRILL: ESADI Protocol", draft-ietf-trill-esadi, work in 562 progress. 564 Appendix Z: Change Summary 566 RFC Editor Note: Please delete this Appendix Z on publication. 568 Changes from -00 to -01 570 1. Because RBridges cannot tell what cloud other RBridges are in, 571 drop the "optimized" option for advertising multicast listeners 572 and require the advertisement of multicast router connectivity. 574 2. Specify that the cloud connectivity must be specified for all cut 575 set RBridges and that cloud IDs are manually configured and are 16 576 bit. 578 3. Expand rules for VLAN ID mapping/handling at a cut set RBridge so 579 as to drop frames that are for a VLAN ID to which another VLAN ID 580 is being mapped. (See Section 3.) 582 4. Add mention of "VLAN ID translation", the 802.1 name for VLAN 583 mapping. 585 5. Minor editing changes. 587 Changes from -01 to -02 589 1. Remove previous confused text about VLAN mapping (point 3 in 590 changes from -00 to -01). 592 2. Add text allowing mapping to zero to indicate frames should be 593 dropped. Add text and diagram explaining that this can lead to 594 VLAN partition. 596 3. Add normative reference to draft-ietf-isis-layer2. 598 4. Minor editing changes. 600 Changes from -02 to -03 602 This was a substantial re-write of the draft but there was no 603 fundamental conceptual change in the mapping mechanism. 605 1. Replace "cloud" with "region". 607 2. Introductory material was re-written to primarily reference 608 RBridge campuses and reduce references to 802.1 bridges. 610 3. Mapping of priority was added to mapping of VLANs. 612 4. Two different models are now described for implementation of 613 mappings, one in the forwarding mechanism as before and one 614 associated with the RBridge ports. 616 5. Add the specification of the TRILL GenApp TLV. Switch to using 617 TRILL GenApp TLV sub-TLVs to advertise VLAN and priority mappings. 618 Add specification of those sub-TLVs. Remove reference to draft- 619 ietf-isis-layer2. 621 6. The IANA considerations section calls for the allocation of a 622 GenApp TLV code for TRILL and provides for sub-TLVs under that 623 code where the LSP advertisement of VLAN and priority mappings was 624 moved. Set up IANA registry for TRILL GenApp sub-TLVs. 626 7. Numerous minor editing changes. 628 Changes from -03 to -04 630 1. Because distribution trees for multi-destination frames may cause 631 frames to cross region boundaries multiple times even to get 632 between RBridges within a single regions, remove facilities for 633 dropping frames at region boundaries. 635 2. Due to questions about the timing of the approval of the IS-IS 636 GenApp draft, move VLAN/priority mapping informational 637 advertisement code points and data structures to a separate draft. 639 3. Numerous minor editing changes. 641 Changes from -04 to -05 643 Increment version and update dates. Update author info. One or two 644 minor editorial changes. 646 Changes from -05 to -06 648 Update draft reference to [RFC6325]. Increment version and update 649 dates. 651 Changes from -06 to -07 653 Update author information, increment version, and update dates. 655 Changes from -07 to -08 657 Minor editorial changes, update author information, increment 658 version, and update dates. 660 Changes from -08 to -09 662 Extend to cover Fine Grained Labeling. 664 Update author information, increment version, and update dates. 666 Changes from -09 to -10 668 Update RFC 6327 reference to draft-ietf-trill-rfc6327bis. 670 Editorial changes, increment version, and update dates. 672 Authors' Addresses 674 Radia Perlman 675 Intel Labs 676 2200 Mission College Blvd. 677 Santa Clara, CA 95054-1549 USA 679 Phone: +1-408-765-8080 680 Email: Radia@alum.mit.edu 682 Anil Rijhsinghani 683 HP Networking 684 350 Campus Drive 685 Marlboro, MA 01752-3082 USA 687 Phone: +1-508-323-1251 688 Email: anil.rijhsinghani@hp.com 690 Donald Eastlake 3rd 691 Huawei Technologies 692 155 Beaver Street 693 Milford, MA 01757 USA 695 Tel: +1-508-333-2270 696 Email: d3e3e3@gmail.com 698 Ayan Banerjee 699 Insieme Networks 700 210 West Tasman Drive 701 San Jose, CA 95134 USA 703 Email: ayabaner@gmail.com 705 Dinesh G. Dutt 706 Cumulus Networks 707 1089 West Evelyn Avenue 708 Sunnyvale, CA 94086 USA 710 Email: ddutt.ietf@hobbesdutt.com 712 Copyright, Disclaimer, and Additional IPR Provisions 714 Copyright (c) 2014 IETF Trust and the persons identified as the 715 document authors. All rights reserved. 717 This document is subject to BCP 78 and the IETF Trust's Legal 718 Provisions Relating to IETF Documents 719 (http://trustee.ietf.org/license-info) in effect on the date of 720 publication of this document. Please review these documents 721 carefully, as they describe your rights and restrictions with respect 722 to this document. Code Components extracted from this document must 723 include Simplified BSD License text as described in Section 4.e of 724 the Trust Legal Provisions and are provided without warranty as 725 described in the Simplified BSD License. The definitive version of 726 an IETF Document is that published by, or under the auspices of, the 727 IETF. Versions of IETF Documents that are published by third parties, 728 including those that are translated into other languages, should not 729 be considered to be definitive versions of IETF Documents. The 730 definitive version of these Legal Provisions is that published by, or 731 under the auspices of, the IETF. Versions of these Legal Provisions 732 that are published by third parties, including those that are 733 translated into other languages, should not be considered to be 734 definitive versions of these Legal Provisions. For the avoidance of 735 doubt, each Contributor to the IETF Standards Process licenses each 736 Contribution that he or she makes as part of the IETF Standards 737 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 738 language to the contrary, or terms, conditions or rights that differ 739 from or are inconsistent with the rights and licenses granted under 740 RFC 5378, shall have any effect and shall be null and void, whether 741 published or posted by such Contributor, or included with or in such 742 Contribution.