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