idnits 2.17.1 draft-ietf-trill-multilevel-single-nickname-15.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 (August 24, 2021) is 976 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 527 -- Looks like a reference, but probably isn't: '257' on line 528 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: February 23, 2022 August 24, 2021 13 Transparent Interconnection of Lots of Links (TRILL) 14 Single Area Border RBridge Nickname for Multilevel 15 draft-ietf-trill-multilevel-single-nickname-15.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. Ingress Nickname Replacement..........................9 58 4.2. 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 Informational [RFC8243] is an educational document to explain 86 multilevel TRILL and list possible concerns. It does not specify a 87 protocol. As described in [RFC8243], there have been two proposed 88 approaches. One approach, which is referred to as the "unique 89 nickname" approach, gives unique nicknames to all the TRILL switches 90 in the multilevel campus, either by having the Level 1/Level 2 border 91 TRILL switches advertise which nicknames are not available for 92 assignment in the area, or by partitioning the 16-bit nickname into 93 an "area" field and a "nickname inside the area" field. [RFC8397] is 94 the standards track document specifying a "unique nickname" flavor of 95 TRILL multilevel. The other approach, which is referred to in 96 [RFC8243] as the "aggregated nickname" approach, involves assigning 97 nicknames to the areas, and allowing nicknames to be reused inside 98 different areas, by having the border TRILL switches rewrite the 99 nickname fields when entering or leaving an area. [RFC8243] makes the 100 case that, while unique nickname multilevel solutions are simpler, 101 aggregated nickname solutions scale better. 103 The approach specified in this standards track document is somewhat 104 similar to the "aggregated nickname" approach in [RFC8243] but with a 105 very important difference. In this document, the nickname of an area 106 border RBridge is used in both Level 1 (L1) and Level 2 (L2). No 107 additional nicknames are assigned to represent L1 areas as such. 108 Instead, multiple border RBridges are allowed and each L1 area is 109 denoted by the set of all nicknames of those border RBridges of the 110 area. For this approach, nicknames in the L2 area MUST be unique but 111 nicknames inside an L1 area can be reused in other L1 areas that also 112 use this approach. The use of the approach specified in this document 113 in one L1 area does not prohibit the use of other approaches in other 114 L1 areas in the same TRILL campus, for example the use of the unique 115 nickname approach specified in [RFC8397]. The TRILL packet format is 116 unchanged by this document, but data plane processing is changed at 117 Border RBridges and efficient high volume data flow at Border 118 RBridges might require forwarding hardware change. 120 2. Acronyms and Terminology 122 Data Label: VLAN or FGL Fine-Grained Label (FGL). 124 DBRB: Designated Border RBridge. 126 IS-IS: Intermediate System to Intermediate System [IS-IS]. 128 Level: Similar to IS-IS, TRILL has Level 1 for intra-area and Level 2 129 for inter-area. Routing information is exchanged between Level 1 130 RBridges within the same Level 1 area, and Level 2 RBridges can only 131 form relationships and exchange information with other Level 2 132 RBridges. 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in BCP 137 14 [RFC2119] [RFC8174] when, and only when, they appear in all 138 capitals, as shown here. 140 Familiarity with [RFC6325] is assumed in this document. 142 3. Nickname Handling on Border RBridges 144 This section provides an illustrative example and description of the 145 border learning border RBridge nicknames. 147 Area {2,20} level 2 Area {3,30} 148 +-------------------+ +-----------------+ +--------------+ 149 | | | | | | 150 | S--RB27---Rx--Rz----RB2---Rb---Rc--Rd---Re--RB3---Rk--RB44---D | 151 | 27 | | 39 | | 44 | 152 | ----RB20--- ----RB30--- | 153 +-------------------+ +-----------------+ +--------------+ 155 Figure 1: An Example Topology for TRILL Multilevel 157 In Figure 1, RB2, RB20, RB3 and RB30 are area border TRILL switches 158 (RBridges). Their nicknames are 2, 20, 3 and 30 respectively and are 159 used as TRILL switch identifiers in their areas [RFC6325]. Area 160 border RBridges use the set of border nicknames to denote the L1 area 161 that they are attached to. For example, RB2 and RB20 use nicknames 162 {2,20} to denote the L1 area on the left. 164 A source S is attached to RB27 and a destination D is attached to 165 RB44. RB27 has a nickname, say 27, and RB44 has a nickname, say 44 166 (and in fact, they could even have the same nickname, since the TRILL 167 switch nickname will not be visible outside these Level 1 areas). 169 3.1. Actions on Unicast Packets 171 Let's say that S transmits a frame to destination D and let's say 172 that D's location has been learned by the relevant TRILL switches 173 already. These relevant switches have learned the following: 175 1) RB27 has learned that D is connected to nickname 3. 176 2) RB3 has learned that D is attached to nickname 44. 178 The following sequence of events will occur: 180 - S transmits an Ethernet frame with source MAC = S and destination 181 MAC = D. 183 - RB27 encapsulates with a TRILL header with ingress RBridge = 27, 184 and egress RBridge = 3 producing a TRILL Data packet. 186 - RB2 and RB20 have announced in the Level 1 IS-IS area designated 187 {2,20}, that they are attached to the nicknames of all the border 188 RBridges in the Level 2 area including RB3 and RB30. Therefore, 189 IS-IS routes the packet to RB2 (or RB20, if RB20 on the least-cost 190 route from RB27 to RB3). 192 - RB2, when transitioning the packet from Level 1 to Level 2, 193 replaces the ingress TRILL switch nickname with its own nickname, 194 replacing 27 with 2. Within Level 2, the ingress RBridge field in 195 the TRILL header will therefore be 2, and the egress RBridge field 196 will be 3. (The egress nickname MAY be replaced with any area 197 nickname selected from {3,30} such as 30. See Section 4 for the 198 detail of the selection method. Here, suppose the egress nickname 199 reamins 3.) Also RB2 learns that S is attached to nickname 27 in 200 area {2,20} to accommodate return traffic. RB2 SHOULD synchronize 201 with RB20 using ESADI protocol [RFC7357] that MAC = S is attached 202 to nickname 27. 204 - The packet is forwarded through Level 2, to RB3, which has 205 advertised, in Level 2, its L2 nickname as 3. 207 - RB3, when forwarding into area {3,30}, replaces the egress 208 nickname in the TRILL header with RB44's nickname (44). (The 209 ingress nickname MAY be replaced with any area nickname selected 210 from {2,20}. See Section 4 for the detail of the selection method. 211 Here, suppose the ingress nickname remains 2.) So, within the 212 destination area, the ingress nickname will be 2 and the egress 213 nickname will be 44. 215 - RB44, when decapsulating, learns that S is attached to nickname 2, 216 which is one of the area nicknames of the ingress. 218 3.2. Actions on Multi-Destination Packets 220 Distribution trees for flooding of multi-destination packets are 221 calculated separately within each L1 area and in L2. When a multi- 222 destination packet arrives at the border, it needs to be transitioned 223 either from L1 to L2, or from L2 to L1. All border RBridges are 224 eligible for Level transition. However, for each multi-destination 225 packet, only one of them acts as the Designated Border RBridge (DBRB) 226 to do the transition while other non-DBRBs MUST drop the received 227 copies. All border RBridges of an area MUST agree on a pseudorandom 228 algorithm as the tie-breaker to locally determine the DBRB. The same 229 pseudorandom algorithm will be reused in Section 4 for the purpose of 230 load balancing. It's also possible to implement a certain election 231 protocol to elect the DBRB. However, such kind of implementations are 232 out the scope of this document. By default, the border RBridge with 233 the smallest nickname, considered as an unsigned integer, is elected 234 DBRB. 236 As per [RFC6325], multi-destination packets can be classified into 237 three types: unicast packet with unknown destination MAC address 238 (unknown-unicast packet), multicast packet and broadcast packet. Now 239 suppose that D's location has not been learned by RB27 or the frame 240 received by RB27 is recognized as broadcast or multicast. What will 241 happen within a Level 1 area (as it would in TRILL today) is that 242 RB27 will forward the packet as multi-destination, setting its M bit 243 to 1 and choosing an L1 tree, flooding the packet on the distribution 244 tree, subject to possible pruning. 246 When the copies of the multi-destination packet arrive at area border 247 RBridges, non-DBRBs MUST drop the packet while the DBRB, say RB2, 248 needs to do the Level transition for the multi-destination packet. 249 For a unknown-unicast packet, if the DBRB has learnt the destination 250 MAC address, it SHOULD convert the packet to unicast and set its M 251 bit to 0. Otherwise, the multi-destination packet will continue to be 252 flooded as multicast packet on the distribution tree. The DBRB 253 chooses the new distribution tree by replacing the egress nickname 254 with the new tree root RBridge nickname from the area the packet is 255 entering. The following sequence of events will occur: 257 - RB2, when transitioning the packet from Level 1 to Level 2, 258 replaces the ingress TRILL switch nickname with its own nickname, 259 replacing 27 with 2. RB2 also MUST replace the egress RBridge 260 nickname with an L2 tree root RBridge nickname (say 39). In order 261 to accommodate return traffic, RB2 records that S is attached to 262 nickname 27 and SHOULD use the ESADI protocol [RFC7357] to 263 synchronize this attachment information with other border RBridges 264 (say RB20) in the area. 266 - RB20, will receive the packet flooded on the L2 tree by RB2. It is 267 important that RB20 does not transition this packet back to L1 as 268 it does for a multicast packet normally received from another 269 remote L1 area. RB20 should examine the ingress nickname of this 270 packet. If this nickname is found to be a border RBridge nickname 271 of the area {2,20}, RB2 must not forwarded the packet into this 272 area. 274 - The packet is flooded on the Level 2 tree to reach 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. In that case, RB3 must turn the packet into a multi- 286 destination packet and floods it on the distribution tree of L1 287 area {3,30}. 289 - RB30, will receive the packet flooded on the L1 tree by RB3. It is 290 important that RB30 does not transition this packet back to L2. 291 RB30 should also examine the ingress nickname of this packet. If 292 this nickname is found to be an L2 border RBridge nickname, RB30 293 must not transition the packet back to L2. 295 - The multicast listener RB44, when decapsulating the received 296 packet, learns that S is attached to nickname 2, which is one of 297 the area nicknames of the ingress. 299 4. Per-flow Load Balancing 301 Area border RBridges perform ingress/egress nickname replacement when 302 they transition TRILL data packets between Level 1 and Level 2. The 303 egress nickname will again be replaced when the packet transitions 304 from Level 2 to Level 1. This nickname replacement enables the per- 305 flow load balance which is specified as follows. 307 4.1. Ingress Nickname Replacement 309 When a TRILL data packet from other areas arrives at an area border 310 RBridge, this RBridge MAY select one area nickname of the ingress 311 area to replace the ingress nickname of the packet so that the 312 returning TRILL data packet can be forwarded to this selected 313 nickname. The selection is simply based on a pseudorandom algorithm 314 as defined in Section 5.3 of [RFC7357]. With the random ingress 315 nickname replacement, the border RBridge actually achieves a per-flow 316 load balance for returning traffic. 318 All area border RBridges in an L1 area MUST agree on the same 319 pseudorandom algorithm. The source MAC address, ingress area 320 nicknames, egress area nicknames and the Data Label of the received 321 TRILL data packet are candidate factors of the input of this 322 pseudorandom algorithm. Note that the value of the destination MAC 323 address SHOULD be excluded from the input of this pseudorandom 324 algorithm, otherwise the egress RBridge will see one source MAC 325 address flip flopping among multiple ingress RBridges. 327 4.2. Egress Nickname Replacement 329 When a TRILL data packet originated from an L1 area arrives at an 330 area border RBridge of that area, that RBridge MAY select one area 331 nickname of the egress area to replace the egress nickname of the 332 packet. By default, it SHOULD choose the egress area border RBridge 333 with the least cost route to reach or, if there are multiple equal 334 cost egress area border RBridges, use the pseudorandom algorithm as 335 defined in Section 5.3 of [RFC7357] to select one. The use of that 336 algorithm MAY be extended to selection among some stable set of 337 egress area border RBridges that include non-least-cost alternatives 338 if it is desired to obtain more load spreading at the cost of 339 sometimes using a non-least-cost Level 2 route to forward the TRILL 340 data packet to the egress area. 342 5. Protocol Extensions for Discovery 344 The following topology change scenarios will trigger the discovery 345 processes as defined in Sections 5.1 and 5.2: 346 - A new node comes up or recovers from a previous failure. 347 - A node goes down. 348 - A link or node fails and causes partition of an L1/L2 area. 349 - A link or node whose failure have caused partitioning of an L1/L2 350 area is repaired. 352 5.1. Discovery of Border RBridges in L1 354 The following Level 1 Border RBridge APPsub-TLV will be included in 355 an E-L1FS FS-LSP fragment zero [RFC7780] as an APPsub-TLV of the 356 TRILL GENINFO-TLV. Through listening for this APPsub-TLV, an area 357 border RBridge discovers all other area border RBridges in this area. 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Type = L1-BORDER-RBRIDGE | (2 bytes) 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Length | (2 bytes) 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Sender Nickname | (2 bytes) 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 o Type: Level 1 Border RBridge (TRILL APPsub-TLV type tbd1) 369 o Length: 2 371 o Sender Nickname: The nickname the originating IS will use as the 372 L1 Border RBridge nickname. This field is useful because the 373 originating IS might own multiple nicknames. 375 5.2. Discovery of Border RBridge Sets in L2 377 The following APPsub-TLV will be included in an E-L2FS FS-LSP 378 fragment zero [RFC7780] as an APPsub-TLV of the TRILL GENINFO-TLV. 379 Through listening to this APPsub-TLV in L2, an area border RBridge 380 discovers all groups of L1 border RBridges and each such group 381 identifies an area. 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Type = L1-BORDER-RB-GROUP | (2 bytes) 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Length | (2 bytes) 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | L1 Border RBridge Nickname 1 | (2 bytes) 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | ... | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | L1 Border RBridge Nickname k | (2 bytes) 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 o Type: Level 1 Border RBridge Group (TRILL APPsub-TLV type tbd2) 397 o Length: 2 * k. If length is not a multiple of 2, the APPsub-TLV is 398 corrupt and MUST be ignored. 400 o L1 Border RBridge Nickname: The nickname that an area border 401 RBridge uses as the L1 Border RBridge nickname. The L1-BORDER-RB- 402 GROUP TLV generated by an area border RBridge MUST include all L1 403 Border RBridge nicknames of the area. It's RECOMMENDED that these 404 k nicknames are ordered in ascending order according to the 405 2-octet nickname considered as an unsigned integer. 407 When an L1 area is partitioned [RFC8243], border RBridges will re- 408 discover each other in both L1 and L2 through exchanging LSPs. In L2, 409 the set of border RBridge nicknames for this splitting area will 410 change. Border RBridges that detect such a change MUST flush the 411 reachability information associated to any RBridge nickname from this 412 changing set. 414 6. One Border RBridge Connects Multiple Areas 416 It's possible that one border RBridge (say RB1) connects multiple L1 417 areas. RB1 SHOULD use a single area nickname for all these areas. 419 Nicknames used within one of these L1 areas can be reused within 420 other areas. It's important that packets destined to those duplicated 421 nicknames are sent to the right area. Since these areas are connected 422 to form a layer 2 network, duplicated {MAC, Data Label} across these 423 areas SHOULD NOT occur (see Section 4.2.6 of [RFC6325] for tie 424 breaking rules). Now suppose a TRILL data packet arrives at the area 425 border nickname of RB1. For a unicast packet, RB1 can look up the 426 {MAC, Data Label} entry in its MAC table to identify the right 427 destination area (i.e., the outgoing interface) and the egress 428 RBridge's nickname. For a multicast packet: either RB1 is not the 429 DBRB and RB1 will not transition the packet or RB1 is the DBRB. If 430 RB1 is the DBRB, RB1 follows the following rules: 432 - if this packet originated from an area out of the connected areas, 433 RB1 replicates this packet and floods it on the proper Level 1 434 trees of all the areas in which it acts as the DBRB. 436 - if the packet originated from one of the connected areas, RB1 437 replicates the packet it receives from the Level 1 tree and floods 438 it on other proper Level 1 trees of all the areas in which it acts 439 as the DBRB except the originating area (i.e., the area connected 440 to the incoming interface). RB1 might also receive the replication 441 of the packet from the Level 2 tree. This replication MUST be 442 dropped by RB1. It recognizes such packets by their ingress 443 nickname being the nickname of one of the border RBridges of an L1 444 area to which the receiving border RBridge is attached. 446 7. E-L1FS/E-L2FS Backwards Compatibility 448 All Level 2 RBridges MUST support E-L2FS [RFC7356] [RFC7780]. The 449 Extended TLVs defined in Section 5 are to be used in Extended Level 450 1/2 Flooding Scope (E-L1FS/E-L2FS) PDUs. Area border RBridges MUST 451 support both E-L1FS and E-L2FS. RBridges that do not support both 452 E-L1FS or E-L2FS cannot serve as area border RBridges but they can 453 appear in an L1 area acting as non-area-border RBridges. 455 8. Manageability Considerations 457 If an L1 Border RBridge Nickname is configured at an RBridge and that 458 RBridge has both L1 and L2 adjacencies, the multilevel feature as 459 specified in this document is turned on for that RBridge. In 460 contrast, unique nickname multilevel as specified in [RFC8397] is 461 enabled by the presence of L1 and L2 adjacencies without an L1 Border 462 RBridge Nickname being configured. RBridges supporting only unique 463 nickname multilevel do not support the configuration of an L2 Border 464 RBridge Nickname. RBridges supporting only the single level TRILL 465 base protocol specified in [RFC6325] do not support L2 adjacencies. 467 If there are multiple border RBridges between an L1 area and L2 and 468 one or more of them only support or are only configured for unique 469 nickname multilevel ([RFC8397]), any of these border RBridges that 470 are configured to used single nickname multilevel as specified in 471 this document MUST support [RFC8397] and fall back to behaving as a 472 unique nickname border RBridge for that L1 area. Because overlapping 473 sets of RBridges may be the border RBridges for different L1 areas, 474 an RBridge supporting single nickname MUST be able to simultaneously 475 support single nickname for some of its L1 areas and unique nickname 476 for others. For example, RB1 and RB2 might be border RBridges for L1 477 area A1 using single nickname while RB2 and RB3 are border RBridges 478 for area A2. If RB3 only supports unique nicknames then RB2 must fall 479 back to unique nickname for area A2 but continue to support single 480 nickname for area A1. Operators SHOULD be notified when this fall 481 back occurs. 483 In both the unique nickname approach specified in [RFC8397] and the 484 single nickname aggregated approach specified in this document, an 485 RBridge that has L1 and L2 adjacencies uses the same nickname in L1 486 and L2. If an RBridge is configured with an L1 Border RBridge 487 Nickname for any a Level 1 area, it uses this nickname across the 488 Level 2 area. This L1 Border RBridge Nickname cannot be used in any 489 other Level 1 area except other Level 1 areas for which the same 490 RBridge is a border RBridge with this L1 Border RBridge Nickname 491 configured. 493 Other than the manageability considerations specified above, the 494 manageability specifications in [RFC6325] still apply. 496 Border RBridges replace ingress and/or egress nickname when a TRILL 497 data packet traverses TRILL L2 area. A TRILL OAM message will be 498 forwarded through the multilevel single nickname TRILL campus using a 499 MAC address belonging to the destination RBridge [RFC7455]. 501 9. Security Considerations 503 For general TRILL Security Considerations, see [RFC6325]. 505 The newly defined TRILL APPsub-TLVs in Section 5 are transported in 506 IS-IS PDUs whose authenticity can be enforced using regular IS-IS 507 security mechanism [IS-IS] [RFC5310]. This document raises no new 508 security issues for IS-IS. 510 Using a variation of aggregated nicknames, and the resulting possible 511 duplication of nicknames between areas, increases the possibility of 512 a TRILL Data packet being delivered to the wrong egress RBridge if 513 areas are unexpectedly merged. However, in many cases the data would 514 be discarded at that egress RBridge because it would not match a 515 known end station data label/MAC address. 517 10. IANA Considerations 519 IANA is requested to allocate two new types under the TRILL GENINFO 520 TLV [RFC7357] from the range allocated by standards action for the 521 TRILL APPsub-TLVs defined in Section 5. The following entries are 522 added to the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application 523 Identifier 1" Registry on the TRILL Parameters IANA web page. 525 Type Name Reference 526 --------- ---- --------- 527 tbd1[256] L1-BORDER-RBRIDGE [This document] 528 tbd2[257] L1-BORDER-RB-GROUP [This document] 530 11. References 532 11.1. Normative References 534 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 535 Requirement Levels", BCP 14, RFC 2119, DOI 536 10.17487/RFC2119, March 1997, . 539 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 540 Ghanwani, "Routing Bridges (RBridges): Base Protocol 541 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 542 . 544 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 545 Scope Link State PDUs (LSPs)", RFC 7356, DOI 546 10.17487/RFC7356, September 2014, . 549 [RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 550 Stokes, "Transparent Interconnection of Lots of Links 551 (TRILL): End Station Address Distribution Information 552 (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, 553 September 2014, . 555 [RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake 556 3rd, D., Aldrin, S., and Y. Li, "Transparent 557 Interconnection of Lots of Links (TRILL): Fault 558 Management", RFC 7455, DOI 10.17487/RFC7455, March 2015, 559 . 561 [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 562 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 563 Lots of Links (TRILL): Clarifications, Corrections, and 564 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 565 . 567 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 568 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 569 2017, . 571 [RFC8397] Zhang, M., Eastlake 3rd, D., Perlman, R., Zhai, H., and D. 572 Liu, "Transparent Interconnection of Lots of Links (TRILL) 573 Multilevel Using Unique Nicknames", RFC 8397, DOI 574 10.17487/RFC8397, May 2018, . 577 11.2. Informative References 579 [IS-IS] International Organization for Standardization, ISO/IEC 580 10589:2002, "Information technology -- Telecommunications 581 and information exchange between systems -- Intermediate 582 System to Intermediate System intra-domain routeing 583 information exchange protocol for use in conjunction with 584 the protocol for providing the connectionless-mode network 585 service", ISO 8473, Second Edition, November 2002. 587 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 588 and M. Fanto, "IS-IS Generic Cryptographic Authentication", 589 RFC 5310, DOI 10.17487/RFC5310, February 2009, 590 . 592 [RFC8243] Perlman, R., Eastlake 3rd, D., Zhang, M., Ghanwani, A., and 593 H. Zhai, "Alternatives for Multilevel Transparent 594 Interconnection of Lots of Links (TRILL)", RFC 8243, DOI 595 10.17487/RFC8243, September 2017, . 598 Appendix A. Level Transition Clarification 600 It's possible that an L1 RBridge is only reachable from a non-DBRB 601 border RBridge. If this non-DBRB RBridge refrains from Level 602 transition, the question is, how can a multicast packet reach this L1 603 RBridge? The answer is, it will be reached after the DBRB performs 604 the Level transition and floods the packet using an L1 distribution 605 tree. 607 Take the following figure as an example. RB77 is reachable from the 608 border RBridge RB30 while RB3 is the DBRB. RB3 transitions the 609 multicast packet into L1 and floods the packet on the distribution 610 tree rooted from RB3. This packet is finally flooded to RB77 via 611 RB30. 613 Area{3,30} 614 +--------------+ (root) RB3 o 615 | | \ 616 -RB3 | | o RB30 617 | | | / 618 -RB30-RB77 | RB77 o 619 +--------------+ 621 Example Topology L1 Tree 623 In the above example, the multicast packet is forwarded along a non- 624 optimal path. A possible improvement is to have RB3 configured not to 625 belong to this area. In this way, RB30 will surely act as the DBRB to 626 do the Level transition. 628 Authors' Addresses 630 Mingui Zhang 631 Huawei Technologies 632 No. 156 Beiqing Rd. Haidian District 633 Beijing 100095 634 China 636 Email: zhangmingui@huawei.com 638 Donald E. Eastlake, 3rd 639 Futurewei Technologies 640 2386 Panoramic Circle 641 Apopka, FL 32703 642 United States 644 Phone: +1-508-333-2270 645 Email: d3e3e3@gmail.com 647 Radia Perlman 648 EMC 649 2010 256th Avenue NE, #200 650 Bellevue, WA 98007 651 United States 653 Email: radia@alum.mit.edu 655 Margaret Cullen 656 Painless Security 657 356 Abbott Street 658 North Andover, MA 01845 659 United States 661 Phone: +1-781-405-7464 662 Email: margaret@painless-security.com 663 URI: http://www.painless-security.com 665 Hongjun Zhai 666 Jinling Institute of Technology 667 99 Hongjing Avenue, Jiangning District 668 Nanjing, Jiangsu 211169 669 China 671 Email: honjun.zhai@tom.com 673 Copyright, Disclaimer, and Additional IPR Provisions 675 Copyright (c) 2021 IETF Trust and the persons identified as the 676 document authors. All rights reserved. 678 This document is subject to BCP 78 and the IETF Trust's Legal 679 Provisions Relating to IETF Documents 680 (http://trustee.ietf.org/license-info) in effect on the date of 681 publication of this document. Please review these documents 682 carefully, as they describe your rights and restrictions with respect 683 to this document. Code Components extracted from this document must 684 include Simplified BSD License text as described in Section 4.e of 685 the Trust Legal Provisions and are provided without warranty as 686 described in the Simplified BSD License.