idnits 2.17.1 draft-ietf-trill-cmt-01.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6325, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6325, updated by this document, for RFC5378 checks: 2006-05-11) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 8, 2012) is 4180 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) == Unused Reference: 'RFC6165' is defined on line 561, but no explicit reference was found in the text == Unused Reference: 'RFC4971' is defined on line 564, but no explicit reference was found in the text == Unused Reference: '8021Q' is defined on line 574, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6327 (Obsoleted by RFC 7177) ** Obsolete normative reference: RFC 6439 (Obsoleted by RFC 8139) -- Obsolete informational reference (is this intentional?): RFC 4971 (Obsoleted by RFC 7981) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Tissa Senevirathne 2 Internet Draft CISCO 3 Intended status: Standard Track Janardhanan Pathangi 4 Updates: 6325 DELL 5 Jon Hudson 6 Brocade 8 November 8, 2012 9 Expires: May 2013 11 Coordinated Multicast Trees (CMT) for TRILL 12 draft-ietf-trill-cmt-01.txt 14 Status of this Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on May 8, 2009. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with 47 respect to this document. Code Components extracted from this 48 document must include Simplified BSD License text as described in 49 Section 4.e of the Trust Legal Provisions and are provided without 50 warranty as described in the Simplified BSD License. 52 Abstract 54 TRILL facilitates loop free connectivity to non-TRILL legacy 55 networks via choice of an Appointed Forwarder for a set of VLANs. 56 Appointed Forwarder provides VLAN level load sharing with active- 57 standby model. Mission critical operations such as High Performance 58 Data Centers require active-active load sharing model. Active-Active 59 load sharing model can be accomplished by representing any given 60 non-TRILL legacy network with a single virtual RBridge. Virtual 61 representation of the non-TRILL legacy network with a single RBridge 62 poses serious challenges in multi-destination RPF calculations. This 63 document presents the required enhancements to build Coordinated 64 Multicast Trees (CMT) within the TRILL campus to solve related RPF 65 issues. CMT provides flexibility to RBridges to select desired path 66 of association to a given distribution tree. 68 Table of Contents 70 1. Introduction...................................................3 71 1.1. Scope and Applicability...................................4 72 1.2. Contributors..............................................5 73 2. Conventions used in this document..............................5 74 2.1. Acronyms..................................................5 75 3. The AFFINITY sub-TLV...........................................5 76 4. Multicast Tree Construction and Use of Affinity Sub-TLV........6 77 4.1. Update to RFC 6325........................................7 78 4.2. Announcing virtual RBridge nickname.......................8 79 4.3. Affinity Sub-TLV Capability...............................8 80 5. Theory of operation............................................8 81 5.1. Distribution Tree provisioning............................8 82 5.2. Affinity Sub-TLV advertisement............................9 83 5.3. Affinity sub-TLV conflict resolution......................9 84 5.4. Ingress Multi-Destination Forwarding.....................10 85 5.4.1. Forwarding when n < k...............................10 86 5.5. Egress Multi-Destination Forwarding......................11 87 5.5.1. Traffic Arriving on an assigned Tree to RBk-RBv.....11 88 5.5.2. Traffic Arriving on other Trees.....................11 89 5.6. Failure scenarios........................................11 90 5.6.1. Edge RBridge RBk failure............................11 91 5.7. Backward compatibility...................................12 93 6. Security Considerations.......................................12 94 7. IANA Considerations...........................................12 95 8. References....................................................12 96 8.1. Normative References.....................................12 97 8.2. Informative References...................................13 98 9. Acknowledgments...............................................13 99 10. Authors' Addresses...........................................14 101 1. Introduction 103 TRILL (Transparent Interconnection of Lots of Links) presented in 104 [RFC6325] and other related documents, provides methods of utilizing 105 all available paths for active forwarding, with minimum 106 configuration. TRILL utilizes IS-IS (Intermediate System to 107 Intermediate System) as its control plane and encapsulates native 108 frames with a TRILL header. 110 [RFC6325], [RFC6327] and [RFC6439] provide methods for 111 interoperability between TRILL and Legacy networks. [RFC6439], 112 provide an active-standby solution, where only one of the RBridges 113 is in active forwarding state for any given VLAN. The RBridge in 114 active forwarding state for any given VLAN is referred to as the 115 Appointed Forwarder (AF). All frames ingressing into a TRILL network 116 via the Appointed Forwarder are encapsulated with the TRILL header 117 with a nickname held by the ingress AF RBridge. Due to failures, re- 118 configurations and other network dynamics, the Appointed Forwarder 119 for any set of VLANs may change. RBridges maintain forwarding tables 120 that contain destination MAC address and VLAN to egress RBridge 121 binding. In the event of AF change, forwarding tables of remote 122 RBridges may continue to forward traffic to the previous AF and may 123 get discarded at the egress, causing traffic disruption. 125 Mission critical applications such as High Performance Data Centers 126 require resiliency during failover. The active-active forwarding 127 model minimizes impact during failures and maximizes the available 128 network bandwidth. A typical deployment scenario, depicted in Figure 129 1, which may have either End Stations and/or Legacy bridges attached 130 to the RBridges. These Legacy devices typically are multi-homed to 131 several RBridges and treat all of the uplinks as a single Link 132 Aggregation (LAG) bundle [802.1AX]. The Appointed Forwarder 133 designation presented in [RFC6439] requires each of the edge 134 RBridges to exchange TRILL hello packets. By design, a LAG does not 135 forward packets received on one of the member ports of the LAG to 136 other member ports of the same LAG. As a result AF designation 137 methods presented in [RFC6439] cannot be applied to deployment 138 scenario depicted in Figure 1. 140 An active-active load-sharing model can be implemented by 141 representing the edge of the network connected to a specific group 142 of RBridges by a single virtual RBridge. Each virtual RBridge MUST 143 have a nickname unique within its TRILL campus. In addition to an 144 active-active forwarding model, there may be other applications that 145 may requires similar representations. 147 Sections 4.5.1 and 4.5.2 of [RFC6325] specify distribution tree 148 calculation and Reverse Path Forwarding Check calculation algorithms 149 for multi-destination forwarding. The algorithms specified in 150 [RFC6325], strictly depend on link cost and parent RBridge priority. 151 As a result, based on the network topology, it may be possible that 152 a given edge RBridge, if it is forwarding on behalf of the virtual 153 RBridge, may not have a candidate multicast tree that the edge 154 RBridge can forward traffic on because there is no tree for which 155 the virtual RBridge is a leaf node from the edge RBridge. 157 In this document we present a method that allows RBridges to specify 158 the path of association for real or virtual child nodes to 159 distribution trees. Remote RBridges calculate their forwarding 160 tables and derive the RPF for distribution trees based on the 161 distribution tree association advertisements. In the absence of 162 distribution tree association advertisements, remote RBridges derive 163 the SPF based on the algorithm specified in section 4.5.1 of [RFC 164 6325]. 166 Other applications, beside the above mentioned active-active 167 forwarding model, may utilize the distribution tree association 168 framework presented in this document to associate to distribution 169 trees through a preferred path. 171 This proposal requires presence of multiple multi-destination trees 172 within the TRILL campus and updating all the RBridges in the network 173 to support the new Affinity sub-TLV (Section 3. ). It is expected 174 that both of these requirements will be met as they are control 175 plane changes, and will be common deployment scenarios. In case 176 either of the above two conditions are not met RBridges MUST 177 support a fallback option for interoperability. Since the fallback 178 is expected to be a temporary phenomenon till all RBridges are 179 upgraded, this proposal gives guidelines for such fallbacks, and 180 does not mandate or specify any specific set of fallback options. 182 1.1. Scope and Applicability 184 This document specifies a concept of Affinity sub-TLV to solve 185 associated RPF issues at the active-active edge. Specific methods in 186 this document for making use of the Affinity sub-TLV are applicable 187 where multiple RBridges are connected to an edge device through link 188 aggregation or to a multiport server or some similar arrangement 189 where the RBridges cannot see each other's Hellos. 191 This document DOES NOT provide other required operational elements 192 to implement active-active edge solution, such as methods of link 193 aggregation. Solution specific operational elements are outside the 194 scope of this document and will be covered in solution specific 195 documents. (See, for example [TRILLPN].) 197 Examples provided in this document are for illustration purposes 198 only. 200 1.2. Contributors 202 The work in this document is a result of much passionate discussions 203 and contributions from following individuals. Their names are listed 204 in alphabetical order: 206 Ayan Banerjee, Dinesh Dutt, Donald Eastlake, Mingui Zhang, Radia 207 Perlman, Sam Aldrin, Shivakumar Sundaram and Zhai Hongjun. 209 2. Conventions used in this document 211 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 212 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 213 document are to be interpreted as described in [RFC2119]. 215 In this document, these words will appear with that interpretation 216 only when in ALL CAPS. Lower case uses of these words are not to be 217 interpreted as carrying [RFC2119] significance. 219 2.1. Acronyms 221 LAG: Link Aggregation, as specified in [8021AX] 223 CE : Classical Ethernet device, that is a device that performs 224 forwarding based on 802.1Q bridging. This also can be end-station or 225 a server. 227 3. The AFFINITY sub-TLV 229 Association of an RBridge to a multi-destination distribution tree 230 through a specific path is accomplished by using a new IS-IS sub- 231 TLV, the Affinity sub-TLV. 233 The AFFINITY sub-TLV appears in capability TLVs that are within LSP 234 PDUs, as described in [6326bis] which specifies the code point and 235 data structure for the Affinity sub-TLV. 237 4. Multicast Tree Construction and Use of Affinity Sub-TLV 239 Figure 1 and Figure 2 below show the reference topology and a 240 logical topology using CMT to provide active-active service. 242 ------------------- 243 / \ 244 | | 245 | TRILL Campus | 246 | | 247 \ / 248 -------------------- 249 | | | 250 ----- | -------- 251 | | | 252 +------+ +------+ +------+ 253 | | | | | | 254 |(RB1) | |(RB2) | | (RBk)| 255 +------+ +------+ +------+ 256 |..| |..| |..| 257 | +----+ | | | | 258 | +---|-----|--|----------+ | 259 | +-|---|-----+ +-----------+ | 260 | | | +------------------+ | | 261 LAG--->(| | |) (| | |) LAG 262 +-------+ . . . +-------+ 263 | CE1 | | CEn | 264 | | | | 265 +-------+ +-------+ 267 Figure 1 Reference Topology 269 ------------------ Sample Multicast Tree (T1) 270 / \ 271 | | | 272 | TRILL Campus | o RBn 273 | | / | \ 274 \ / / | ---\ 275 --------------------- RB1o o o 276 | | | | RB2 RBk 277 | | | ---------- | 278 | | | oRBv 279 +------+ +------+ +------+ 280 | | | | | | 281 |(RB1) | |(RB2) | | (RBk)| 282 +------+ +------+ +------+ 283 |..| |..| |..| 284 | +----+ | | | | 285 | +---|--|--|-------------+ | 286 | +-|---|--+ +--------------+ | 287 | | | +------------------+ | | 288 LAG--->(| | |) (| | |) LAG 289 +-------+ . . . +-------+ 290 | CE1 | | CEn | 291 | | | | 292 +-------+ +-------+ 294 Figure 2 Example Logical Topology 296 4.1. Update to RFC 6325 298 Section 4.5.1 of [RFC6325], is updated as below: 300 Each RBridge that desires to be the parent RBridge for child Rbridge 301 RBy in a multi-destination distribution tree x announces the 302 desired association using an Affinity sub-TLV. The child RBridge 303 RBy is specified by its nickname (or one of its nicknames if it hold 304 more than one). 306 When such an Affinity sub-TLV is present, the association specified 307 by the affinity sub-TLV MUST be used when constructing the SPF tree 308 except in case of conflicting Affinity sub-TLV which are resolved as 309 specified in Section 5.3. below. In the absence of such an Affinity 310 sub-TLV, or if there are any RBRidges in the campus that are do not 311 support Affinity sub-TLV, distribution trees tree are calculated 312 as specified in the section 4.5.1 of [RFC6325] as updated by 313 [clearcor]. Section 4.3. below explains methods of identifying 314 RBridges that support Affinity sub-TLV capability. 316 4.2. Announcing virtual RBridge nickname 318 Each edge RBridge RB1 to RBk advertises in its LSP virtual RBridge 319 nickname RBv using the Nickname sub-TLV (6), [6326bis], along with 320 their regular nickname or nicknames. 322 It will be possible for any RBridge to determine that RBv is a 323 virtual RBridge because each RBridge (RB1 to RBk) this appears to be 324 advertising that it is holding RBv is also advertising an Affinity 325 sub-TLV asking that RBv be its child in one or more trees. 327 Virtual RBridges are ignored when determining the distribution 328 tree roots for the campus. 330 All RBridges outside the edge group assume that multi-destination 331 packets with ingress nickname RBv might use any of the distribution 332 trees that any member of the edge group is advertising that it might 333 use. 335 4.3. Affinity Sub-TLV Capability. 337 RBridges that announce the TRILL version sub-TLV [6326bis] and set 338 the Affinity capability bit (Section 7. ) support the Affinity sub- 339 TLV and calculation of multi-destination distribution trees and RPF 340 checks as specified herein. 342 5. Theory of operation 344 5.1. Distribution Tree provisioning 346 Let's assume there are n distribution trees and k edge RBridges in 347 the edge group of interest. 349 If n >= k 351 Let's assume edge RBridges are sorted in numerically ascending 352 order by SystemID such that RB1 < RB2 < RBk. Each Rbridge in the 353 numerically sorted list is assigned a monotonically increasing 354 number j such that; RB1=0, RB2=1, RBi=j and RBi+1=j+1. 356 Assign each tree to RBi such that tree number { (tree_number) % 357 k}+1 is assigned to RBridge i for tree_number from 1 to n. where n 358 is the number of trees and k is the number of RBridges considered 359 for tree allocation. 361 If n < k 363 Distribution trees are assigned to RBridges RB1 to RBn, using the 364 same algorithm as n >= k case. RBridges RBn+1 to RBk do not 365 participate in active-active forwarding process on behalf of RBv. 367 5.2. Affinity Sub-TLV advertisement 369 Each RBridge in the RB1..RBk domain advertises an Affinity TLV on 370 behalf of RBv. 372 As an example, let's assume that RB1 has chosen Trees t1 and tk+1 on 373 behalf of RBv. 375 RB1 advertises affinity TLV; {RBv, Num of Trees=2, t1, tk+1. 377 Other RBridges in the RB1..RBk edge group follow the same procedure. 379 5.3. Affinity sub-TLV conflict resolution 381 In TRILL, multi-destination distribution trees are built outward 382 from the root. If an RBridges RB1 advertises an Affinity sub-TLV 383 with an AFFINITY RECORD that asks for RBridge RBroot to be its child 384 in a tree rooted at RBroot, that AFFINITY RECORD is in conflict with 385 TRILL distribution tree root determination and MUST be ignored. 387 If an RBridge RB1 advertises an Affinity sub-TLV with an AFFINITY 388 RECORD that's ask for nickname RBn to be its child in any tree and 389 RB1 is not adjacent to a real or virtual RBridge RBn, that AFFINITY 390 RECORD is in conflict with the campus topology and MUST be ignored. 392 If different RBridges advertise Affinity sub-TLVs that try to 393 associate the same virtual RBridge as their child in the same tree 394 or trees, those Affinity sub-TLVs are in conflict for those trees. 395 The nicknames of the conflicting RBridges are compared to identify 396 which RBridge holds the nickname that is the highest priority to be 397 a tree root, with the System ID as the tie breaker 399 The RBridge with the highest priority to be a tree root will retain 400 the Affinity association. Other RBridges with lower priority to be a 401 tree root MUST stop advertising their conflicting Affinity sub-TLV, 402 re-calculate the multicast tree affinity allocation, and, if 403 appropriate, advertise a new non-conflict Affinity sub-TLV. 405 Similarly, remote RBridges MUST honor the Affinity sub-TLV from the 406 RBridge with the highest priority to be a tree root and ignore the 407 conflicting Affinity sub-TLV entries advertised by the RBridges with 408 lower priorities to be tree roots. 410 5.4. Ingress Multi-Destination Forwarding 412 If there is at least one tree on which RBv has affinity via RBk, 413 then RBk performs the following operations, for multi-destination 414 frames received from a CE node: 416 1. Flood to locally attached CE nodes subjected to VLAN and multicast 417 pruning. 418 2. Encapsulate in TRILL header and assign ingress RBridge nickname as 419 RBv. (nickname of the virtual RBridge). 420 3. Forward to one of the distribution trees, tree x in which RBv is 421 associated with RBk 423 5.4.1. Forwarding when n < k 425 If there is no tree on which RBv can claim affinity via RBk 426 (Probably because the number of trees n built is less than number 427 of RBridges k announcing the affinity sub-TLV), then RBk MUST fall 428 back to one of the following 430 1. This RBridge should stop forwarding frames from the CE nodes, 431 and should mark that port as disabled. This will prevent CE 432 nodes from forwarding data on to this RBridge, and only use 433 those RBridges which have been assigned a tree -OR- 435 2. This RBridge tunnels multi-destination frames received from 436 attached native devices to an RBridge RBy that has an assigned 437 tree. The tunnel destination should forward it to the TRILL 438 network, and also to its local access links . (The mechanism 439 of tunneling and handshake between the tunnel source and 440 destination are out of scope of this specification and may be 441 addressed in future documents). 443 Above fallback options may be specific to active-active forwarding 444 scenario. However, as stated above, Affinity sub-TLV may be used in 445 other applications. In such event the application SHOULD specify 446 applicable fallback options. 448 5.5. Egress Multi-Destination Forwarding 450 5.5.1. Traffic Arriving on an assigned Tree to RBk-RBv 452 Multi-destination frames arriving at RBk on a Tree x, where RBk has 453 announced the affinity of RBv via x, MUST be forwarded to CE members 454 of RBv that are in the frame's VLAN. Forwarding to other end-nodes 455 and RBridges that are not part of the network represented by the RBv 456 virtual RBridge MUST follow the forwarding rules specified in 457 [RFC6325]. 459 5.5.2. Traffic Arriving on other Trees 461 Multi-destination frames arriving at RBk on a Tree y, where RBk has 462 not announced the affinity of RBv via y, MUST NOT be forwarded to CE 463 members of RBv. Forwarding to other end-nodes and RBridges that are 464 not part of the network represented by the RBv virtual RBridge MUST 465 follow the forwarding rules specified in RFC6325. 467 5.6. Failure scenarios 469 The below failure recovery algorithm is presented only as a 470 guideline. Implementations MAY include other failure recover 471 algorithms. Details of such algorithms are outside the scope of this 472 document. 474 5.6.1. Edge RBridge RBk failure 476 Each of the member RBridges of given virtual RBridge edge group is 477 aware of its member RBridges through configuration or some other 478 method. 480 Member RBridges detect nodal failure of a member RBridge through IS- 481 IS LSP advertisements or lack thereof. 483 Upon detecting a member failure, each of the member RBridges of the 484 RBv edge group start recovery timer T_rec for failed RBrdige RBi. If 485 the previously failed RBridge RBi has not recovered after the expiry 486 of timer T_rec, members RBridges perform distribution tree 487 assignment algorithm specified in section 5.1. Each of the member 488 RBridges re-advertises the Affinity sub-TLV with new tree 489 assignment. This action causes the campus to update the tree 490 calculation with the new assignment. 492 RBi upon start-up, starts advertising its presence through IS-IS 493 LSPs and starts a timer T_i. Member RBridges detecting the presence 494 of RBi start a timer T_j. Timer T_j SHOULD be at least < T_i/2. 495 (Please see note below) 497 Upon expiry of timer T_j, member RBridges recalculate the multi- 498 destination tree assignment and advertised the related trees using 499 Affinity sub-TLV. 501 Upon expiry of timer T_i, RBi recalculate the multi-destination tree 502 assignment and advertises the related trees using Affinity TLV. 504 Note: Timers T_i and T_j are designed so as to minimize traffic down 505 time and avoid multi-destination packet duplication. 507 5.7. Backward compatibility 509 Implementations MUST support backward compatibility mode to 510 interoperate with pre Affinity sub-TLV RBRidges in the network. Such 511 backward compatibility operation MAY include, however is not limited 512 to, tunneling and/or active-standby modes of operations. 514 Example: 516 Step 1. Stop using virtual RBridge nickname for traffic ingressing 517 from CE nodes 518 Step 2. Stop performing active-active forwarding. And fall back to 519 active standby forwarding, based on locally defined policies. 520 Definition of such policies is outside the scope of this document 521 and may be addressed in future documents. 523 6. Security Considerations 525 Security considerations are similar to RFC 6325,RFC 6326 and RFC 526 6327. Additional security considerations are being discussed. 528 7. IANA Considerations 530 IANA is requested to allocate a capability bit for 531 ''Affinity Supported'' in the TRILL-VER sub-TLV. ''Affinity 532 Supported'' capability bit and Affinity sub-TLV are specified and 533 allocated in [6326bis]. 535 8. References 537 8.1. Normative References 539 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 540 Requirement Levels", BCP 14, RFC 2119, March 1997. 542 [RFC6325] Perlman, R., et.al. ''RBridge: Base Protocol 543 Specification'', RFC 6325, July 2011. 545 [RFC6327] Eastlake, D. et.al., ''RBridge: Adjacency'', RFC 6327, July 546 2011. 548 [RFC6439] Eastlake, D. et.al., ''RBridge: Appointed Forwarder'', RFC 549 6439, November 2011. 551 [6326bis] Eastlake, D. et.al., ''Transparent Interconnection of Lots 552 of Links (TRILL) Use of IS-IS'', draft-eastlake-isis- 553 rfc6326bis, Work in Progress, December 2011. 555 [clearcor] Eastlake, D. et.al., ''TRILL: Clarifications, Corrections, 556 and Updates'', draft-ietf-trill-clear-correct, Work in 557 Progress, July 2011. 559 8.2. Informative References 561 [RFC6165] Banerjee, A. and Ward, D. ''Extensions to IS-IS for Layer-2 562 Systems'', RFC 6165, April 2011. 564 [RFC4971] Vasseur, JP. et.al ''Intermediate System to Intermediate 565 System (IS-IS) Extensions for Advertising Router 566 Information'', RFC 4971, July 2007. 568 [TRILLPN] Zhai,H., et.al ''RBridge: Pseudonode Nickname'', draft-hu- 569 trill-pseudonode-nickname, Work in progress, November 570 2011. 572 [8021AX] IEEE, ''Link Aggregration'', 802.1AX-2008, 2008. 574 [8021Q] IEEE, ''Media Access Control (MAC) Bridges and Virtual 575 Bridged Local Area Networks'', IEEE Std 802.1Q-2011, 576 August, 2011 578 9. Acknowledgments 580 Authors wish to extend their appreciations towards individuals who 581 volunteered to review and comment on the work presented in this 582 document and provided constructive and critical feedback. Specific 583 acknowledgements are due for Anoop Ghanwani, Ronak Desai, and Varun 584 Shah. Very special Thanks to Donald Eastlake for his careful review 585 and constructive comments. 587 This document was prepared using 2-Word-v2.0.template.dot. 589 10. Authors' Addresses 591 Tissa Senevirathne 592 Cisco Systems 593 375 East Tasman Drive, 594 San Jose, CA 95134 596 Phone: +1-408-853-2291 597 Email: tsenevir@cisco.com 599 Janardhanan Pathangi 600 Dell/Force10 Networks 601 Olympia Technology Park, 602 Guindy Chennai 600 032 604 Phone: +91 44 4220 8400 605 Email: Pathangi_Janardhanan@Dell.com 607 Jon Hudson 608 Brocade 609 130 Holger Way 610 San Jose, CA 95134 USA 612 Email: jon.hudson@gmail.com