idnits 2.17.1 draft-ietf-trill-multilevel-single-nickname-09.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 (July 3, 2019) is 1758 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 451 -- Looks like a reference, but probably isn't: '257' on line 452 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT M. Zhang 3 Intended Status: Proposed Standard Huawei 4 D. Eastlake 5 Futurewei 6 R. Perlman 7 EMC 8 M. Cullen 9 Painless Security 10 H. Zhai 11 JIT 12 Expires: January 4, 2020 July 3, 2019 14 Transparent Interconnection of Lots of Links (TRILL) 15 Single Area Border RBridge Nickname for Multilevel 16 draft-ietf-trill-multilevel-single-nickname-09.txt 18 Abstract 20 A major issue in multilevel TRILL is how to manage RBridge nicknames. 21 In this document, the area border RBridge uses a single nickname in 22 both Level 1 and Level 2. RBridges in Level 2 must obtain unique 23 nicknames but RBridges in different Level 1 areas may have the same 24 nicknames. 26 Status of This Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that other 33 groups may also distribute working documents as Internet-Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/1id-abstracts.html 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 46 Copyright and License Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . . 3 65 3. Nickname Handling on Border RBridges . . . . . . . . . . . . . 3 66 3.1. Actions on Unicast Packets . . . . . . . . . . . . . . . . 4 67 3.2. Actions on Multi-Destination Packets . . . . . . . . . . . 5 68 4. Per-flow Load Balancing . . . . . . . . . . . . . . . . . . . . 6 69 4.1. Ingress Nickname Replacement . . . . . . . . . . . . . . . 7 70 4.2. Egress Nickname Replacement . . . . . . . . . . . . . . . . 7 71 5. Protocol Extensions for Discovery . . . . . . . . . . . . . . . 7 72 5.1. Discovery of Border RBridges in L1 . . . . . . . . . . . . 7 73 5.2. Discovery of Border RBridge Sets in L2 . . . . . . . . . . 8 74 6. One Border RBridge Connects Multiple Areas . . . . . . . . . . 8 75 7. E-L1FS/E-L2FS Backwards Compatibility . . . . . . . . . . . . . 9 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 80 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 81 Appendix A. Clarifications . . . . . . . . . . . . . . . . . . . . 11 82 A.1. Level Transition . . . . . . . . . . . . . . . . . . . . . 11 83 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 TRILL (Transparent Interconnection of Lots of Links [RFC6325] 88 [RFC7780]) multilevel techniques are designed to improve TRILL 89 scalability issues. As described in [RFC8243], there have been two 90 proposed approaches. One approach, which is referred to as the 91 "unique nickname" approach, gives unique nicknames to all the TRILL 92 switches in the multilevel campus, either by having the Level- 93 1/Level-2 border TRILL switches advertise which nicknames are not 94 available for assignment in the area, or by partitioning the 16-bit 95 nickname into an "area" field and a "nickname inside the area" field. 97 The other approach, which is referred to in [RFC8243] as the 98 "aggregated nickname" approach, involves assigning nicknames to the 99 areas, and allowing nicknames to be reused in different areas, by 100 having the border TRILL switches rewrite the nickname fields when 101 entering or leaving an area. 103 The approach specified in this document is somewhat similar to the 104 "aggregated nickname" approach in [RFC8243] but with very important 105 difference. In this document, the nickname of an area border RBridge 106 is used in both Level 1 (L1) and Level 2 (L2). No additional 107 nicknames are assigned to the L1 areas. Instead, each L1 area is 108 denoted by the set of all nicknames of those border RBridges of the 109 area. For this approach, nicknames in L2 MUST be unique but nicknames 110 inside an L1 areas MAY be reused in other L1 areas that also use this 111 approach. The use of the approach specified in this document in one 112 L1 area does not prohibit the use of other approaches in other L1 113 areas in the same TRILL campus. 115 2. Acronyms and Terminology 117 Data Label: VLAN or FGL Fine-Grained Label (FGL) 119 DBRB: Designated Border RBridge. 121 IS-IS: Intermediate System to Intermediate System [IS-IS] 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 Familiarity with [RFC6325] is assumed in this document. 131 3. Nickname Handling on Border RBridges 133 This section provides an illustrative example and description of the 134 border learning border RBridge nicknames. 136 Area {2,20} level 2 Area {3,30} 137 +-------------------+ +-----------------+ +--------------+ 138 | | | | | | 139 | S--RB27---Rx--Rz----RB2---Rb---Rc--Rd---Re--RB3---Rk--RB44---D | 140 | 27 | | | | 44 | 141 | ----RB20--- ----RB30--- | 142 +-------------------+ +-----------------+ +--------------+ 144 Figure 1: An Example Topology for TRILL Multilevel 146 In Figure 1, RB2, RB20, RB3 and RB30 are area border TRILL switches 147 (RBridges). Their nicknames are 2, 20, 3 and 30 respectively and are 148 used as TRILL switch identifiers in their areas [RFC6325]. Area 149 border RBridges use the set of border nicknames to denote the L1 area 150 that they are attached to. For example, RB2 and RB20 use nicknames 151 {2,20} to denote the L1 area on the left. 153 A source S is attached to RB27 and a destination D is attached to 154 RB44. RB27 has a nickname, say 27, and RB44 has a nickname, say 44 155 (and in fact, they could even have the same nickname, since the TRILL 156 switch nickname will not be visible outside these Level 1 areas). 158 3.1. Actions on Unicast Packets 160 Let's say that S transmits a frame to destination D and let's say 161 that D's location is learned by the relevant TRILL switches already. 162 These relevant switches have learned the following: 164 1) RB27 has learned that D is connected to nickname 3. 165 2) RB3 has learned that D is attached to nickname 44. 167 The following sequence of events will occur: 169 - S transmits an Ethernet frame with source MAC = S and destination 170 MAC = D. 172 - RB27 encapsulates with a TRILL header with ingress RBridge = 27, 173 and egress RBridge = 3 producing a TRILL Data packet. 175 - RB2 and RB20 have announced in the Level 1 IS-IS instance in area 176 {2,20}, that they are attached to all those area nicknames, 177 including {3,30}. Therefore, IS-IS routes the packet to RB2 (or 178 RB20, if RB20 on the least-cost route from RB27 to RB3). 180 - RB2, when transitioning the packet from Level 1 to Level 2, 181 replaces the ingress TRILL switch nickname with its own nickname, 182 so replaces 27 with 2. Within Level 2, the ingress RBridge field 183 in the TRILL header will therefore be 2, and the egress RBridge 184 field will be 3. (The egress nickname MAY be replaced with an area 185 nickname selected from {3,30}. See Section 4 for the detail of the 186 selection method. Here, suppose nickname 3 is used.) Also RB2 187 learns that S is attached to nickname 27 in area {2,20} to 188 accommodate return traffic. RB2 SHOULD synchronize with RB20 using 189 ESADI protocol [RFC7357] that MAC = S is attached to nickname 27. 191 - The packet is forwarded through Level 2, to RB3, which has 192 advertised, in Level 2, its L2 nickname as 3. 194 - RB3, when forwarding into area {3,30}, replaces the egress 195 nickname in the TRILL header with RB44's nickname (44). (The 196 ingress nickname MAY be replaced with an area nickname selected 197 from {2,20}. See Section 4 for the detail of the selection method. 198 Here, suppose nickname 2 is selected.) So, within the destination 199 area, the ingress nickname will be 2 and the egress nickname will 200 be 44. 202 - RB44, when decapsulating, learns that S is attached to nickname 2, 203 which is one of the area nicknames of the ingress. 205 3.2. Actions on Multi-Destination Packets 207 Distribution trees for flooding of multi-destination packets are 208 calculated separately within each L1 area and in L2. When a multi- 209 destination packet arrives at the border, it needs to be transitioned 210 either from L1 to L2, or from L2 to L1. All border RBridges are 211 eligible for Level transition. However, for each multi-destination 212 packet, only one of them acts as the Designated Border RBridge (DBRB) 213 to do the transition while other non-DBRBs MUST drop the received 214 copies. All border RBridges of an area MUST agree on a pseudorandom 215 algorithm and locally determine the DBRB as they do in the "Per-flow 216 Load Balancing" section. It's also possible to implement a certain 217 election protocol to elect the DBRB. However, such kind of 218 implementations are out the scope of this document. By default, the 219 border RBridge with the smallest nickname, considered as an unsigned 220 integer, is elected DBRB. 222 As per [RFC6325], multi-destination packets can be classified into 223 three types: unicast packet with unknown destination MAC address 224 (unknown-unicast packet), multicast packet and broadcast packet. Now 225 suppose that D's location has not been learned by RB27 or the frame 226 received by RB27 is recognized as broadcast or multicast. What will 227 happen, as it would in TRILL today, is that RB27 will forward the 228 packet as multi-destination, setting its M bit to 1 and choosing an 229 L1 tree, flooding the packet on the distribution tree, subject to 230 possible pruning. 232 When the copies of the multi-destination packet arrive at area border 233 RBridges, non-DBRBs MUST drop the packet while the DBRB, say RB2, 234 needs to do the Level transition for the multi-destination packet. 235 For a unknown-unicast packet, if the DBRB has learnt the destination 236 MAC address, it SHOULD convert the packet to unicast and set its M 237 bit to 0. Otherwise, the multi-destination packet will continue to be 238 flooded as multicast packet on the distribution tree. The DBRB 239 chooses the new distribution tree by replacing the egress nickname 240 with the new root RBridge nickname. The following sequence of events 241 will occur: 243 - RB2, when transitioning the packet from Level 1 to Level 2, 244 replaces the ingress TRILL switch nickname with its own nickname, 245 so replaces 27 with 2. RB2 also needs to replace the egress 246 RBridge nickname with an L2 tree root RBridge nickname, say 2. In 247 order to accommodate return traffic, RB2 records that S is 248 attached to nickname 27 and SHOULD use ESADI protocol to 249 synchronize this attachment information with other border RBridges 250 (say RB20) in the area. 252 - RB20, will receive the packet flooded on the L2 tree by RB2. It is 253 important that RB20 does not transition this packet back to L1 as 254 it does for a multicast packet normally received from another 255 remote L1 area. RB20 should examine the ingress nickname of this 256 packet. If this nickname is found to be a border RBridge nickname 257 of the area {2,20}, RB2 must not forwarded the packet into this 258 area. 260 - The packet is flooded on the Level 2 tree to reach both RB3 and 261 RB30. Suppose RB3 is the selected DBRB. The non-DBRB RB30 will 262 drop the packet. 264 - RB3, when forwarding into area {3,30}, replaces the egress 265 nickname in the TRILL header with the root RBridge nickname, say 266 3, of the distribution tree of L1 area {3,30}. (Here, the ingress 267 nickname MAY be replaced with a different area nickname selected 268 from {2,20}, the set of border RBridges to the ingress area, as 269 specified in Section 4.) Now suppose that RB27 has learned the 270 location of D (attached to nickname 3), but RB3 does not know 271 where D is. In that case, RB3 must turn the packet into a multi- 272 destination packet and floods it on the distribution tree of L1 273 area {3,30}. 275 - RB30, will receive the packet flooded on the L1 tree by RB3. It is 276 important that RB30 does not transition this packet back to L2. 277 RB30 should also examine the ingress nickname of this packet. If 278 this nickname is found to be an L2 border RBridge nickname, RB30 279 must not transition the packet back to L2. 281 - The multicast listener RB44, when decapsulating the received 282 packet, learns that S is attached to nickname 2, which is one of 283 the area nicknames of the ingress. 285 4. Per-flow Load Balancing 287 Area border RBridges perform ingress/egress nickname replacement when 288 they transition TRILL data packets between Level 1 and Level 2. This 289 nickname replacement enables the per-flow load balance which is 290 specified as follows. 292 4.1. Ingress Nickname Replacement 294 When a TRILL data packet from other areas arrives at an area border 295 RBridge, this RBridge MAY select one area nickname of the ingress 296 area to replace the ingress nickname of the packet so that the 297 returning TRILL data packet can be forwarded to this selected 298 nickname. The selection is simply based on a pseudorandom algorithm 299 as defined in Section 5.3 of [RFC7357]. With the random ingress 300 nickname replacement, the border RBridge actually achieves a per-flow 301 load balance for returning traffic. 303 All area border RBridges in an L1 area MUST agree on the same 304 pseudorandom algorithm. The source MAC address, ingress area 305 nicknames, egress area nicknames and the Data Label of the received 306 TRILL data packet are candidate factors of the input of this 307 pseudorandom algorithm. Note that the value of the destination MAC 308 address SHOULD be excluded from the input of this pseudorandom 309 algorithm, otherwise the egress RBridge will see one source MAC 310 address flip flopping among multiple ingress RBridges. 312 4.2. Egress Nickname Replacement 314 When a TRILL data packet originated from an L1 area arrives at an 315 area border RBridge, that RBridge MAY select one area nickname of the 316 egress area to replace the egress nickname of the packet. By default, 317 it SHOULD choose the egress area border RBridge with the least cost 318 route to reach. The pseudorandom algorithm as defined in Section 5.3 319 of [RFC7357] may be used as an alternative. In that case, however, 320 the ingress area border RBridge may take the non-least-cost Level 2 321 route to forward the TRILL data packet to the egress area border 322 RBridge. 324 5. Protocol Extensions for Discovery 326 5.1. Discovery of Border RBridges in L1 328 The following Level 1 Border RBridge APPsub-TLV will be included in 329 an E-L1FS FS-LSP fragment zero [RFC7780] as an APPsub-TLV of the 330 TRILL GENINFO-TLV. Through listening for this APPsub-TLV, an area 331 border RBridge discovers all other area border RBridges in this area. 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Type = L1-BORDER-RBRIDGE | (2 bytes) 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Length | (2 bytes) 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Sender Nickname | (2 bytes) 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 o Type: Level 1 Border RBridge (TRILL APPsub-TLV type tbd1) 342 o Length: 2 344 o Sender Nickname: The nickname the originating IS will use as the 345 L1 Border RBridge nickname. This field is useful because the 346 originating IS might own multiple nicknames. 348 5.2. Discovery of Border RBridge Sets in L2 350 The following APPsub-TLV will be included in an E-L2FS FS-LSP 351 fragment zero [RFC7780] as an APPsub-TLV of the TRILL GENINFO-TLV. 352 Through listening to this APPsub-TLV in L2, an area border RBridge 353 discovers all groups of L1 border RBridges and each such group 354 identifies an area. 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Type = L1-BORDER-RB-GROUP | (2 bytes) 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Length | (2 bytes) 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | L1 Border RBridge Nickname 1 | (2 bytes) 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | ... | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | L1 Border RBridge Nickname k | (2 bytes) 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 o Type: Level 1 Border RBridge Group (TRILL APPsub-TLV type tbd2) 370 o Length: 2 * k. If length is not a multiple of 2, the APPsub-TLV is 371 corrupt and MUST be ignored. 373 o L1 Border RBridge Nickname: The nickname that an area border 374 RBridge uses as the L1 Border RBridge nickname. The L1-BORDER-RB- 375 GROUP TLV generated by an area border RBridge MUST include all L1 376 Border RBridge nicknames of the area. It's RECOMMENDED that these 377 k nicknames are ordered in ascending order according to the 2- 378 octet nickname considered as an unsigned integer. 380 When an L1 area is partitioned [RFC8243], border RBridges will re- 381 discover each other in both L1 and L2 through exchanging LSPs. In L2, 382 the set of border RBridge nicknames for this splitting area will 383 change. Border RBridges that detect such a change MUST flush the 384 reach-ability information associated to any RBridge nickname from 385 this changing set. 387 6. One Border RBridge Connects Multiple Areas 388 It's possible that one border RBridge (say RB1) connects multiple L1 389 areas. RB1 SHOULD use a single area nickname for all these areas. 391 Nicknames used within one of these areas can be reused within other 392 areas. It's important that packets destined to those duplicated 393 nicknames are sent to the right area. Since these areas are connected 394 to form a layer 2 network, duplicated {MAC, Data Label} across these 395 areas ought not occur. Now suppose a TRILL data packet arrives at the 396 area border nickname of RB1. For a unicast packet, RB1 can lookup the 397 {MAC, Data Label} entry in its MAC table to identify the right 398 destination area (i.e., the outgoing interface) and the egress 399 RBridge's nickname. For a multicast packet: suppose RB1 is not the 400 DBRB, RB1 will not transition the packet; otherwise, RB1 is the DBRB, 402 - if this packet originated from an area out of the connected areas, 403 RB1 replicates this packet and floods it on the proper Level 1 404 trees of all the areas in which it acts as the DBRB. 406 - if the packet originated from one of the connected areas, RB1 407 replicates the packet it receives from the Level 1 tree and floods 408 it on other proper Level 1 trees of all the areas in which it acts 409 as the DBRB except the originating area (i.e., the area connected 410 to the incoming interface). RB1 might also receive the replication 411 of the packet from the Level 2 tree. This replication MUST be 412 dropped by RB1. It recognizes such packets by their ingress 413 nickname being the nickname of one of the border RBridges of an L1 414 area to which the receiving border RBridge is attached. 416 7. E-L1FS/E-L2FS Backwards Compatibility 418 All Level 2 RBridges MUST support E-L2FS [RFC7356] [RFC7780]. The 419 Extended TLVs defined in Section 5 are to be used in Extended Level 420 1/2 Flooding Scope (E-L1FS/E-L2FS) PDUs. Area border RBridges MUST 421 support both E-L1FS and E-L2FS. RBridges that do not support both 422 E-L1FS or E-L2FS cannot serve as area border RBridges but they can 423 appear in an L1 area acting as non-area-border RBridges. 425 8. Security Considerations 427 For general TRILL Security Considerations, see [RFC6325]. 429 The newly defined TRILL APPsub-TLVs in Section 5 are transported in 430 IS-IS PDUs whose authenticity can be enforced using regular IS-IS 431 security mechanism [IS-IS] [RFC5310]. This document raises no new 432 security issues for IS-IS. 434 Using a variation of aggregated nicknames, and the resulting possible 435 duplication of nicknames between areas, increases the possibility of 436 a TRILL Data packet being delivered to the wrong egress RBridge if 437 areas are unexpectedly merged. However, in many cases the data would 438 be discarded at that egress because it would not match a known end 439 station data label/MAC address. 441 9. IANA Considerations 443 IANA is requested to allocate two new types under the TRILL GENINFO 444 TLV [RFC7357] from the range allocated by standards action for the 445 TRILL APPsub-TLVs defined in Section 5. The following entries are 446 added to the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application 447 Identifier 1" Registry on the TRILL Parameters IANA web page. 449 Type Name Reference 450 --------- ---- --------- 451 tbd1[256] L1-BORDER-RBRIDGE [This document] 452 tbd2[257] L1-BORDER-RB-GROUP [This document] 454 10. References 456 10.1. Normative References 458 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 459 Requirement Levels", BCP 14, RFC 2119, DOI 460 10.17487/RFC2119, March 1997, . 463 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 464 Ghanwani, "Routing Bridges (RBridges): Base Protocol 465 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 466 . 468 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 469 Scope Link State PDUs (LSPs)", RFC 7356, DOI 470 10.17487/RFC7356, September 2014, . 473 [RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 474 Stokes, "Transparent Interconnection of Lots of Links 475 (TRILL): End Station Address Distribution Information 476 (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, 477 September 2014, . 479 [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 480 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 481 Lots of Links (TRILL): Clarifications, Corrections, and 482 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 483 . 485 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 486 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 487 2017, . 489 10.2. Informative References 491 [IS-IS] International Organization for Standardization, ISO/IEC 492 10589:2002, "Information technology -- Telecommunications 493 and information exchange between systems -- Intermediate 494 System to Intermediate System intra-domain routeing 495 information exchange protocol for use in conjunction with 496 the protocol for providing the connectionless-mode network 497 service", ISO 8473, Second Edition, November 2002. 499 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 500 and M. Fanto, "IS-IS Generic Cryptographic Authentication", 501 RFC 5310, DOI 10.17487/RFC5310, February 2009, 502 . 504 [RFC8243] Perlman, R., Eastlake 3rd, D., Zhang, M., Ghanwani, A., 505 and H. Zhai, "Alternatives for Multilevel Transparent 506 Interconnection of Lots of Links (TRILL)", RFC 8243, DOI 507 10.17487/RFC8243, September 2017, . 510 Appendix A. Clarifications 512 A.1. Level Transition 514 It's possible that an L1 RBridge is only reachable from a non-DBRB 515 RBridge. If this non-DBRB RBridge refrains from Level transition, the 516 question is, how can a multicast packet reach this L1 RBridge? The 517 answer is, it will be reached after the DBRB performs the Level 518 transition and floods the packet using an L1 distribution tree. 520 Take the following figure as an example. RB77 is reachable from the 521 border RBridge RB30 while RB3 is the DBRB. RB3 transitions the 522 multicast packet into L1 and floods the packet on the distribution 523 tree rooted from RB3. This packet will finally flooded to RB77 via 524 RB30. 526 Area{3,30} 527 +--------------+ (root) RB3 o 528 | | \ 529 -RB3 | | o RB30 530 | | | / 531 -RB30-RB77 | RB77 o 532 +--------------+ 533 Example Topology L1 Tree 535 In the above example, the multicast packet is forwarded along a non- 536 optimal path. A possible improvement is to have RB3 configured not to 537 belong to this area. In this way, RB30 will surely act as the DBRB to 538 do the Level transition. 540 Author's Addresses 542 Mingui Zhang 543 Huawei Technologies 544 No. 156 Beiqing Rd. Haidian District 545 Beijing 100095 546 China 548 Email: zhangmingui@huawei.com 550 Donald E. Eastlake, 3rd 551 Futurewei Technologies 552 1424 Pro Shop Court 553 Davenport, FL 33896 554 United States 556 Phone: +1-508-333-2270 557 Email: d3e3e3@gmail.com 559 Radia Perlman 560 EMC 561 2010 256th Avenue NE, #200 562 Bellevue, WA 98007 563 United States 565 Email: radia@alum.mit.edu 567 Margaret Cullen 568 Painless Security 569 356 Abbott Street 570 North Andover, MA 01845 571 United States 573 Phone: +1-781-405-7464 574 Email: margaret@painless-security.com 575 URI: http://www.painless-security.com 577 Hongjun Zhai 578 Jinling Institute of Technology 579 99 Hongjing Avenue, Jiangning District 580 Nanjing, Jiangsu 211169 581 China 583 Email: honjun.zhai@tom.com