idnits 2.17.1 draft-zhang-trill-multi-topo-rpfc-00.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 == Line 459 has weird spacing: '...ections to RB...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Hashing function is widely used in LAG for the purpose of load balancing. In a corner case, native data packets from one end-station may be mapped to any aggregated member. Similar as the example shown in Figure 3.3, the egress of Mac_H1 at RBi may change between RBv001 and RBv010 back and forth. When MAC address flip-flop happens, the MT unaware RBi is unable to use asymmetric topologies to send return TRILL data frames back to aggregated members. TRILL data frames destined to RBv001 and RBv010 may go through two different forwarding paths. Although this kind of MAC flip-flop is rare in real TRILL campus, it is recommended that the hashing function is configured to completely avoid it. The configuration of LAG should guarantee that native data frames from one end-station are mapped to only one aggregated member (one active link in the LAG). Destination IP/MAC address fields of a native data frame SHOULD not be used as the input of hashing function. -- The document date (January 30, 2012) is 4468 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: 'RBagg' is mentioned on line 263, but not defined == Missing Reference: 'RFC2119' is mentioned on line 150, but not defined == Missing Reference: 'H1' is mentioned on line 191, but not defined == Missing Reference: 'H2' is mentioned on line 191, but not defined == Outdated reference: A later version (-04) exists of draft-zhang-trill-aggregation-01 == Outdated reference: A later version (-04) exists of draft-manral-isis-trill-multi-topo-03 == Outdated reference: A later version (-03) exists of draft-eastlake-trill-rbridge-multi-topo-02 == Outdated reference: A later version (-08) exists of draft-hu-trill-pseudonode-nickname-01 == Outdated reference: A later version (-01) exists of draft-tissa-trill-cmt-00 Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Mingui Zhang 3 Intended Status: Proposed Standard Huawei 4 Expires: August 2, 2012 January 30, 2012 6 Reverse Path Forwarding Check under Multiple Topology TRILL 7 draft-zhang-trill-multi-topo-rpfc-00.txt 9 Abstract 11 Multi-homing (RBridge Aggregation) is a promising approach to 12 increase the reliability and access bandwidth of TRILL edge. Active- 13 active forwarding in multi-homing allows multiple RBridges forward 14 data frames for VLAN-x on a LAN link, which creates the possibility 15 that multicast frames from a specific ingress RBridge may arrive at 16 multiple incoming ports of a remote RBridge. This violates the 17 Reverse Path Forwarding Check and multicast frames arrives at 18 unexpected incoming ports will be discarded by this RBridge. This 19 document makes use of multiple topology TRILL to solve this problem. 20 Multiple topology TRILL provides physical separation of traffic from 21 different members of aggregation. Multicast frames from aggregation 22 members comply with the Reverse Path Forwarding Check per topology. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that other 31 groups may also distribute working documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Content . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. RPFC Issue in Active-Active Multi-homing . . . . . . . . . . . 5 66 3. Multi-Topology for Aggregation . . . . . . . . . . . . . . . . 6 67 3.1. Multicast Ingressing . . . . . . . . . . . . . . . . . . . 7 68 3.2. Multicast Egressing . . . . . . . . . . . . . . . . . . . . 7 69 3.3. Address Flip-Flop Avoidance by Asymmetric Topologies . . . 7 70 3.4. Tunneling Approach . . . . . . . . . . . . . . . . . . . . 8 71 4. Incremental Deployment . . . . . . . . . . . . . . . . . . . . 9 72 4.1. Intra-Topology Communication . . . . . . . . . . . . . . . 9 73 4.2. Inter-Topology Communication . . . . . . . . . . . . . . . 10 74 4.3. A Hybrid Scenario . . . . . . . . . . . . . . . . . . . . . 10 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 11 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 81 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 With the link state routing of IS-IS (Intermediate System to 86 Intermediate System), TRILL provides a solution of least cost 87 forwarding of data frames to replace the Spanning Tree Protocol (STP) 88 running in traditional bridge networks. 90 RBridge Aggregation provides active-active multi-homing at the edge 91 of TRILL [RBAgg]. It increases the access bandwidth and reliability 92 of TRILL edge but creates the possibility that multiple RBridges 93 ingress/egress data frames for end-stations from VLAN-x on a LAN 94 link. A typical use of RBridges Aggregation is to represent a LAN 95 link with a single virtual RBridge. RBridges participating the 96 aggregation ingress/egress data frames on behalf of this virtual 97 RBridge using a pseudonode nickname. 99 Reverse Path Forwarding Check (RPFC) is used by TRILL to suppress 100 forwarding loops of multicast frames. Based on a Distribution Tree 101 (DT), a multicast frame from a specific ingress RBridge arrives at a 102 single expected link of an RBridge. RBridges MUST drop multicast 103 frames that fail the RPFC [RFC6325]. When multiple RBridges ingress 104 multicast frames for end-stations from VLAN-x on a LAN link 105 simultaneously, it can not guarantee that these frames always arrive 106 at the expected link of a remote RBridge. 108 Multiple Topology (MT) TRILL provides a physical separation of 109 traffic [RFC5120] [MTc] [MTd]. An MT aware RBridge can participate 110 data forwarding in multiple topologies at the same time. This feature 111 is utilized in this document to resolve the issue that active-active 112 multi-homing may fail RPFC. Each RBridge of the aggregation uses an 113 individual topology to ingress/egress data frames for the target LAN 114 link. Since distribution trees are calculated per topology by MT 115 aware RBridges [MTd], multicast frames will be forwarded along these 116 distribution tress separately, which helps the arriving multicast 117 frames pass RPFC. To be backward compatible, the solution provided in 118 this draft does not require all RBridges in a campus to upgrade to 119 support multiple topology TRILL. Legacy RBridges that do not support 120 multiple topology TRILL can inter-operate with the MT aware RBridges 121 participating the RBridge Aggregation. 123 This document focus on solving the RPFC issues caused by active- 124 active multi-homing. Other issues of multi-homing, such as failure 125 recovery and load balance, are in the scope of RBridge Aggregation 126 [RBagg]. One advantage of the adoption of multiple topology TRILL is 127 that approaches for failure recovery developed for multiple topology 128 routing ([RFC5714]) can be reused in RBridge Aggregation without the 129 reinvention of the wheel. 131 1.1. Content 133 Section 2 explains why active-active multi-homing may cause trouble 134 in Reverse Path Forwarding Check of TRILL. 136 Section 3 describes the approach of configuration for the edge 137 RBridges to achieve RBridge Aggregation through multi-topology 138 TRILL. 140 Backward compatibility is an essential requirement for the inter- 141 operation between legacy RBridges and RBridges participating in 142 aggregation. Section 4 describes solutions for three incremental 143 deployment scenarios. 145 1.2. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 1.3. Acronyms 153 IS-IS - Intermediate System to Intermediate System 155 TRILL - TRansparent Interconnection of Lots of Links 157 STP - Spanning Tree Protocol 159 MT - Multiple Topology 161 DT - Distribution Tree 163 LAG - Link Aggregation 165 RPFC - Reverse Path Forwarding Check 167 2. RPFC Issue in Active-Active Multi-homing 169 +-----+ 170 RBi | RBi |(Remote RBridge) 171 / \ +-----+ 172 RB1 RB2 | 173 / /\/\/\/\/\/\ 174 RBv / Transit \ 175 < RBridges > 176 Distribution Tree(DT) \ Campus / 177 \/\/\/\/\/\/ 178 | | 179 +-----+ +-----+ 180 | RB1 |--| RB2 |(Aggregation Members) 181 +-----+ +-----+ 182 \ / 183 ******* 184 * RBv * (Virtual RBridge) 185 ******* 186 ||(LAG) 187 +----+ 188 +---| CE |---+ 189 | +----+ | 190 | | 191 |[H1][H2]... | 192 +------------+ 193 VLAN-x 195 Figure 2.1: An Example Topology of RBridge Aggregation 197 RBridge Aggregation is first proposed in [RBagg]. RBridge Aggregation 198 enables active-active multi-homing for LAN links [RBagg]. Several 199 RBridges can ingress/egress data frames for end-stations of one VLAN 200 on a LAN link, which increases the access bandwidth and reliability 201 of TRILL edge. 203 Figure 2.1 shows an example topology of RBridge Aggregation and the 204 distribution tree is shown on the left (Suppose the transit RBridge 205 campus is null.). Based on the distributions tree, multicast frames 206 from RBv to RBi is expected to be received at the port attaching to 207 RB1. 209 Under RBridge Aggregation, RB2 can really ingress native data frames 210 from the LAG links, therefore multicast frames from RBv to RBi may 211 legally be received at the port attaching to RB2. These frames will 212 be discarded according to the rule of Reverse Path Forwarding Check 213 [RFC6325]. Active-active forwarding of multicast frames is the root 214 cause of this issue. The rest of this document will make use of 215 multiple topology TRILL to solve this problem. 217 3. Multi-Topology for Aggregation 219 Documents [MTc] and [MTd] define the protocol extensions, data plane 220 encoding and procedures to make use of the multiple topology routing 221 supported by ISIS. Multiple topology routing provides physical 222 traffic segregation to TRILL, which is utilized to solve the RPFC 223 issue caused by RBridge Aggregation. RPFC will be done based on 224 distribution trees which are calculated per topology abbreviation by 225 MT aware RBridges. 227 Topology IDs are used to identify the aggregation members. If the 228 number of available topologies is greater than the number of 229 aggregation members, several topology IDs can be assigned to one 230 aggregation member which can make use of these topologies to realize 231 load-balancing. If available topologies are less than aggregation 232 members, some of these members get no topology ID. These standby 233 aggregation members can make use of the tunneling approach defined in 234 Section 3.3 to redirect arriving data frames to other members for 235 forwarding. 237 Table 3.1: A Sample Configuration for Aggregation 239 +------------+---------+-------+ 240 |Aggregation | RBv's | LAG | 241 | Members |Nicknames|Members| 242 +------------+---------+-------+ 243 | RB1 |...001...|RB1-RBv| 244 +------------+---------+-------+ 245 | RB2 |...010...|RB2-RBv| 246 +------------+---------+-------+ 247 | RB3 |...011...|RB3-RBv| 248 +------------+---------+-------+ 249 | RB4 |...100...|RB4-RBv| 250 +------------+---------+-------+ 252 Since multiple topology TRILL identifies a topology using the ingress 253 nickname [MTd], the topology assignment among aggregation members is 254 embodied through the nickname configuration of RBv. Figure 3.1 shows 255 a typical configuration of RBridge Aggregation with 4 members. Each 256 aggregation member ingress native frames using one nickname of RBv. 257 These frames will be confined to the topology as these nicknames 258 indicate. For example, when RB1 ingress the native frames from the 259 local link, it will use RBv001 as the ingress nickname and these 260 frames will be forwarded in topology 1. 262 The rest of this section discusses multicast forwarding. For the 263 detail of unicast forwarding, one may refer to [RBagg]. 265 3.1. Multicast Ingressing 267 RBi RBi 268 / \ / \ 269 RB1 RB2 RB1 RB2 270 / \ 271 RBv001 RBv010 273 DT for Topology_1 DT for Topology_2 275 Figure 3.1: Sample Distribution Trees for Topology 1 and 2 277 LAG may use any of its links as the active link to send frames to a 278 member of RBridge Aggregation. The receiver SHOULD encapsulate the 279 native frames on behalf of RBv. Take Figure 3.1 as an example, RB1 280 and RB2 encapsulates native frame using RBv001 and RBv010 as their 281 ingress nicknames respectively. If these frames are multicast frames, 282 they will be forwarded according to the distribution trees calculated 283 per topology. Since RBi calculates two different distributions trees 284 for RBv001 and RBv010, multicast frames arriving at the ports 285 attached to RB1 and RB2 can all pass the RPFC. 287 3.2. Multicast Egressing 289 Since distribution trees are built per topology, a multicast frame 290 will be received by only one aggregation member. This member should 291 egress the multicast frame to the local link on behalf of RBv. But 292 remote RBridges is not aware that RBv actually does not exist. All 293 aggregation members act as penultimate hops to RBv in the campus. 295 3.3. Address Flip-Flop Avoidance by Asymmetric Topologies 297 +-------+------+------+ +-------+------+------+ 298 |VLAN ID|MacDA |Egress| |VLAN ID|MacDA |Egress| 299 +-------+----- +------+ ---> +-------+----- +------+ 300 |VLAN-x |Mac_H1|RBv001| |VLAN-x |Mac_H1|RBv010| 301 +-------+------+------+ +-------+------+------+ 303 Figure 3.2: An Example of MAC Address Flip-Flop 305 In the above ingressing procedure, native data frames from one end 306 station may be ingressed to the campus by different aggregation 307 members. Current RBridges do not have the topology abbreviation as a 308 separate column in their MAC tables. Therefore, when a remote RBridge 309 receives multicast frames with the same source MAC address from 310 different aggregation members, these multicast frames will create 311 only one entry in the MAC table of this remote RBridge. 313 As illustrated in Figure 3.2, when frames originated from H1 is sent 314 to RBi from RB1, RBi will learn that the egress RBridge nickname for 315 Mac_H1 is RBv001. Afterwards, if RB2 sends frames originated from H1 316 to RBi, the egress RBridge nickname will change to RBv010. It seems 317 that the use of multiple topology TRILL brings a MAC address flip- 318 flop issue. If RBv001 and RBv010 are regarded as two different egress 319 RBridges and RBi prepares paths to them separately, it is possible 320 RBi gets different forwarding paths. In other words, RBi will use 321 different forwarding paths in different topologies for the data 322 frames destined to the same end-station, which may cause packet 323 disorder. 325 However, MT aware RBridges support asymmetric use of topologies 326 [MTd]. In the above example, RBi can send data frames to Mac_H1 327 according to topology 1 even if it learns Mac_H1 from the data flow 328 in topology 2. That is to say RBi can send return data frames to 329 RBv001 all the time. In practical use, remote RBridges SHOULD adhere 330 to a specific topology to send return data frames destined to a 331 specific MAC address. 333 3.4. Tunneling Approach 335 If available topologies are less than the aggregation members, there 336 will be standby members who get no topology ID. These members can 337 still ingress native frames from the LAG directly. But they should 338 redirect them to other members through the following tunneling 339 approach. 341 Suppose RB5 is a standby member of the aggregation. So it is not a 342 parent of RBv on the distribution tree of any topology. Assume RB5 343 tunnels native frames from the LAG to RB1 which is the parent of RBv 344 in topology 1. RB5 should ingress the native frame, fill its egress 345 nickname as RB1 and fill its ingress nickname as the nickname of 346 RBv001 which is used by RB1. Then RB5 sends this frame as a unicast 347 frame to RB1. When RB1 receives this unicast frame, it can judge from 348 its ingress nickname that this frame should be actually ingressed by 349 RB1. Therefore, RB1 decapsulates this frame and re-capsulate it as if 350 it is received from the LAG link RBv-RB1. 352 For the sake of load-balancing and resilience, it is recommended that 353 standby RBridges tunnel their multicast frames evenly among those 354 aggregation members who get topology IDs. The optimization of the 355 tunneling configuration is out the scope of this document. Tunneling 356 approach can also be used for any other purpose such as fail-over. 357 However, in this document, tunneling is used only for redirecting 358 ingress multicast frames to pass through the RPFC in TRILL. 360 4. Incremental Deployment 362 When RBridge Aggregation is put to use in a TRILL campus, it is 363 probably that MT unaware RBridges have already been deployed in this 364 campus. It is therefore necessary to enable the inter-operation of 365 these two types of RBridges. On one hand, MT aware aggregation 366 members MUST be backward compatible to those legacy MT unaware 367 RBridges. On the other hand, legacy RBridges need not make any change 368 in order to communicate with aggregation members. 370 With multi-topology TRILL, RBridge Aggregation can be incrementally 371 deploy in an RBridge campus. This rest of this section provides 372 approaches for three incremental deployment scenarios: (1) 373 aggregation members need not to talk with MT unaware RBridges; (2) 374 aggregation members need to communicate with MT unaware RBridges; (3) 375 a combination of the above two scenarios. 377 4.1. Intra-Topology Communication 379 +------------------------+ 380 |Topology_0 RBx | 381 | | 382 +------------------------+ 383 |Topology_1 RBi | 384 | / \ | 385 | RB1 RB2 | 386 | / | 387 | RBv001 | 388 +------------------------+ 389 |Topology_2 RBi | 390 | / \ | 391 | RB1 RB2 | 392 | \ | 393 | RBv010| 394 +------------------------+ 396 Figure 4.1: Aggregation Members Talk with MT aware RBridges Only 398 If MT aware aggregated RBridges do not talk with MT unaware RBridges, 399 aggregation traffic can be confined to non-zero topologies. This kind 400 of traffic segregation is achieved through multi-topology routing. As 401 illustrated in Figure 4.1, when RB1 and RB2 forward multicast frames 402 to RBi according to distribution trees for topology 1 and topology 2 403 respectively, the MT unaware RBx will not receive these frames from 404 RBv. When RB1 and RB2 advertise LSPs in the base topology, they will 405 not include their adjacencies to RBv001 and RBv010, therefore RBx 406 will not be aware of RBv001 and RBv010. In particular, nickname 407 RBv000 SHOULD be reserved and not used in aggregation configuration 408 so that even RBx can reach RBv000, they will not talk with each 409 other. 411 4.2. Inter-Topology Communication 413 +------------------------+ 414 |Topology_0 | 415 | RBi | 416 | / \ | 417 | RB1 RB2 | 418 | / \ | 419 | RBv001 RBv010| 420 +------------------------+ 422 Figure 4.2: MT aware RBridges Need to Talk with MT unaware RBridges 424 If MT aware aggregated RBridges need to talk with MT unaware 425 RBridges, the traffic segregation method in Section 4.1 can not be 426 used again. Since MT unaware RBridges only understand the base 427 topology, all aggregated RBridges advertise their connections to RBv 428 in the base topology. Figure 4.2 illustrate this approach. Assume RBi 429 is the MT unaware RBridge. RB1 and RB2 advertise their adjacencies to 430 RBv, i.e., "RB1-RBv001" and "RB2-RBv010", in their LSPs. When RBi 431 calculate the distribution tree, it should calculate as what is shown 432 in Figure 4.2. RBv001 and RBv010 are regarded as two different 433 RBridges by RBi. 435 Hashing function is widely used in LAG for the purpose of load 436 balancing. In a corner case, native data packets from one end-station 437 may be mapped to any aggregated member. Similar as the example shown 438 in Figure 3.3, the egress of Mac_H1 at RBi may change between RBv001 439 and RBv010 back and forth. When MAC address flip-flop happens, the MT 440 unaware RBi is unable to use asymmetric topologies to send return 441 TRILL data frames back to aggregated members. TRILL data frames 442 destined to RBv001 and RBv010 may go through two different forwarding 443 paths. Although this kind of MAC flip-flop is rare in real TRILL 444 campus, it is recommended that the hashing function is configured to 445 completely avoid it. The configuration of LAG should guarantee that 446 native data frames from one end-station are mapped to only one 447 aggregated member (one active link in the LAG). Destination IP/MAC 448 address fields of a native data frame SHOULD not be used as the input 449 of hashing function. 451 4.3. A Hybrid Scenario 453 It is allowable that some aggregated members report their connections 454 to RBv in the base topology while others do not. For aggregated 455 members which do not report the connections to RBv in the based 456 topology, they need tunnel multicast frames to those members who 457 report their connections to RBv in the based topology in order to 458 communicate with MT unaware RBridges. For example, RB1 and RB2 459 advertise their connections to RBv001 and RBv010 in topology 1 and 460 2, while RB0 advertises the adjacency to RBv000 in topology 0. Assume 461 RBi is an MT unaware RBridge. The distribution tree calculated by RBi 462 will include RBv000 while does not include RBv001 or RBv010. RB0 can 463 talk with RBi directly on behalf of RBv000. When RB1 and RB2 464 communicates with MT aware RBridges, they can confine the traffic in 465 topology 1 and 2. If RB1 and RB2 need to send TRILL data frames to MT 466 unaware RBrdiges, such as RBi, they should redirect these frames to 467 RB0 using the tunneling approach described in Section 3.3. RB0 will 468 send these frames with RBv000 as their ingress nickname. 470 5. Security Considerations 472 This document raises no new security issues for IS-IS. 474 6. IANA Considerations 476 No new registry is requested to be assigned by IANA. 478 7. Acknowledgements 480 Discussions with authors and contributors of [Pseudo] and [CMT] 481 provide a great help to the write up of this draft. This document is 482 by no means to replace such kind of solutions used for RPFC relaxing. 483 These solutions are designed for TRILL base topology and can be used 484 in parallel in the same RBridge campus with the solution presented in 485 this document. 487 8. References 489 8.1. Normative References 491 [RBAgg] M. Zhang, D. Eastlake, et al, "RBridge Aggregation", draft- 492 zhang-trill-aggregation-01.txt, working in progress. 494 [RFC6325] R. Perlman, D. Eastlake, et al, "RBridges: Base Protocol 495 Specification", RFC 6325, July 2011. 497 [MTc] Vishwas Manral, D. Eastlake, et al, "Multiple Topology 498 Routing Extensions for Transparent Interconnection of Lots 499 of Links (TRILL)", draft-manral-isis-trill-multi-topo- 500 03.txt, working in progress. 502 [MTd] D. Eastlake, M. Zhang, et al, "Multiple Topology TRILL", 503 draft-eastlake-trill-rbridge-multi-topo-02.txt, working in 504 progress. 506 8.2. Informative References 508 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 509 Topology (MT) Routing in Intermediate System to 510 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 512 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 513 5714, January 2010. 515 [Pseudo] H. Zhai, F. Hu, et atl, "RBridge: Pseudonode Nickname", 516 draft-hu-trill-pseudonode-nickname-01.txt, working in 517 progress. 519 [CMT] T. Senevirathne, J. Pathangi, et al, "Coordinated Multicast 520 Trees (CMT)for TRILL", draft-tissa-trill-cmt-00.txt, 521 working in progress. 523 Author's Addresses 525 Mingui Zhang 526 Huawei Technologies Co.,Ltd 527 Huawei Building, No.156 Beiqing Rd. 528 Z-park ,Shi-Chuang-Ke-Ji-Shi-Fan-Yuan,Hai-Dian District, 529 Beijing 100095 P.R. China 531 Email: zhangmingui@huawei.com