idnits 2.17.1 draft-ietf-trill-multilevel-single-nickname-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 (June 8, 2020) is 1418 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 476 -- Looks like a reference, but probably isn't: '257' on line 477 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: December 7, 2020 June 8, 2020 13 Transparent Interconnection of Lots of Links (TRILL) 14 Single Area Border RBridge Nickname for Multilevel 15 draft-ietf-trill-multilevel-single-nickname-10.txt 17 Abstract 18 A major issue in multilevel TRILL is how to manage RBridge nicknames. 19 In this document, the area border RBridge uses a single nickname in 20 both Level 1 and Level 2. RBridges in Level 2 must obtain unique 21 nicknames but RBridges in different Level 1 areas may have the same 22 nicknames. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Distribution of this document is unlimited. Comments should be sent 30 to the authors or the IDR Working Group mailing list . 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 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 44 Shadow Directories can be accessed at 45 http://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................................14 69 10. IANA Considerations...................................14 71 11. References............................................15 72 11.1. Normative References................................15 73 11.2. Informative References..............................15 75 Appendix A. Level Transition Clarification................17 77 Authors' Addresses........................................18 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 to 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 in 98 different areas, by having the border TRILL switches rewrite the 99 nickname fields when entering or leaving an area. RFC 8243 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 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 the L1 areas. Instead, multiple 108 border RBridges are allowed and each L1 area is denoted by the set of 109 all nicknames of those border RBridges of the area. For this 110 approach, nicknames in the L2 area MUST be unique but nicknames 111 inside an L1 area MAY be reused in other L1 areas that also use this 112 approach. The use of the approach specified in this document in one 113 L1 area does not prohibit the use of other approaches in other L1 114 areas in the same TRILL campus. 116 2. Acronyms and Terminology 118 Data Label: VLAN or FGL Fine-Grained Label (FGL). 120 DBRB: Designated Border RBridge. 122 IS-IS: Intermediate System to Intermediate System [IS-IS]. 124 Level: Similar to IS-IS, TRILL has Level 1 for intra-area and Level 2 125 for inter-area. Routing information is exchanged between Level 1 126 RBridges within the same Level 1 area, and Level 2 RBridges can only 127 form relationships and exchange information with other Level 2 128 RBridges. 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in BCP 133 14 [RFC2119] [RFC8174] when, and only when, they appear in all 134 capitals, as shown here. 136 Familiarity with [RFC6325] is assumed in this document. 138 3. Nickname Handling on Border RBridges 140 This section provides an illustrative example and description of the 141 border learning border RBridge nicknames. 143 Area {2,20} level 2 Area {3,30} 144 +-------------------+ +-----------------+ +--------------+ 145 | | | | | | 146 | S--RB27---Rx--Rz----RB2---Rb---Rc--Rd---Re--RB3---Rk--RB44---D | 147 | 27 | | | | 44 | 148 | ----RB20--- ----RB30--- | 149 +-------------------+ +-----------------+ +--------------+ 151 Figure 1: An Example Topology for TRILL Multilevel 153 In Figure 1, RB2, RB20, RB3 and RB30 are area border TRILL switches 154 (RBridges). Their nicknames are 2, 20, 3 and 30 respectively and are 155 used as TRILL switch identifiers in their areas [RFC6325]. Area 156 border RBridges use the set of border nicknames to denote the L1 area 157 that they are attached to. For example, RB2 and RB20 use nicknames 158 {2,20} to denote the L1 area on the left. 160 A source S is attached to RB27 and a destination D is attached to 161 RB44. RB27 has a nickname, say 27, and RB44 has a nickname, say 44 162 (and in fact, they could even have the same nickname, since the TRILL 163 switch nickname will not be visible outside these Level 1 areas). 165 3.1. Actions on Unicast Packets 167 Let's say that S transmits a frame to destination D and let's say 168 that D's location has been learned by the relevant TRILL switches 169 already. These relevant switches have learned the following: 171 1) RB27 has learned that D is connected to nickname 3. 172 2) RB3 has learned that D is attached to nickname 44. 174 The following sequence of events will occur: 176 - S transmits an Ethernet frame with source MAC = S and destination 177 MAC = D. 179 - RB27 encapsulates with a TRILL header with ingress RBridge = 27, 180 and egress RBridge = 3 producing a TRILL Data packet. 182 - RB2 and RB20 have announced in the Level 1 IS-IS instance in area 183 {2,20}, that they are attached to all those area nicknames, 184 including {3,30}. Therefore, IS-IS routes the packet to RB2 (or 185 RB20, if RB20 on the least-cost route from RB27 to RB3). 187 - RB2, when transitioning the packet from Level 1 to Level 2, 188 replaces the ingress TRILL switch nickname with its own nickname, 189 so replaces 27 with 2. Within Level 2, the ingress RBridge field 190 in the TRILL header will therefore be 2, and the egress RBridge 191 field will be 3. (The egress nickname MAY be replaced with an area 192 nickname selected from {3,30}. See Section 4 for the detail of the 193 selection method. Here, suppose nickname 3 is used.) Also RB2 194 learns that S is attached to nickname 27 in area {2,20} to 195 accommodate return traffic. RB2 SHOULD synchronize with RB20 using 196 ESADI protocol [RFC7357] that MAC = S is attached to nickname 27. 198 - The packet is forwarded through Level 2, to RB3, which has 199 advertised, in Level 2, its L2 nickname as 3. 201 - RB3, when forwarding into area {3,30}, replaces the egress 202 nickname in the TRILL header with RB44's nickname (44). (The 203 ingress nickname MAY be replaced with an area nickname selected 204 from {2,20}. See Section 4 for the detail of the selection method. 205 Here, suppose nickname 2 is selected.) So, within the destination 206 area, the ingress nickname will be 2 and the egress nickname will 207 be 44. 209 - RB44, when decapsulating, learns that S is attached to nickname 2, 210 which is one of the area nicknames of the ingress. 212 3.2. Actions on Multi-Destination Packets 214 Distribution trees for flooding of multi-destination packets are 215 calculated separately within each L1 area and in L2. When a multi- 216 destination packet arrives at the border, it needs to be transitioned 217 either from L1 to L2, or from L2 to L1. All border RBridges are 218 eligible for Level transition. However, for each multi-destination 219 packet, only one of them acts as the Designated Border RBridge (DBRB) 220 to do the transition while other non-DBRBs MUST drop the received 221 copies. All border RBridges of an area MUST agree on a pseudorandom 222 algorithm as the tie-breaker to locally determine the DBRB. The same 223 pseudorandom algorithm will be reused in Section 4 for the purpose of 224 load balancing. It's also possible to implement a certain election 225 protocol to elect the DBRB. However, such kind of implementations are 226 out the scope of this document. By default, the border RBridge with 227 the smallest nickname, considered as an unsigned integer, is elected 228 DBRB. 230 As per [RFC6325], multi-destination packets can be classified into 231 three types: unicast packet with unknown destination MAC address 232 (unknown-unicast packet), multicast packet and broadcast packet. Now 233 suppose that D's location has not been learned by RB27 or the frame 234 received by RB27 is recognized as broadcast or multicast. What will 235 happen within a Level 1 area, as it would in TRILL today, is that 236 RB27 will forward the packet as multi-destination, setting its M bit 237 to 1 and choosing an L1 tree, flooding the packet on the distribution 238 tree, subject to possible pruning. 240 When the copies of the multi-destination packet arrive at area border 241 RBridges, non-DBRBs MUST drop the packet while the DBRB, say RB2, 242 needs to do the Level transition for the multi-destination packet. 243 For a unknown-unicast packet, if the DBRB has learnt the destination 244 MAC address, it SHOULD convert the packet to unicast and set its M 245 bit to 0. Otherwise, the multi-destination packet will continue to be 246 flooded as multicast packet on the distribution tree. The DBRB 247 chooses the new distribution tree by replacing the egress nickname 248 with the new tree root RBridge nickname. The following sequence of 249 events will occur: 251 - RB2, when transitioning the packet from Level 1 to Level 2, 252 replaces the ingress TRILL switch nickname with its own nickname, 253 so replaces 27 with 2. RB2 also needs to replace the egress 254 RBridge nickname with an L2 tree root RBridge nickname, say 2. In 255 order to accommodate return traffic, RB2 records that S is 256 attached to nickname 27 and SHOULD use ESADI protocol [RFC7357] to 257 synchronize this attachment information with other border RBridges 258 (say RB20) in the area. 260 - RB20, will receive the packet flooded on the L2 tree by RB2. It is 261 important that RB20 does not transition this packet back to L1 as 262 it does for a multicast packet normally received from another 263 remote L1 area. RB20 should examine the ingress nickname of this 264 packet. If this nickname is found to be a border RBridge nickname 265 of the area {2,20}, RB2 must not forwarded the packet into this 266 area. 268 - The packet is flooded on the Level 2 tree to reach both RB3 and 269 RB30. Suppose RB3 is the selected DBRB. The non-DBRB RB30 will 270 drop the packet. 272 - RB3, when forwarding into area {3,30}, replaces the egress 273 nickname in the TRILL header with a root RBridge nickname, say 3, 274 of the distribution tree of L1 area {3,30}. (Here, the ingress 275 nickname MAY be replaced with a different area nickname selected 276 from {2,20}, the set of border RBridges to the ingress area, as 277 specified in Section 4.) Now suppose that RB27 has learned the 278 location of D (attached to nickname 3), but RB3 does not know 279 where D is. In that case, RB3 must turn the packet into a multi- 280 destination packet and floods it on the distribution tree of L1 281 area {3,30}. 283 - RB30, will receive the packet flooded on the L1 tree by RB3. It is 284 important that RB30 does not transition this packet back to L2. 286 RB30 should also examine the ingress nickname of this packet. If 287 this nickname is found to be an L2 border RBridge nickname, RB30 288 must not transition the packet back to L2. 290 - The multicast listener RB44, when decapsulating the received 291 packet, learns that S is attached to nickname 2, which is one of 292 the area nicknames of the ingress. 294 4. Per-flow Load Balancing 296 Area border RBridges perform ingress/egress nickname replacement when 297 they transition TRILL data packets between Level 1 and Level 2. The 298 egress nickname will again be replaced when the packet transitions 299 from Level 2 to Level 1. This nickname replacement enables the per- 300 flow load balance which is specified as follows. 302 4.1. Ingress Nickname Replacement 304 When a TRILL data packet from other areas arrives at an area border 305 RBridge, this RBridge MAY select one area nickname of the ingress 306 area to replace the ingress nickname of the packet so that the 307 returning TRILL data packet can be forwarded to this selected 308 nickname. The selection is simply based on a pseudorandom algorithm 309 as defined in Section 5.3 of [RFC7357]. With the random ingress 310 nickname replacement, the border RBridge actually achieves a per-flow 311 load balance for returning traffic. 313 All area border RBridges in an L1 area MUST agree on the same 314 pseudorandom algorithm. The source MAC address, ingress area 315 nicknames, egress area nicknames and the Data Label of the received 316 TRILL data packet are candidate factors of the input of this 317 pseudorandom algorithm. Note that the value of the destination MAC 318 address SHOULD be excluded from the input of this pseudorandom 319 algorithm, otherwise the egress RBridge will see one source MAC 320 address flip flopping among multiple ingress RBridges. 322 4.2. Egress Nickname Replacement 324 When a TRILL data packet originated from an L1 area arrives at an 325 area border RBridge of that area, that RBridge MAY select one area 326 nickname of the egress area to replace the egress nickname of the 327 packet. By default, it SHOULD choose the egress area border RBridge 328 with the least cost route to reach. The pseudorandom algorithm as 329 defined in Section 5.3 of [RFC7357] may be used as an alternative. In 330 that case, however, the ingress area border RBridge may take the non- 331 least-cost Level 2 route to forward the TRILL data packet to the 332 egress area border RBridge. 334 5. Protocol Extensions for Discovery 336 5.1. Discovery of Border RBridges in L1 338 The following Level 1 Border RBridge APPsub-TLV will be included in 339 an E-L1FS FS-LSP fragment zero [RFC7780] as an APPsub-TLV of the 340 TRILL GENINFO-TLV. Through listening for this APPsub-TLV, an area 341 border RBridge discovers all other area border RBridges in this area. 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Type = L1-BORDER-RBRIDGE | (2 bytes) 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Length | (2 bytes) 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Sender Nickname | (2 bytes) 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 o Type: Level 1 Border RBridge (TRILL APPsub-TLV type tbd1) 353 o Length: 2 355 o Sender Nickname: The nickname the originating IS will use as the 356 L1 Border RBridge nickname. This field is useful because the 357 originating IS might own multiple nicknames. 359 5.2. Discovery of Border RBridge Sets in L2 361 The following APPsub-TLV will be included in an E-L2FS FS-LSP 362 fragment zero [RFC7780] as an APPsub-TLV of the TRILL GENINFO-TLV. 363 Through listening to this APPsub-TLV in L2, an area border RBridge 364 discovers all groups of L1 border RBridges and each such group 365 identifies an area. 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Type = L1-BORDER-RB-GROUP | (2 bytes) 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Length | (2 bytes) 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | L1 Border RBridge Nickname 1 | (2 bytes) 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | ... | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | L1 Border RBridge Nickname k | (2 bytes) 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 o Type: Level 1 Border RBridge Group (TRILL APPsub-TLV type tbd2) 380 o Length: 2 * k. If length is not a multiple of 2, the APPsub-TLV is 381 corrupt and MUST be ignored. 383 o L1 Border RBridge Nickname: The nickname that an area border 384 RBridge uses as the L1 Border RBridge nickname. The L1-BORDER-RB- 385 GROUP TLV generated by an area border RBridge MUST include all L1 386 Border RBridge nicknames of the area. It's RECOMMENDED that these 387 k nicknames are ordered in ascending order according to the 388 2-octet nickname considered as an unsigned integer. 390 When an L1 area is partitioned [RFC8243], border RBridges will re- 391 discover each other in both L1 and L2 through exchanging LSPs. In L2, 392 the set of border RBridge nicknames for this splitting area will 393 change. Border RBridges that detect such a change MUST flush the 394 reach-ability information associated to any RBridge nickname from 395 this changing set. 397 6. One Border RBridge Connects Multiple Areas 399 It's possible that one border RBridge (say RB1) connects multiple L1 400 areas. RB1 SHOULD use a single area nickname for all these areas. 402 Nicknames used within one of these areas can be reused within other 403 areas. It's important that packets destined to those duplicated 404 nicknames are sent to the right area. Since these areas are connected 405 to form a layer 2 network, duplicated {MAC, Data Label} across these 406 areas ought not occur. Now suppose a TRILL data packet arrives at the 407 area border nickname of RB1. For a unicast packet, RB1 can lookup the 408 {MAC, Data Label} entry in its MAC table to identify the right 409 destination area (i.e., the outgoing interface) and the egress 410 RBridge's nickname. For a multicast packet: suppose RB1 is not the 411 DBRB, RB1 will not transition the packet; otherwise, RB1 is the DBRB, 413 - if this packet originated from an area out of the connected areas, 414 RB1 replicates this packet and floods it on the proper Level 1 415 trees of all the areas in which it acts as the DBRB. 417 - if the packet originated from one of the connected areas, RB1 418 replicates the packet it receives from the Level 1 tree and floods 419 it on other proper Level 1 trees of all the areas in which it acts 420 as the DBRB except the originating area (i.e., the area connected 421 to the incoming interface). RB1 might also receive the replication 422 of the packet from the Level 2 tree. This replication MUST be 423 dropped by RB1. It recognizes such packets by their ingress 424 nickname being the nickname of one of the border RBridges of an L1 425 area to which the receiving border RBridge is attached. 427 7. E-L1FS/E-L2FS Backwards Compatibility 429 All Level 2 RBridges MUST support E-L2FS [RFC7356] [RFC7780]. The 430 Extended TLVs defined in Section 5 are to be used in Extended Level 431 1/2 Flooding Scope (E-L1FS/E-L2FS) PDUs. Area border RBridges MUST 432 support both E-L1FS and E-L2FS. RBridges that do not support both 433 E-L1FS or E-L2FS cannot serve as area border RBridges but they can 434 appear in an L1 area acting as non-area-border RBridges. 436 8. Manageability Considerations 438 If an L1 Border RBridge Nickname is configured, the multilevel 439 feature as specified in this document is turned on. 441 If an RBridge is configured with an L1 Border RBridge Nickname for 442 any a Level 1 area, this nickname will be used across the Level 2 443 area. This L1 Border RBridge Nickname cannot be reused by any other 444 Level 1 area except the Level 1 area for which this L1 Border RBridge 445 Nickname is configured. 447 Other than the manageability considerations as specified above, 448 manageability specifications specified per RFC 6325 still apply. 450 9. Security Considerations 452 For general TRILL Security Considerations, see [RFC6325]. 454 The newly defined TRILL APPsub-TLVs in Section 5 are transported in 455 IS-IS PDUs whose authenticity can be enforced using regular IS-IS 456 security mechanism [IS-IS] [RFC5310]. This document raises no new 457 security issues for IS-IS. 459 Using a variation of aggregated nicknames, and the resulting possible 460 duplication of nicknames between areas, increases the possibility of 461 a TRILL Data packet being delivered to the wrong egress RBridge if 462 areas are unexpectedly merged. However, in many cases the data would 463 be discarded at that egress because it would not match a known end 464 station data label/MAC address. 466 10. IANA Considerations 468 IANA is requested to allocate two new types under the TRILL GENINFO 469 TLV [RFC7357] from the range allocated by standards action for the 470 TRILL APPsub-TLVs defined in Section 5. The following entries are 471 added to the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application 472 Identifier 1" Registry on the TRILL Parameters IANA web page. 474 Type Name Reference 475 --------- ---- --------- 476 tbd1[256] L1-BORDER-RBRIDGE [This document] 477 tbd2[257] L1-BORDER-RB-GROUP [This document] 479 11. References 481 11.1. Normative References 483 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 484 Requirement Levels", BCP 14, RFC 2119, DOI 485 10.17487/RFC2119, March 1997, . 488 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 489 Ghanwani, "Routing Bridges (RBridges): Base Protocol 490 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 491 . 493 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 494 Scope Link State PDUs (LSPs)", RFC 7356, DOI 495 10.17487/RFC7356, September 2014, . 498 [RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 499 Stokes, "Transparent Interconnection of Lots of Links 500 (TRILL): End Station Address Distribution Information 501 (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, 502 September 2014, . 504 [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 505 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 506 Lots of Links (TRILL): Clarifications, Corrections, and 507 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 508 . 510 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 511 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 512 2017, . 514 11.2. Informative References 516 [IS-IS] International Organization for Standardization, ISO/IEC 517 10589:2002, "Information technology -- Telecommunications 518 and information exchange between systems -- Intermediate 519 System to Intermediate System intra-domain routeing 520 information exchange protocol for use in conjunction with 521 the protocol for providing the connectionless-mode network 522 service", ISO 8473, Second Edition, November 2002. 524 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 525 and M. Fanto, "IS-IS Generic Cryptographic Authentication", 526 RFC 5310, DOI 10.17487/RFC5310, February 2009, 527 . 529 [RFC8243] Perlman, R., Eastlake 3rd, D., Zhang, M., Ghanwani, A., and 530 H. Zhai, "Alternatives for Multilevel Transparent 531 Interconnection of Lots of Links (TRILL)", RFC 8243, DOI 532 10.17487/RFC8243, September 2017, . 535 [RFC8397] Zhang, M., Eastlake 3rd, D., Perlman, R., Zhai, H., and D. 536 Liu, "Transparent Interconnection of Lots of Links (TRILL) 537 Multilevel Using Unique Nicknames", RFC 8397, DOI 538 10.17487/RFC8397, May 2018, . 541 Appendix A. Level Transition Clarification 543 It's possible that an L1 RBridge is only reachable from a non-DBRB 544 RBridge. If this non-DBRB RBridge refrains from Level transition, the 545 question is, how can a multicast packet reach this L1 RBridge? The 546 answer is, it will be reached after the DBRB performs the Level 547 transition and floods the packet using an L1 distribution tree. 549 Take the following figure as an example. RB77 is reachable from the 550 border RBridge RB30 while RB3 is the DBRB. RB3 transitions the 551 multicast packet into L1 and floods the packet on the distribution 552 tree rooted from RB3. This packet is finally flooded to RB77 via 553 RB30. 555 Area{3,30} 556 +--------------+ (root) RB3 o 557 | | \ 558 -RB3 | | o RB30 559 | | | / 560 -RB30-RB77 | RB77 o 561 +--------------+ 563 Example Topology L1 Tree 565 In the above example, the multicast packet is forwarded along a non- 566 optimal path. A possible improvement is to have RB3 configured not to 567 belong to this area. In this way, RB30 will surely act as the DBRB to 568 do the Level transition. 570 Authors' Addresses 572 Mingui Zhang 573 Huawei Technologies 574 No. 156 Beiqing Rd. Haidian District 575 Beijing 100095 576 China 578 Email: zhangmingui@huawei.com 580 Donald E. Eastlake, 3rd 581 Futurewei Technologies 582 2386 Panoramic Circle 583 Apopka, FL 32703 584 United States 586 Phone: +1-508-333-2270 587 Email: d3e3e3@gmail.com 589 Radia Perlman 590 EMC 591 2010 256th Avenue NE, #200 592 Bellevue, WA 98007 593 United States 595 Email: radia@alum.mit.edu 597 Margaret Cullen 598 Painless Security 599 356 Abbott Street 600 North Andover, MA 01845 601 United States 603 Phone: +1-781-405-7464 604 Email: margaret@painless-security.com 605 URI: http://www.painless-security.com 607 Hongjun Zhai 608 Jinling Institute of Technology 609 99 Hongjing Avenue, Jiangning District 610 Nanjing, Jiangsu 211169 611 China 613 Email: honjun.zhai@tom.com 615 Copyright, Disclaimer, and Additional IPR Provisions 617 Copyright (c) 2020 IETF Trust and the persons identified as the 618 document authors. All rights reserved. 620 This document is subject to BCP 78 and the IETF Trust's Legal 621 Provisions Relating to IETF Documents 622 (http://trustee.ietf.org/license-info) in effect on the date of 623 publication of this document. Please review these documents 624 carefully, as they describe your rights and restrictions with respect 625 to this document. Code Components extracted from this document must 626 include Simplified BSD License text as described in Section 4.e of 627 the Trust Legal Provisions and are provided without warranty as 628 described in the Simplified BSD License.