idnits 2.17.1 draft-yizhou-trill-tc-awareness-03.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 abstract seems to contain references ([RFC6325]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 21, 2013) is 3806 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: 'RFC2119' is mentioned on line 230, but not defined == Missing Reference: 'ISO-10589' is mentioned on line 300, but not defined == Missing Reference: 'RFC6326' is mentioned on line 360, but not defined ** Obsolete undefined reference: RFC 6326 (Obsoleted by RFC 7176) == Unused Reference: '6326bis' is defined on line 526, but no explicit reference was found in the text == Unused Reference: 'RFC6327' is defined on line 537, but no explicit reference was found in the text == Unused Reference: 'RFC6165' is defined on line 547, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-eastlake-isis-rfc6326bis-07 ** Obsolete normative reference: RFC 6439 (Obsoleted by RFC 8139) ** Obsolete normative reference: RFC 6327 (Obsoleted by RFC 7177) Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Yizhou Li 2 Internet Draft Weiguo Hao 3 Intended status: Standards Track Huawei Technologies 4 Jon Hudson 5 Brocade 6 Naveen Nimmu 7 Broadcom 8 Anoop Ghanwani 9 DELL 11 Expires: May 25, 2014 November 21, 2013 13 Aware Spanning Tree Topology Change on RBridges 14 draft-yizhou-trill-tc-awareness-03.txt 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as 29 reference material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on May 21, 2009. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with 49 respect to this document. Code Components extracted from this 50 document must include Simplified BSD License text as described in 51 Section 4.e of the Trust Legal Provisions and are provided without 52 warranty as described in the Simplified BSD License. 54 Abstract 56 When a local LAN running spanning tree protocol connecting to TRILL 57 campus via more than one RBridge, there are several ways to perform 58 loop avoidance. One of them illustrated by RFC6325 [RFC6325] A.3 was 59 to make relevant ports on edge RBridges involving in spanning tree 60 calculation. When edge RBridges are emulated as a single highest 61 priority root, the local bridged LAN will be naturally partitioned 62 after running spanning tree protocol. This approach achieves better 63 link utilization and intra-VLAN load balancing in some scenarios. 64 This document describes how the edge RBridges react to topology 65 change occurring in bridged LAN in order to make the abovementioned 66 spanning tree approach function correct. 68 Table of Contents 70 1. Introduction ............................................. 3 71 1.1. Motivations ......................................... 5 72 2. Conventions used in this document ........................ 6 73 3. BPDU RBridge Channel and TLVs ............................ 6 74 3.1. BPDU TLV ............................................ 7 75 3.2. Authentication Information TLV ...................... 7 76 4. Operations ............................................... 8 77 4.1. Sending BPDU using RBridge channel .................. 9 78 4.2. Receiving BPDU in RBridge channel................... 10 79 4.3. Informing the remote site .......................... 11 80 5. Security Considerations ................................. 13 81 6. IANA Considerations ..................................... 13 82 7. References .............................................. 13 83 7.1. Normative References ............................... 13 84 7.2. Informative References.............................. 14 85 8. Acknowledgments ......................................... 14 87 1. Introduction 89 The TRILL protocol [RFC6325] provides the appointed forwarder 90 mechanism [RFC6439] for loop avoidance where, for part of the loop, 91 the frame would be in TRILL encapsulated format, for example in the 92 scenario shown by Figure 1. Only one of the RBridges is responsible 93 for encapsulating/decapsulating a given VLAN's data frames on a link. 94 Bridges in the local bridged LAN runs normal spanning tree protocol 95 for local loop avoidance. RBridges keeps track of the root bridge by 96 listening to BPDUs received on the local port. This information is 97 reported per VLAN by the RBridge in its LSP and is used to detect a 98 root bridge change. Root bridge changes trigger the reset of the 99 inhibition timer of the appointed forwarder. When an RBridge ceases 100 to be appointed forwarder for a VLAN on a port, it sends topology 101 change BPDUs to purge the MAC table on local bridged LAN switches. 102 An RBridge conformable to [RFC6325] never encapsulates or forwards 103 any BPDU frame it receives. 105 ------------------ 106 / \ 107 | Trill Network | 108 \ / 109 ------------------ 110 | | 111 DRB| | 112 +------+ +------+ 113 AF --->| RB1 | | RB2 | 114 +------+ +------+ 115 | | 116 +---------------------------------------------+ 117 | | | | 118 | STP | | | 119 | +----+ root+----+ +----+ | 120 | | B4 |-------| B1 |-------| B2 | | 121 | +----+ +----+ +----+ | 122 | | | | 123 | | | | 124 | | |<---blocked | 125 |Bridged | +----+ | | 126 |LAN +-----| B3 |----+ | 127 | +----+ | 128 +---------------------------------------------+ 130 Figure 1 TRILL and bridged LAN topology 132 [RFC6325] A.2 & A.3 presented the problems using the conventional 133 approach shown in Figure 1. Native frames enter and leave a link via 134 the link's appointed forwarder for the VLAN of the frame can cause 135 congestion or suboptimal routing. Four methods was illustrated in 136 [RFC6325] to solve the problem, 138 1. Use RBridge instead of conventional bridge 140 2. Re-arrange network topology 142 3. Carefully select the different appointed forwarders for VLANs if 143 end stations on local bridged LAN can be separated into multiple 144 VLANs 146 4. Configure the RBridges to be like one STP tree root in local 147 bridged LAN. The RBridge ports that are connected to the bridged 148 LAN send spanning tree configuration BPDUs. Then the bridged LAN 149 is forced into partitions. Figure 2 shows its network topology. 151 Method 1 and 2 highly depends on the network topology and equipment 152 types and therefore have very limited applicability. Method 3 and 4 153 have broader applicability. Method 4 is more applicable than method 154 3 if all end stations in bridged LAN are on the same VLAN or intra 155 VLAN load balancing is required to avoid per VLAN congestion and 156 suboptimal routing. The traffic discontinuity was caused by 157 inhibition timer setting in case of root change in method 3. Proper 158 timeout value has to be carefully chosen for tradeoff between 159 unnecessary traffic continuity and potential loop. Method 4 160 eliminates the requirement of setting inhibition timer in case of 161 root change. Therefore method 4 is considered as a very common 162 practice in real deployment. 164 ------------------ 165 / \ 166 | Trill Network | 167 \ / 168 ------------------ 169 | | 170 | | 171 -----+-----------+---- 172 / +------+ +------+ \ <---emulated highest 173 | | RB1 | | RB2 | | priority root Bx 174 -------------| +------+ +------+ |--------- 175 | \-----+-----------+-----/ | 176 | | | | 177 | | | | 178 | | | | 179 | +----+ +----+ \|/ +----+ | 180 | | B4 |-------| B1 |--- ---| B2 | | 181 | +----+ p1 +----+ /|\ +----+ | 182 | | | | | 183 | | blocked \|/ | 184 | | - ----blocked | 185 |Bridged | /|\ | 186 |LAN | +----+ | | 187 | +-----| B3 |----+ | 188 | p1 +----+ p2 | 189 ----------------------------------------------- 190 Figure 2 RBs function as STP tree root topology 192 1.1. Motivations 194 Bridged LANs may have topology changes at any time. When RB1 & RB2 195 serve as one single STP tree root as shown in Figure 2, it is 196 required that RB1 and RB2 have to tunnel some BPDUs to help the 197 bridged LAN convergence in certain circumstances. Figure 2 will be 198 used to illustrate such motivation for rest of this subsection. 200 RB1 & RB2 use the same bridge ID to emit spanning tree BPDUs as the 201 highest priority root Bx. All bridges in LAN see RB1 and RB2 as a 202 single tree root. Therefore B1-B2 and B2-B3 links are blocked for 203 loop avoidance by the spanning tree protocol. RB1 and RB2 will not 204 receive TRILL-Hello from each other. Bridged LAN is logically 205 partitioned into two parts. RB1 is DRB and AF for all VLANs in left 206 partition and RB2 is DRB and AF in right partition. 208 If B1-B3 link fails for some reason, alternate port p2 on B3 will 209 send topology change (TC) BPDU to B2 as RSTP specifies [802.1D]. B2- 210 B3 link will start forwarding frames. TC BPDU is then sent from B2 211 to RB2. As RB2 never forwards BPDU frame to TRILL campus, left 212 partition has no way to know the topology change. Therefore B4 will 213 not able to correctly purge the MACs learnt from port p1 for end 214 stations connected to B3. MAC table entry aging is the last resort 215 in this case. In addition, a remote end station may keep sending 216 traffic to an end station connected to B3 via RB1-B1 which causes 217 frame loss. Therefore some mechanism must be introduced to purge the 218 MACs learned both in the left partition of the bridged LAN and at 219 the remote Rbridges when topology changes. 221 This draft proposes to use RBridge channel [TRILLChannel] to tunnel 222 the TC BPDU to solve the issue. It complements Appendix A.3 of 223 RFC6325 to improve correctness and efficiency. 225 2. Conventions used in this document 227 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 228 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 229 document are to be interpreted as described in RFC-2119 [RFC2119]. 231 This document uses the terminologies defined in [RFC6325] along with 232 the following: 234 Root Bridge Group - A group of RBridges acting as an emulated single 235 tree root in a spanning tree instance in local bridged LAN. The 236 group has at least two RBridges. 238 3. BPDU RBridge Channel and TLVs 240 A new channel protocol is defined to carry BPDU. 242 Channel protocol code: TBD (BPDU) 243 | 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15| 244 RBridge Channel Header: 245 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 246 | RBridge Channel Ethertype | 247 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 248 | CHV | Channel Protocol (BPDU) | 249 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 250 | Flags | ERR | 251 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 252 RBridge Channel BPDU Specific Information: 253 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 254 | Domain ID | reserved | 255 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 256 . TLVs . 257 . . 258 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 259 Figure 3 RBridge Channel Format for BPDU 261 Domain ID: Unique ID to identify a single spanning tree domain. 262 Reserved: 4 bits reserved field. 264 The fields of TRILL header and inner Ethernet header SHOULD be set 265 as per [TRILLChannel] unless specified in this draft. 267 3.1. BPDU TLV 269 +-+-+-+-+-+-+-+-+ 270 | Type= | (1 byte) 271 +-+-+-+-+-+-+-+-+ 272 | Length | (1 byte) 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | BPDU | (variable length) 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 BPDU: field used to put the original BPDU frame, typically is TC 277 (topology awareness) BPDU. 279 3.2. Authentication Information TLV 281 +-+-+-+-+-+-+-+-+ 282 | Type= | (1 byte) 283 +-+-+-+-+-+-+-+-+ 284 | Length | (1 byte) 285 +-+-+-+-+-+-+-+-+ 286 | Auth Mode | (1 byte) 287 +-+-+-+-+-+-+-+-+-.....-+-+-+-+-+-+-+-+-+ 288 | Auth Value | (variable length) 289 +-+-+-+-+-+-+-+-+-.....-+-+-+-+-+-+-+-+-+ 291 Auth Mode: 293 +------------------------------+-------+-------------+ 294 | Authentication Mode Code | Value | Reference | 295 +------------------------------+-------+-------------+ 296 | Reserved | 0 | [ISO-10589] | 297 | Cleartext Password | 1 | [ISO-10589] | 298 | ISO 10589 Reserved | 2 | [ISO-10589] | 299 | HMAC-MD5 Authentication | 54 | RFC 5304 | 300 | Routing Domain private | 255 | [ISO-10589] | 301 | authentication method | | | 302 +------------------------------+-------+-------------+ 304 Auth Value: Value used to authenticate the RBridge Channel BPDU 305 Specific Information using the algorithm specified by Auth Mode 307 This TLV is used for channel message authentication. When an RBridge 308 receives a channel message with Authentication Information, it MUST 309 discard it if the Authentication Value is incorrect. 311 4. Operations 313 Figure 4 shows TC BPDU tunneled from RB2 to RB1 using RBridge 314 Channel. 316 ------------------------- 317 / \ 318 / \ 319 | Trill Network | 320 | | 321 | +---------------+ | 322 | | 4.tunnel BPDU | | 323 | | in channel | | 324 \ | +-----------+ | / 325 \ | | | | / 326 \ ---|-|-----------|-|-- / 327 / +-+ +--+ +--+ +-+ \ <--- emulated highest 328 | | RB1 | | RB2 | | priority root Bx 329 ------------| +------+ +------+ |------------------ 330 | \-----+-----------+-----/ | 331 | | | | 332 | 5. TC BPDU | | | /|\ 3. TC BPDU | 333 | \|/ | | | | 334 | | | | 335 | +----+ +----+ \|/ +----+ | 336 | | B4 |-------| B1 |--- ---| B2 | | 337 | +----+ +----+ /|\ +----+ | 338 | | | | | 339 | | blocked | | 340 | | |<---blocking to | 341 | 1.link \|/ | forwarding | 342 | failure --> | | 343 | /|\ | | 344 | | | | 345 | | +----+ p2 | /|\ | 346 | +--| B3 |-------+ | | 347 |Bridged +----+ ---------+ | 348 |LAN 2. TC BPDU | 349 | | 350 -------------------------------------------------------| 351 Figure 4 Tunneled TC BPDU 353 4.1. Sending BPDU using RBridge channel 355 In figure 4, when B1-B3 link fails, alternate port p2 on B3 will 356 start to send TC BPDU and go to forwarding state. RB2 receives TC 357 BPDU from B2 sequentially. RB2 encapsulates the TC BPDU in RBridge 358 channel and sends it to RB1. 360 Interested VLANs and Spanning Tree Roots Sub-TLV [RFC6326] carries 361 spanning tree root bridge IDs seen for all ports for which the 362 RBridge is the appointed forwarder for a VLAN. As RB1 and RB2 use 363 the same bridge ID and that bridge ID is the spanning tree root, RB1 364 and RB2 are considered as in a root bridge group. Static 365 configuration of root bridge group is also allowed. 367 When RBridge receives TC BPDU from an access port, it tunnels the 368 frame to all the other RBridges in the same root bridge group using 369 RBridge channel protocol specified in section 3. Normally the number 370 of RBridges in a root bridge group is limited, say 2 or 3; such 371 tunneling is performed using TRILL unicast encapsulation. N members 372 in a root bridge group results in N-1 sequential unicast BPDU 373 tunneled. In figure 4, RB2 knows RB1 is in the same root bridge 374 group from LSP exchange; hence RB2 uses RB1's nickname as egress 375 nickname and encapsulates the TC BPDU in RBridge channel. M bit in 376 TRILL header SHOULD be 0. 378 If TRILL Campus was partitioned temporarily in some unusual cases, 379 RBridges in the same root bridge group may not reach each other. For 380 instance, if RB2 was not able to reach RB1 through TRILL campus at 381 some transition period due to network fault, RB1 would not receive 382 the tunneled TC BPDU from RB2. Then the approach illustrated in this 383 document will take effect again only after RB1 and RB2 connectivity 384 via TRILL recovers from the network fault. 386 It is possible to statically configure a root bridge group, especial 387 when network is relatively small and stable. Therefore when an 388 RBridge tunnels the TC BPDU to other members in the same root bridge 389 group, it has to make sure the destination is reachable. 391 If edges RBridges configured in the same root bridge group connect 392 to separate TRILL campus intentionally, it is not recommended to use 393 spanning tree partition mechanism and such root bridge group 394 provisioning is normally considered as mis-configuration. 396 4.2. Receiving BPDU in RBridge channel 398 When an RBridge receives a TC BPDU from RBridge channel, it 399 determines the frame was sent from an RB in the same root bridge 400 group. Then RBridge decapsulates the frame and sends the original TC 401 BPDU to its local bridged LAN. TC BPDU will be flooded throughout 402 the access ports configured as the same domain ID specified by BPDU 403 RBridge channel in the left partition to purge MAC table of bridges. 405 4.3. Informing the remote site 407 When local topology changes, the correspondence of end station and 408 its attaching RBridge cached by remote RB may become invalid. The 409 RBridges who is the appointed forwarder for the specified VLAN in 410 remote sites should be informed to update the stale correspondence 411 table entry. 413 When traffic is bi-directional, the remote RBridge will receive the 414 data frames from the newly attached RBridge of the local end station. 415 The remote RBridge will update its MAC-Nickname correspondence table 416 naturally though data frame learning. 418 When traffic is uni-directional from the remote to local site or 419 traffic from local to remote has to be triggered by traffic from 420 remote to local, remote RBridge will not receive the data frame from 421 local RBridge to refresh its table. Then traffic discontinuity may 422 last for some time until the table entry is aged out at the remote 423 RBridge. 425 A lightweight method is to use RBridge channel to carry MAC purge 426 information. In Figure 4, When RB2 receives TC BPDU from B2, it 427 derives the corresponding VLAN list. For example, if MSTP is used, 428 RB2 will get the VLAN IDs in the same MSTP instance as TC BPDU. RB2 429 sends out MAC purge information using RBridge channel with VLAN 430 information and RBidges' nicknames in the same root bridge group. 431 All remote RBridges received MAC purge should clear its MAC-to- 432 nickname correspondence table for entries with the specified 433 nicknames and VLAN IDs. If no VLAN list is specified, the remote 434 RBridges should clear the correspondence in all VLANs relevant to 435 the given nicknames. The MAC purge is recommended to send on the 436 management VLAN in which all RBridges joins. 438 A new channel protocol code for MAC purge should be defined as 439 follows. 441 | 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15| 442 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 443 | RBridge Channel | 444 | Header | 445 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 446 | Number of nicknames | nickname 1 | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | nickname 1 | nickname 2 | 449 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 450 | nickname 2 | ... | 451 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 452 | ... | nickname n | 453 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 454 | nickname n | Num of VLAN blocks| 455 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 456 | Start.VLAN | | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | End.VLAN | | 459 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 460 | Other Start/End VLAN list ... | 461 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 462 . TLVs . 463 . . 464 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 466 Figure 5 RBridge Channel Format for MAC Purge 468 Number of nicknames: number of the following nicknames, which will 469 be used by the receivers to purge their relevant MAC-to-nickname 470 correspondence table entries. 472 Num of VLAN blocks: number of the following VLAN block. A VLAN block 473 is specified by a start and an end VLAN IDs. When start and end VLAN 474 IDs are the same, it implies only one VLAN ID is in the block. When 475 number of VLAN block is 0, it implies no VLAN ID is specified. 477 For any nickname x specified and any VLAN y specified in this TLV, 478 the receivers should purge MAC-to-nickname correspondence table 479 entries with (any-MAC, VLAN-y, nickname-x). When number of VLAN 480 block is 0, the receivers should purge entries with (any-MAC, any- 481 VLAN, nickname-x). 483 Authentication Information TLV specified by section 3.2 can be used 484 in MAC Purge channel message. 486 5. Security Considerations 488 This document does not change the general RBridge security 489 considerations of the TRILL base protocol and TRILL RBridge Channel. 490 See Section 6 of [RFC6325] and section 7 of [TRILLChannel]. 492 Massive TC BPDU may trigger RBridges continuously sending tunneled 493 BPDU and MAC purges. It may cause denial-of-service in TRILL campus. 494 Similar as the traditional bridged LAN running spanning tree, it is 495 suggested to monitor the receiving rate of TC BPDU on bridged LAN 496 facing port of RBridges. If the receiving rate is beyond the 497 threshold, RBridge should only process and tunnel the TC BPDU in the 498 configured rate. 500 Authentication TLV should be included if risk of injecting forged 501 information is a concern. However keeping channel information in 502 this document secret and private is not necessary and is not a 503 requirement. 505 6. IANA Considerations 507 IANA is requested to allocate the new channel protocol codes as 508 following. 510 Channel protocol code X1: BPDU 512 Channel protocol code X2: MAC purge 514 BPDU TLV type: 516 Authentication Information TLV type: 518 7. References 520 7.1. Normative References 522 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 523 Ghanwani, "Routing Bridges (RBridges): Base Protocol 524 Specification", RFC 6325, July 2011. 526 [6326bis] Eastlake, D. et.al., ''Transparent Interconnection of Lots 527 of Links (TRILL) Use of IS-IS'', draft-eastlake-isis- 528 rfc6326bis-07.txt, Work in Progress, December 2011. 530 [RFC6439] Eastlake, D. et.al., ''RBridge: Appointed Forwarder'', RFC 531 6439, November 2011. 533 [TRILLChannel] - Eastlake, D., V. Manral, Y. Li, S. Aldrin, D. Ward, 534 "RBridges: RBridge Channel Support in TRILL", draft-ietf- 535 trill-rbridge-channel, work in progress. 537 [RFC6327] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., 538 and V. Manral, "Routing Bridges (RBridges): Adjacency", 539 RFC 6327, July 2011 541 [802.1D] "IEEE Standard for Local and metropolitan area networks 542 /Media Access Control (MAC) Bridges", 802.1D-2004, 9 June 543 2004. 545 7.2. Informative References 547 [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 548 Systems", RFC 6165, April 2011. 550 [802.1Q-2011] "IEEE Standard for Local and metropolitan area 551 networks /Virtual Bridged Local Area Networks", 802.1Q- 552 2011, 31 Aug 2011. 554 8. Acknowledgments 556 This document was prepared using 2-Word-v2.0.template.dot. 558 Appendix: Change History 560 Changes from -01 to -02 562 1. Add domain ID field to BPDU channel message. 564 2. Allow TLVs for BPDU and MAC Purge channel message. 566 3. Change BPDU channel message. Make BPDU field from fixed field 567 to TLV 569 4. Add Authentication Information TLV 571 6. Assorted editorial changes. 573 Authors' Addresses 575 Yizhou Li 576 Huawei Technologies 577 101 Software Avenue, 578 Nanjing 210012 579 China 581 Phone: +86-25-56625375 582 Email: liyizhou@huawei.com 584 Weiguo Hao 585 Huawei Technologies 586 101 Software Avenue, 587 Nanjing 210012 588 China 590 Phone: +86-25-56623144 591 Email: haoweiguo@huawei.com 593 Jon Hudson 594 Brocade 595 120 Holger Way 596 San Jose, CA 95134 597 USA. 599 Email: jon.hudson@gmail.com 601 Naveen Nimmu 602 Broadcom 603 9th Floor, Building no 9, Raheja Mind space 604 Hi-Tec City, Madhapur, 605 Hyderabad - 500 081, INDIA 607 Phone: +1-408-218-8893 608 Email: naveen@broadcom.com 610 Anoop Ghanwani 611 DELL 612 350 Holger Way 613 San Jose, CA 95134 614 USA. 616 Phone: +1-408-571-3500 617 Email: Anoop@alumni.duke.edu