idnits 2.17.1 draft-ietf-trill-multilevel-single-nickname-17.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 (November 12, 2021) is 888 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) -- Looks like a reference, but probably isn't: '256' on line 553 -- Looks like a reference, but probably isn't: '257' on line 554 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT M. Zhang 2 Intended Status: Proposed Standard Huawei 3 D. Eastlake 4 Futurewei 5 R. Perlman 6 EMC 7 M. Cullen 8 Painless Security 9 H. Zhai 10 JIT 11 Expires: May 11, 2022 November 12, 2021 13 Transparent Interconnection of Lots of Links (TRILL) 14 Single Area Border RBridge Nickname for Multilevel 15 draft-ietf-trill-multilevel-single-nickname-17.txt 17 Abstract 18 A major issue in multilevel TRILL is how to manage RBridge nicknames. 19 In this document, area border RBridges use a single nickname in both 20 Level 1 and Level 2. RBridges in Level 2 must obtain unique nicknames 21 but RBridges in different Level 1 areas may have the same nicknames. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Distribution of this document is unlimited. Comments should be sent 29 to the authors or the TRILL Working Group mailing list 30 trill@ietf.org>. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 https://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 44 Shadow Directories can be accessed at 45 https://www.ietf.org/shadow.html. 47 Table of Contents 49 1. Introduction............................................3 50 2. Acronyms and Terminology................................4 52 3. Nickname Handling on Border RBridges....................5 53 3.1. Actions on Unicast Packets............................5 54 3.2. Actions on Multi-Destination Packets..................6 56 4. Per-flow Load Balancing.................................9 57 4.1. L2 to L1 Ingress Nickname Replacement................9 58 4.2. L1 to L2 Egress Nickname Replacement..................9 60 5. Protocol Extensions for Discovery......................10 61 5.1. Discovery of Border RBridges in L1...................10 62 5.2. Discovery of Border RBridge Sets in L2...............10 64 6. One Border RBridge Connects Multiple Areas.............12 65 7. E-L1FS/E-L2FS Backwards Compatibility..................13 66 8. Manageability Considerations...........................13 68 9. Security Considerations................................15 69 10. IANA Considerations...................................15 71 11. References............................................16 72 11.1. Normative References................................16 73 11.2. Informative References..............................17 75 Appendix A. Level Transition Clarification................18 77 Authors' Addresses........................................19 79 1. Introduction 81 TRILL (Transparent Interconnection of Lots of Links [RFC6325] 82 [RFC7780]) multilevel techniques are designed to improve TRILL 83 scalability issues. 85 [RFC8243] (Alternatives for Multilevel Transparent Interconnection of 86 Lots of Links (TRILL)) is an educational document to explain 87 multilevel TRILL and list possible concerns. It does not specify a 88 protocol. As described in [RFC8243], there have been two proposed 89 approaches. One approach, which is referred to as the "unique 90 nickname" approach, gives unique nicknames to all the TRILL switches 91 in the multilevel campus, either by having the Level 1/Level 2 border 92 TRILL switches advertise which nicknames are not available for 93 assignment in the area, or by partitioning the 16-bit nickname into 94 an "area" field and a "nickname inside the area" field. [RFC8397] is 95 the standards track document specifying a "unique nickname" flavor of 96 TRILL multilevel. The other approach, which is referred to in 97 [RFC8243] as the "aggregated nickname" approach, involves assigning 98 nicknames to the areas, and allowing nicknames to be reused inside 99 different areas, by having the border TRILL switches rewrite the 100 nickname fields when entering or leaving an area. [RFC8243] makes the 101 case that, while unique nickname multilevel solutions are simpler, 102 aggregated nickname solutions scale better. 104 The approach specified in this standards track document is somewhat 105 similar to the "aggregated nickname" approach in [RFC8243] but with a 106 very important difference. In this document, the nickname of an area 107 border RBridge is used in both Level 1 (L1) and Level 2 (L2). No 108 additional nicknames are assigned to represent L1 areas as such. 109 Instead, multiple border RBridges are allowed and each L1 area is 110 denoted by the set of all nicknames of those border RBridges of the 111 area. For this approach, nicknames in the L2 area MUST be unique but 112 nicknames inside an L1 area can be reused in other L1 areas that also 113 use this approach. The use of the approach specified in this document 114 in one L1 area does not prohibit the use of other approaches in other 115 L1 areas in the same TRILL campus, for example the use of the unique 116 nickname approach specified in [RFC8397]. The TRILL packet format is 117 unchanged by this document, but data plane processing is changed at 118 Border RBridges and efficient high volume data flow at Border 119 RBridges might require forwarding hardware change. 121 2. Acronyms and Terminology 123 Data Label: VLAN or FGL Fine-Grained Label (FGL). 125 DBRB: Designated Border RBridge. 127 IS-IS: Intermediate System to Intermediate System [IS-IS]. 129 Level: Similar to IS-IS, TRILL has Level 1 for intra-area and Level 2 130 for inter-area. Routing information is exchanged between Level 1 131 RBridges within the same Level 1 area, and Level 2 RBridges can only 132 form relationships and exchange information with other Level 2 133 RBridges. 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in BCP 138 14 [RFC2119] [RFC8174] when, and only when, they appear in all 139 capitals, as shown here. 141 Familiarity with [RFC6325] is assumed in this document. 143 3. Nickname Handling on Border RBridges 145 This section provides an illustrative example and description of the 146 border learning border RBridge nicknames. 148 Area {2,20} level 2 Area {3,30} 149 +-------------------+ +-----------------+ +--------------+ 150 | | | | | | 151 | S--RB27---Rx--Rz----RB2---Rb---Rc--Rd---Re--RB3---Rk--RB44---D | 152 | 27 | | 39 | | 44 | 153 | ----RB20--- ----RB30--- | 154 +-------------------+ +-----------------+ +--------------+ 156 Figure 1: An Example Topology for TRILL Multilevel 158 In Figure 1, RB2, RB20, RB3 and RB30 are area border TRILL switches 159 (RBridges). Their nicknames are 2, 20, 3 and 30 respectively and are 160 used as TRILL switch identifiers in their areas [RFC6325]. Area 161 border RBridges use the set of border nicknames to denote the L1 area 162 that they are attached to. For example, RB2 and RB20 use nicknames 163 {2,20} to denote the L1 area on the left. 165 A source S is attached to RB27 and a destination D is attached to 166 RB44. RB27 has a nickname, say 27, and RB44 has a nickname, say 44 167 (and in fact, they could even have the same nickname, since the TRILL 168 switch nickname will not be visible outside these Level 1 areas). 170 3.1. Actions on Unicast Packets 172 Let's say that S transmits a frame to destination D and let's say 173 that D's location has been learned by the relevant TRILL switches 174 already. These relevant switches have learned the following: 176 1) RB27 has learned that D is connected to nickname 3. 177 2) RB3 has learned that D is attached to nickname 44. 179 The following sequence of events will occur: 181 - S transmits an Ethernet frame with source MAC = S and destination 182 MAC = D. 184 - RB27 encapsulates with a TRILL header with ingress RBridge = 27, 185 and egress RBridge = 3 producing a TRILL Data packet. 187 - RB2 and RB20 have announced in the Level 1 IS-IS area designated 188 {2,20}, that they are attached to the nicknames of all the border 189 RBridges in the Level 2 area including RB3 and RB30. Therefore, 190 IS-IS routes the packet to RB2 (or RB20, if RB20 on the least-cost 191 route from RB27 to RB3). 193 - RB2, when transitioning the packet from Level 1 to Level 2, 194 replaces the ingress TRILL switch nickname with its own nickname, 195 replacing 27 with 2. Within Level 2, the ingress RBridge field in 196 the TRILL header will therefore be 2, and the egress RBridge field 197 will be 3. (The egress nickname MAY be replaced with any area 198 nickname selected from {3,30} such as 30. See Section 4 for the 199 detail of the selection method. Here, suppose the egress nickname 200 remains 3.) Also, RB2 learns that S is attached to nickname 27 in 201 area {2,20} to accommodate return traffic. RB2 SHOULD synchronize 202 with RB20 using ESADI protocol [RFC7357] that MAC = S is attached 203 to nickname 27. 205 - The packet is forwarded through Level 2, to RB3, which has 206 advertised, in Level 2, its L2 nickname as 3. 208 - RB3, when forwarding into area {3,30}, replaces the egress 209 nickname in the TRILL header with RB44's nickname (44) based on 210 looking up D. (The ingress nickname MAY be replaced with any area 211 nickname selected from {2,20}. See Section 4 for the detail of the 212 selection method. Here, suppose the ingress nickname remains 2.) 213 So, within the destination area, the ingress nickname will be 2 214 and the egress nickname will be 44. 216 - RB44, when decapsulating, learns that S is attached to nickname 2, 217 which is one of the area nicknames of the ingress. 219 3.2. Actions on Multi-Destination Packets 221 Distribution trees for flooding of multi-destination packets are 222 calculated separately within each L1 area and in L2. When a multi- 223 destination packet arrives at the border, it needs to be transitioned 224 either from L1 to L2, or from L2 to L1. All border RBridges are 225 eligible for Level transition. However, for each multi-destination 226 packet, only one of them acts as the Designated Border RBridge (DBRB) 227 to do the transition while other non-DBRBs MUST drop the received 228 copies. By default, the border RBridge with the smallest nickname, 229 considered as an unsigned integer, is elected DBRB. All border 230 RBridges of an area MUST agree on the mechanism used to determine the 231 DBRB locally. The use of an alternative is possible, but out of the 232 scope of this document; one such mechanism is used in Section 4 for 233 load balancing. 235 As per [RFC6325], multi-destination packets can be classified into 236 three types: unicast packet with unknown destination MAC address 237 (unknown-unicast packet), multicast packet and broadcast packet. Now 238 suppose that D's location has not been learned by RB27 or the frame 239 received by RB27 is recognized as broadcast or multicast. What will 240 happen within a Level 1 area (as it would in TRILL today) is that 241 RB27 will forward the packet as multi-destination, setting its M bit 242 to 1 and choosing an L1 tree, flooding the packet on the distribution 243 tree, subject to possible pruning. 245 When the copies of the multi-destination packet arrive at area border 246 RBridges, non-DBRBs MUST drop the packet while the DBRB, say RB2, 247 needs to do the Level transition for the multi-destination packet. 248 For an unknown-unicast packet, if the DBRB has learnt the destination 249 MAC address, it SHOULD convert the packet to unicast and set its M 250 bit to 0. Otherwise, the multi-destination packet will continue to be 251 flooded as multicast packet on the distribution tree. The DBRB 252 chooses the new distribution tree by replacing the egress nickname 253 with the new tree root RBridge nickname from the area the packet is 254 entering. The following sequence of events will occur: 256 - RB2, when transitioning the packet from Level 1 to Level 2, 257 replaces the ingress TRILL switch nickname with its own nickname, 258 replacing 27 with 2. RB2 also MUST replace the egress RBridge 259 nickname with an L2 tree root RBridge nickname (say 39). In order 260 to accommodate return traffic, RB2 records that S is attached to 261 nickname 27 and SHOULD use the ESADI protocol [RFC7357] to 262 synchronize this attachment information with other border RBridges 263 (say RB20) in the area. 265 - RB20, will receive the packet flooded on the L2 tree by RB2. It is 266 important that RB20 does not transition this packet back to L1 as 267 it does for a multicast packet normally received from another 268 remote L1 area. RB20 should examine the ingress nickname of this 269 packet. If this nickname is found to be a border RBridge nickname 270 of the area {2,20}, RB2 must not forward the packet into this 271 area. 273 - The multidestination packet is flooded on the Level 2 tree to 274 reach all border routers for all L1 areas including both RB3 and 275 RB30. Suppose RB3 is the selected DBRB. The non-DBRB RB30 will 276 drop the packet. 278 - RB3, when forwarding into area {3,30}, replaces the egress 279 nickname in the TRILL header with the root RBridge nickname of a 280 distribution tree of L1 area {3,30} say 30. (Here, the ingress 281 nickname MAY be replaced with a different area nickname selected 282 from {2,20}, the set of border RBridges to the ingress area, as 283 specified in Section 4.) Now suppose that RB27 has learned the 284 location of D (attached to nickname 3), but RB3 does not know 285 where D is because this information has fallen out of cache or RB3 286 has re-started or some other reason. In that case, RB3 must turn 287 the packet into a multi-destination packet and floods it on a 288 distribution tree in the L1 area {3,30}. 290 - RB30, will receive the packet flooded on the L1 tree by RB3. It is 291 important that RB30 does not transition this packet back to L2. 292 RB30 should also examine the ingress nickname of this packet. If 293 this nickname is found to be an L2 border RBridge nickname, RB30 294 must not transition the packet back to L2. 296 - The multicast listener RB44, when decapsulating the received 297 packet, learns that S is attached to nickname 2, which is one of 298 the area nicknames of the ingress. 300 See also Appendix A. 302 4. Per-flow Load Balancing 304 Area border RBridges perform ingress/egress nickname replacement when 305 they transition TRILL data packets between Level 1 and Level 2. The 306 egress nickname will again be replaced when the packet transitions 307 from Level 2 to Level 1. This nickname replacement enables the per- 308 flow load balance which is specified in the following subsections. 309 The mechanism specified in Setion 4.1 or that in 4.2 or both is 310 necessary in general to load balance traffic across L2 paths. 312 4.1. L2 to L1 Ingress Nickname Replacement 314 When a TRILL data packet from other L1 areas arrives at an area 315 border RBridge, this RBridge MAY select one area nickname of the 316 ingress area to replace the ingress nickname of the packet so that 317 the returning TRILL data packet can be forwarded to this selected 318 nickname to help load balance return unicast traffic over multiple 319 paths. The selection is simply based on a pseudorandom algorithm as 320 discussed in Section 5.3 of [RFC7357]. With the random ingress 321 nickname replacement, the border RBridge actually achieves a per-flow 322 load balance for returning traffic. 324 All area border RBridges for an L1 area MUST agree on the same 325 pseudorandom algorithm. The source MAC address, ingress area 326 nicknames, egress area nicknames and the Data Label of the received 327 TRILL data packet are candidate factors of the input of this 328 pseudorandom algorithm. Note that the value of the destination MAC 329 address SHOULD be excluded from the input of this pseudorandom 330 algorithm, otherwise the egress RBridge could see one source MAC 331 address flip-flopping among multiple ingress RBridges. 333 4.2. L1 to L2 Egress Nickname Replacement 335 When a unicast TRILL data packet originated from an L1 area arrives 336 at an area border RBridge of that L1 area, that RBridge MAY select 337 one area nickname of the egress area to replace the egress nickname 338 of the packet. By default, it SHOULD choose the egress area border 339 RBridge with the least cost route to reach or, if there are multiple 340 equal cost egress area border RBridges, use the pseudorandom 341 algorithm as defined in Section 5.3 of [RFC7357] to select one. The 342 use of that algorithm MAY be extended to selection among some stable 343 set of egress area border RBridges that include non-least-cost 344 alternatives if it is desired to obtain more load spreading at the 345 cost of sometimes using a non-least-cost Level 2 route to forward the 346 TRILL data packet to the egress area. 348 5. Protocol Extensions for Discovery 350 The following topology change scenarios will trigger the discovery 351 processes as defined in Sections 5.1 and 5.2: 352 - A new node comes up or recovers from a previous failure. 353 - A node goes down. 354 - A link or node fails and causes partition of an L1/L2 area. 355 - A link or node whose failure have caused partitioning of an L1/L2 356 area is repaired. 358 5.1. Discovery of Border RBridges in L1 360 The following Level 1 Border RBridge APPsub-TLV will be included in 361 an E-L1FS FS-LSP fragment zero [RFC7780] as an APPsub-TLV of the 362 TRILL GENINFO-TLV. Through listening for this APPsub-TLV, an area 363 border RBridge discovers all other area border RBridges in this area. 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Type = L1-BORDER-RBRIDGE | (2 bytes) 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Length | (2 bytes) 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Sender Nickname | (2 bytes) 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 o Type: Level 1 Border RBridge (TRILL APPsub-TLV type tbd1) 375 o Length: 2 377 o Sender Nickname: The nickname the originating IS will use as the 378 L1 Border RBridge nickname. This field is useful because the 379 originating IS might own multiple nicknames. 381 5.2. Discovery of Border RBridge Sets in L2 383 The following APPsub-TLV will be included in an E-L2FS FS-LSP 384 fragment zero [RFC7780] as an APPsub-TLV of the TRILL GENINFO-TLV. 385 Through listening to this APPsub-TLV in L2, an area border RBridge 386 discovers all groups of L1 border RBridges and each such group 387 identifies an area. 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Type = L1-BORDER-RB-GROUP | (2 bytes) 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Length | (2 bytes) 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | L1 Border RBridge Nickname 1 | (2 bytes) 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | ... | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | L1 Border RBridge Nickname k | (2 bytes) 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 o Type: Level 1 Border RBridge Group (TRILL APPsub-TLV type tbd2) 403 o Length: 2 * k. If length is not a multiple of 2, the APPsub-TLV is 404 corrupt and MUST be ignored. 406 o L1 Border RBridge Nickname: The nickname that an area border 407 RBridge uses as the L1 Border RBridge nickname. The L1-BORDER-RB- 408 GROUP TLV generated by an area border RBridge MUST include all L1 409 Border RBridge nicknames of the area. It's RECOMMENDED that these 410 k nicknames are ordered in ascending order according to the 411 2-octet nickname considered as an unsigned integer. 413 When an L1 area is partitioned [RFC8243], border RBridges will re- 414 discover each other in both L1 and L2 through exchanging LSPs. In L2, 415 the set of border RBridge nicknames for this splitting area will 416 change. Border RBridges that detect such a change MUST flush the 417 reachability information associated to any RBridge nickname from this 418 changing set. 420 6. One Border RBridge Connects Multiple Areas 422 It's possible that one border RBridge (say RB1) connects multiple L1 423 areas. RB1 SHOULD use a single area nickname for itself for all these 424 areas to minimize nickname consumption and the number of nicknames 425 being advertised in L2; however, such a border RBridge might have to 426 hold multiple nicknames, for example it might the root of multiple L1 427 or multiple L2 distribution trees. 429 Nicknames used within one of these L1 areas can be reused within 430 other areas. It's important that packets destined to those duplicated 431 nicknames are sent to the right area. Since these areas are connected 432 to form a layer 2 network, duplicated {MAC, Data Label} across these 433 areas SHOULD NOT occur (see Section 4.2.6 of [RFC6325] for tie 434 breaking rules). Now suppose a TRILL data packet arrives at the area 435 border nickname of RB1. For a unicast packet, RB1 can look up the 436 {MAC, Data Label} entry in its MAC table to identify the right 437 destination area (i.e., the outgoing interface) and the egress 438 RBridge's nickname. For a multicast packet for each attached L1 439 area: either RB1 is not the DBRB and RB1 will not transition the 440 packet or RB1 is the DBRB. If RB1 is the DBRB, RB1 follows the 441 following rules: 443 - if this packet originated from an area out of the connected areas, 444 RB1 replicates this packet and floods it on the proper Level 1 445 trees of all the areas in which it acts as the DBRB. 447 - if the packet originated from one of the connected areas, RB1 448 replicates the packet it receives from the Level 1 tree and floods 449 it on other proper Level 1 trees of all the areas in which it acts 450 as the DBRB except the originating area (i.e., the area connected 451 to the incoming interface). RB1 might also receive the replication 452 of the packet from the Level 2 tree. This replication MUST be 453 dropped by RB1. It recognizes such packets by their ingress 454 nickname being the nickname of one of the border RBridges of an L1 455 area for which the receiving border RBridge is DBRB. 457 7. E-L1FS/E-L2FS Backwards Compatibility 459 All Level 2 RBridges MUST support E-L2FS [RFC7356] [RFC7780]. The 460 Extended TLVs defined in Section 5 are to be used in Extended Level 461 1/2 Flooding Scope (E-L1FS/E-L2FS) PDUs. Area border RBridges MUST 462 support both E-L1FS and E-L2FS. RBridges that do not support both 463 E-L1FS or E-L2FS cannot serve as area border RBridges but they can 464 appear in an L1 area acting as non-area-border RBridges. 466 8. Manageability Considerations 468 If an L1 Border RBridge Nickname is configured at an RBridge and that 469 RBridge has both L1 and L2 adjacencies, the multilevel feature as 470 specified in this document is turned on for that RBridge and it 471 normally uses an L2 nickname in both L1 and L2 although, as provided 472 below, such an RBridge may have to fall back to multilevel unique 473 nickname behavior [RFC8397] in which case it uses this L1 nickname. 474 In contrast, unique nickname multilevel as specified in [RFC8397] is 475 enabled by the presence of L1 and L2 adjacencies without an L1 Border 476 RBridge Nickname being configured. RBridges supporting only unique 477 nickname multilevel do not support the configuration of an L2 Border 478 RBridge Nickname. RBridges supporting only the single level TRILL 479 base protocol specified in [RFC6325] do not support L2 adjacencies. 481 RBridges that support and are configured to use single nickname 482 multilevel as specified in this document MUST support unique nickname 483 multilevel ([RFC8397]). If there are multiple border RBridges 484 between an L1 area and L2 and one or more of them only support or are 485 only configured for unique nickname multilevel ([RFC8397]), any of 486 these border RBridges that are configured to use single nickname 487 multilevel MUST fall back to behaving as a unique nickname border 488 RBridge for that L1 area. Because overlapping sets of RBridges may be 489 the border RBridges for different L1 areas, an RBridge supporting 490 single nickname MUST be able to simultaneously support single 491 nickname for some of its L1 areas and unique nickname for others. For 492 example, RB1 and RB2 might be border RBridges for L1 area A1 using 493 single nickname while RB2 and RB3 are border RBridges for area A2. If 494 RB3 only supports unique nicknames then RB2 must fall back to unique 495 nickname for area A2 but continue to support single nickname for area 496 A1. Operators SHOULD be notified when this fall back occurs. The 497 presence of border RBridges using unique nickname multilevel can be 498 detected because they advertise in L1 the blocks of nicknames 499 available within that L1 area. 501 In both the unique nickname approach specified in [RFC8397] and the 502 single nickname aggregated approach specified in this document, an 503 RBridge that has L1 and L2 adjacencies uses the same nickname in L1 504 and L2. If an RBridge is configured with an L1 Border RBridge 505 Nickname for any a Level 1 area, it uses this nickname across the 506 Level 2 area. This L1 Border RBridge Nickname cannot be used in any 507 other Level 1 area except other Level 1 areas for which the same 508 RBridge is a border RBridge with this L1 Border RBridge Nickname 509 configured. 511 In addition to the manageability considerations specified above, the 512 manageability specifications in [RFC6325] still apply. 514 Border RBridges replace ingress and/or egress nickname when a TRILL 515 data packet traverses TRILL L2 area. A TRILL OAM message will be 516 forwarded through the multilevel single nickname TRILL campus using a 517 MAC address belonging to the destination RBridge [RFC7455]. 519 9. Security Considerations 521 For general TRILL Security Considerations, see [RFC6325]. 523 The newly defined TRILL APPsub-TLVs in Section 5 are transported in 524 IS-IS PDUs whose authenticity can be enforced using regular IS-IS 525 security mechanism [IS-IS] [RFC5310]. Malicious devices may also fake 526 the APPsub-TLVs to attract TRILL data packets, interfere with 527 multilevel TRILL operation, induce excessive state in TRILL switches 528 (or in any bridges that may be part of the TRILL campus), etc. For 529 this reason, RBridges SHOULD be configured to use the IS-IS 530 Authentication TLV (10) in their IS-IS PDUs so that IS-IS security 531 [RFC5310] can be used to authenticate those PDUs and discard them if 532 they are forged. 534 Using a variation of aggregated nicknames, and the resulting possible 535 duplication of nicknames between areas, increases the possibility of 536 a TRILL Data packet being delivered to the wrong egress RBridge if 537 areas are unexpectedly merged as compared with a scheme were all 538 nicknames in the TRILL campus are, except as a transient condition, 539 unique such as the scheme in [RFC8397]. However, in many cases the 540 data would be discarded at that egress RBridge because it would not 541 match a known end station data label/MAC address. 543 10. IANA Considerations 545 IANA is requested to allocate two new types under the TRILL GENINFO 546 TLV [RFC7357] from the range allocated by standards action for the 547 TRILL APPsub-TLVs defined in Section 5. The following entries are 548 added to the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application 549 Identifier 1" Registry on the TRILL Parameters IANA web page. 551 Type Name Reference 552 --------- ---- --------- 553 tbd1[256] L1-BORDER-RBRIDGE [This document] 554 tbd2[257] L1-BORDER-RB-GROUP [This document] 556 11. References 558 11.1. Normative References 560 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 561 Requirement Levels", BCP 14, RFC 2119, DOI 562 10.17487/RFC2119, March 1997, . 565 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 566 Ghanwani, "Routing Bridges (RBridges): Base Protocol 567 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 568 . 570 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 571 Scope Link State PDUs (LSPs)", RFC 7356, DOI 572 10.17487/RFC7356, September 2014, . 575 [RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 576 Stokes, "Transparent Interconnection of Lots of Links 577 (TRILL): End Station Address Distribution Information 578 (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, 579 September 2014, . 581 [RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake 582 3rd, D., Aldrin, S., and Y. Li, "Transparent 583 Interconnection of Lots of Links (TRILL): Fault 584 Management", RFC 7455, DOI 10.17487/RFC7455, March 2015, 585 . 587 [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 588 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 589 Lots of Links (TRILL): Clarifications, Corrections, and 590 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 591 . 593 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 594 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 595 2017, . 597 [RFC8397] Zhang, M., Eastlake 3rd, D., Perlman, R., Zhai, H., and D. 598 Liu, "Transparent Interconnection of Lots of Links (TRILL) 599 Multilevel Using Unique Nicknames", RFC 8397, DOI 600 10.17487/RFC8397, May 2018, . 603 11.2. Informative References 605 [IS-IS] International Organization for Standardization, ISO/IEC 606 10589:2002, "Information technology -- Telecommunications 607 and information exchange between systems -- Intermediate 608 System to Intermediate System intra-domain routeing 609 information exchange protocol for use in conjunction with 610 the protocol for providing the connectionless-mode network 611 service", ISO 8473, Second Edition, November 2002. 613 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 614 and M. Fanto, "IS-IS Generic Cryptographic Authentication", 615 RFC 5310, DOI 10.17487/RFC5310, February 2009, 616 . 618 [RFC8243] Perlman, R., Eastlake 3rd, D., Zhang, M., Ghanwani, A., and 619 H. Zhai, "Alternatives for Multilevel Transparent 620 Interconnection of Lots of Links (TRILL)", RFC 8243, DOI 621 10.17487/RFC8243, September 2017, . 624 Appendix A. Level Transition Clarification 626 It's possible that an L1 RBridge is only reachable from a non-DBRB 627 border RBridge. If this non-DBRB RBridge refrains from Level 628 transition, the question is, how can a multicast packet reach this L1 629 RBridge? The answer is, it will be reached after the DBRB performs 630 the Level transition and floods the packet using an L1 distribution 631 tree. 633 Take the following figure as an example. RB77 is reachable from the 634 border RBridge RB30 while RB3 is the DBRB. RB3 transitions the 635 multicast packet into L1 and floods the packet on the distribution 636 tree rooted from RB3. This packet is finally flooded to RB77 via 637 RB30. 639 Area{3,30} 640 +--------------+ (root) RB3 o 641 | | \ 642 -RB3 | | o RB30 643 | | | / 644 -RB30-RB77 | RB77 o 645 +--------------+ 647 Example Topology L1 Tree 649 In the above example, the multicast packet is forwarded along a non- 650 optimal path. A possible improvement is to have RB3 configured not to 651 belong to this area. In this way, RB30 will surely act as the DBRB to 652 do the Level transition. 654 Authors' Addresses 656 Mingui Zhang 657 Huawei Technologies 658 No. 156 Beiqing Rd. Haidian District 659 Beijing 100095 660 China 662 Email: zhangmingui@huawei.com 664 Donald E. Eastlake, 3rd 665 Futurewei Technologies 666 2386 Panoramic Circle 667 Apopka, FL 32703 668 United States 670 Phone: +1-508-333-2270 671 Email: d3e3e3@gmail.com 673 Radia Perlman 674 EMC 675 2010 256th Avenue NE, #200 676 Bellevue, WA 98007 677 United States 679 Email: radia@alum.mit.edu 681 Margaret Cullen 682 Painless Security 683 356 Abbott Street 684 North Andover, MA 01845 685 United States 687 Phone: +1-781-405-7464 688 Email: margaret@painless-security.com 689 URI: https://www.painless-security.com 691 Hongjun Zhai 692 Jinling Institute of Technology 693 99 Hongjing Avenue, Jiangning District 694 Nanjing, Jiangsu 211169 695 China 697 Email: honjun.zhai@tom.com 699 Copyright, Disclaimer, and Additional IPR Provisions 701 Copyright (c) 2021 IETF Trust and the persons identified as the 702 document authors. All rights reserved. 704 This document is subject to BCP 78 and the IETF Trust's Legal 705 Provisions Relating to IETF Documents 706 (http://trustee.ietf.org/license-info) in effect on the date of 707 publication of this document. Please review these documents 708 carefully, as they describe your rights and restrictions with respect 709 to this document. Code Components extracted from this document must 710 include Simplified BSD License text as described in Section 4.e of 711 the Trust Legal Provisions and are provided without warranty as 712 described in the Simplified BSD License.