idnits 2.17.1 draft-hao-trill-rb-syn-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 : ---------------------------------------------------------------------------- ** There are 12 instances of too long lines in the document, the longest one being 2004 characters in excess of 72. ** The abstract seems to contain references ([CMT], [TRILLPN]), 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 == Line 348 has weird spacing: '... group link ...' == Line 555 has weird spacing: '...removed in lo...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 06, 2014) is 3611 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: 'CMT' is mentioned on line 186, but not defined == Missing Reference: 'RFC2119' is mentioned on line 212, but not defined == Missing Reference: 'PSEUDO-NICK' is mentioned on line 252, but not defined == Unused Reference: 'RFC6326' is defined on line 625, but no explicit reference was found in the text == Unused Reference: '6326bis' is defined on line 629, but no explicit reference was found in the text == Unused Reference: 'RFC6439' is defined on line 635, but no explicit reference was found in the text == Unused Reference: 'TRILLChannel' is defined on line 639, but no explicit reference was found in the text == Unused Reference: 'RFC6327' is defined on line 645, but no explicit reference was found in the text == Unused Reference: 'TRILL-CMT' is defined on line 654, but no explicit reference was found in the text == Unused Reference: 'RFC6165' is defined on line 667, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6326 (Obsoleted by RFC 7176) -- Possible downref: Non-RFC (?) normative reference: ref. '6326bis' ** Obsolete normative reference: RFC 6439 (Obsoleted by RFC 8139) -- Possible downref: Non-RFC (?) normative reference: ref. 'TRILLChannel' ** Obsolete normative reference: RFC 6327 (Obsoleted by RFC 7177) == Outdated reference: A later version (-11) exists of draft-ietf-trill-cmt-01 -- Possible downref: Non-RFC (?) normative reference: ref. '8021AX' == Outdated reference: A later version (-11) exists of draft-ietf-l2vpn-evpn-02 Summary: 5 errors (**), 0 flaws (~~), 16 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Weiguo Hao 2 Yizhou Li 3 Liang Xia 4 Internet Draft Huawei Technologies 5 HJ. Zhai 6 ZTE Corporation 7 Intended status: Standards Track June 06, 2014 8 Expires: December 2014 10 The problem statement of RBridge edge group state synchronization 11 draft-hao-trill-rb-syn-03.txt 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. This document may not be modified, 20 and derivative works of it may not be created, and it may not be 21 published except as an Internet-Draft. 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. This document may not be modified, 25 and derivative works of it may not be created, except to publish it 26 as an RFC and to translate it into languages other than English. 28 This document may contain material from IETF Documents or IETF 29 Contributions published or made publicly available before November 10, 30 2008. The person(s) controlling the copyright in some of this 31 material may not have granted the IETF Trust the right to allow 32 modifications of such material outside the IETF Standards Process. 33 Without obtaining an adequate license from the person(s) controlling 34 the copyright in such materials, this document may not be modified 35 outside the IETF Standards Process, and derivative works of it may 36 not be created outside the IETF Standards Process, except to format 37 it for publication as an RFC or to translate it into languages other 38 than English. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet-Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html 55 This Internet-Draft will expire on December 6, 2014. 57 Copyright Notice 59 Copyright (c) 2014 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents carefully, 66 as they describe your rights and restrictions with respect to this 67 document. Code Components extracted from this document must include 68 Simplified BSD License text as described in Section 4.e of the Trust 69 Legal Provisions and are provided without warranty as described in 70 the Simplified BSD License. 72 This document is subject to BCP 78 and the IETF Trust's Legal 73 Provisions Relating to IETF Documents 74 (http://trustee.ietf.org/license-info) in effect on the date of 75 publication of this document. Please review these documents carefully, 76 as they describe your rights and restrictions with respect to this 77 document. 79 Abstract 81 In TRILL multi-homing scenario, the concept of virtual RBridge in 82 [TRILLPN], was introduced to address the MAC flip-flopping problem at 83 remote RBridges. Based on virtual RBridge mechanism, Coordinated 84 Multicast Trees (CMT) solution in [CMT] was introduced to solve the 85 related RPF issues. In this document, additional problems are 86 described regarding virtual Bridges members' state synchronization in 87 multi-homing scenario, including virtual RBridge membership auto 88 discovery, pseudo-nickname static configuration consistency check, 89 dynamic pseudo-nickname allocation, CMT configuration 90 synchronization ,LACP configuration and state synchronization, 91 node/link failure detection, MAC table synchronization, DHCP snooping 92 information, and dynamically joined VLANs and multicast groups. To 93 address these problems, a communication protocol among members of a 94 virtual RBridge group should be provided. Requirements for this 95 protocol are also discussed. 97 Table of Contents 99 1. Introduction ................................................ 3 100 2. Conventions used in this document............................ 5 101 3. Problem Statement ........................................... 6 102 3.1. RBv membership configuration and state synchronization...6 103 3.2. CMT configuration and state synchronization .............7 104 3.3. LACP configuration and state synchronization ............8 105 3.4. MAC table synchronization.............................. 10 106 3.5. Dynamic VLAN and multicast group table synchronization..11 107 3.6. DHCP snooping table synchronization ....................11 108 4. Requirements for communication protocol in RBv ..............11 109 5. Security Considerations..................................... 14 110 6. IANA Considerations ........................................ 14 111 7. References ................................................. 14 112 7.1. Normative References................................... 14 113 7.2. Informative References................................. 15 114 8. Acknowledgments ............................................ 15 116 1. Introduction 118 TRILL (Transparent Interconnection of Lots of Links) presented 119 in[RFC6325] and other related documents, provides methods of 120 utilizing all available paths for active forwarding with minimum 121 configuration. TRILL utilizes IS-IS (Intermediate System to 122 Intermediate System) as its control plane and encapsulates native 123 frames with a TRILL header. 125 +------+ 126 | CEx | 127 +------+ 128 | 129 +------+ 130 |(RBx) | 131 +------+ 132 | 134 ------------------- 135 / \ 136 | | 137 | TRILL Campus | 138 | | 139 \ / 140 -------------------- 141 | | | 142 -------- | -------- 143 | | | 144 +------+ +------+ +------+ 145 |(RB1) | |(RB2) | | (RBk)| 146 +------+ +------+ +------+ 147 | | | | 148 | --------- ------ | 149 | | LAG1 LAG2 | | 150 +------+ +------+ 151 | CE1 | | CE2 | 152 +------+ +------+ 154 Figure 1 Reference Topology 156 In order to improve the reliability of connection to TRILL network , 157 CE devices typically are multi-homed to edge RBridges and treat all 158 of the uplinks as a single Link Aggregation (LAG) bundle [802.1AX] in 159 the scenario shown by Figure 1. In this scenario, When remote RBridge 160 RBx receives a frame originated by CE1, the ingress RBridge maybe 161 either one of the edge RBridges i.e. RB1 or RB2. The learning on RBx 162 for source MAC will flip-flop between RB1's and RB2's nicknames. In 163 [TRILLPN], the concept of Virtual RBridge, along with its pseudo- 164 nickname, is introduced to address the MAC flip-flopping problem in 165 remote RBridges. 167 A Virtual RBridge (RBv) represents a group of different ports on 168 different edge RBridges, on which these RBridges provide end-station 169 service to a set of their attached CE devices. After joining RBv, 170 such an RBridge port is called a member port of RBv, and such an 171 RBridge becomes a member RBridge of RBv. In an RBridge RBv is 172 identified by its virtual nickname in TRILL campus, and virtual 173 nickname is also referred to as pseudo-nickname in this specification. 175 An RBridge port can join at most one RBv at any time, but different 176 ports on the same RBridge can join the same RBv or different RBvs. 177 After joining an RBv, such a port becomes a member port of the RBv, 178 and the RBridge becomes a member RBridge of the RBv. 180 Furthermore, for a member RBridge, it MUST move out of RBv and clear 181 the RBv's information from its self-originated LSPs when it loses the 182 last member port from this group, due to port down, configuration, 183 and etc. 185 Based on the concept of Virtual RBridge and pseudo-nickname, 186 Coordinated Multicast Trees (CMT) [CMT] solution was introduced to 187 solve the related RPF issues. In CMT solution, different member 188 RBridges are assigned different distribution trees for forwarding the 189 multi-destination TRILL data frames that using RBv's pseudo-nickname 190 as ingress nickname in their TRILL header. 192 When a member RBridge joins into or leaves from a virtual RBridge 193 group RBv due to its last member ports up/down or its configuration 194 changing, the distribution trees assigned to different member 195 RBridges may change. 197 For TRILL multi-homing scenario, pseudo-nickname and CMT is not 198 sufficient to provide a complete solution. Additional problems such 199 as RBv membership management, LACP configuration and state 200 synchronization, node and access link failure detection, and etc 201 still exist. This draft is going to talk about those problem in more 202 details. 204 2. Conventions used in this document 206 In examples, "C:" and "S:" indicate lines sent by the client and 207 server respectively. 209 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 210 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 211 document are to be interpreted as described in RFC-2119 [RFC2119]. 213 In this document, these words will appear with that interpretation 214 only when in ALL CAPS. Lower case uses of these words are not to be 215 interpreted as carrying RFC-2119 significance. 217 In this document, the characters ">>" preceding an indented line(s) 218 indicates a compliance requirement statement using the key words 219 listed above. This convention aids reviewers in quickly identifying 220 or finding the explicit compliance requirements of this RFC. 222 TRILL: Transparent Interconnection of Lots of Links. TRILL presented 223 in [RFC6325] and other related documents, provides methods of 224 utilizing all available paths for active forwarding, with minimum 225 configuration. TRILL utilizes IS-IS (Intermediate System to 226 Intermediate System) as its control plane and encapsulates native 227 frames with a TRILL header. 229 CE: Classical Ethernet device, that is a device that performs 230 forwarding based on 802.1Q bridging. This also can be end-station or 231 a server. 233 CMT: Coordinated Multicast Trees. 235 LACP: Link Aggregation Control Protocol. 237 LAG: Link Aggregation, as specified in [8021AX]. 239 RB: Router Bridge. RBs are a switch that implements the TRILL 240 protocol and combine the advantages of bridges and routers. 242 3. Problem Statement 244 For TRILL multi-homing scenario, the following problems should be 245 addressed: 247 3.1. RBv membership 248 configuration and state 249 synchronization 251 A Virtual RBridge (RBv) is identified by its virtual nickname 252 referred as pseudo-nickname in [PSEUDO-NICK]. RBv must allow static 253 member configuration by network operator. 255 If each member of RBv statically configures its RBridge ports with a 256 pseudo-nickname, the pseudo-nickname should be consistent among all 257 member RBridges in RBv. Communication protocol between member 258 RBridges should be provided to ensure pseudo-nickname configuration 259 consistency in RBv. Member RBridges in RBv should notify each other 260 to find if conflict of pseudo-nickname configuration exists when 261 pseudo-nickname is configured. For example: 263 The RBridges configured with same pseudo-nickname are not in the same 264 LACP group. 266 The Rbridges configured in the same LACP group don't have the same 267 pseudo-nickname. 269 If conflict exists, It is recommended to send trap to network 270 management system (NMS) and let operator modify configuration to 271 eliminate conflict. Only when the conflict is removed, each member 272 RBridge can advertises the RBv's pseudo-nickname using the nickname 273 sub-TLV [rfc6326bis], along with its regular nickname(s), in its LSPs. 275 The communication protocol is an inter-chassis communication protocol 276 among RBridges in RBv to synchronize configuration and/or running 277 state data. The communication protocol should run over TRILL campus 278 to accommodate multi-hop interconnection among member RBridges in RBv. 280 To simplify configuration of pseudo-nickname, dynamic pseudo-nickname 281 allocation through communication protocol should be allowed. For LAG 282 multi-homed access scenario, as no Hello running on LAG member 283 ports RBv membership auto-discovery and pseudo-nickname dynamic 284 allocation are not achievable using the Hello based mechanism. Some 285 new method is required for such purpose. One of the potential 286 ways[TRILLPN] is to use the member communication protocol as follows. 288 As all member RBridges in RBv can exchange message through TRILL 289 campus although there is no HELLOs on LAG access port side, dynamic 290 pseudo-nickname allocation can be accomplished through communication 291 protocol over TRILL campus. The member RBridges in RBv select one RB 292 as DRB and let DRB assign pseudo-nickname dynamically. After pseudo- 293 nickname is allocated, each member RBridge in RBv can advertises the 294 RBv's pseudo-nickname in its LSPs. 296 3.2. CMT configuration and 297 state synchronization 299 CMT configuration should be synchronized between RBridges in RBv to 300 ensure different member RBridges assigned to different distribution 301 trees. If different RBridges in one RBv associate the same virtual 302 RBridge as their child in the same tree or trees, conflict occurs and 303 there should be a mechanism to remove the conflict. It is recommended 304 to send trap to NMS if conflict occurs. Network operator may manually 305 eliminate the conflict by modify configurations. Automatic mechanism 306 should also be provided to remove the conflict. After the conflict is 307 removed in local RBv, RBridges can advertise Affinity sub-TLVs to 308 trill campus. 310 If RBv membership changes when a member RBridges joins or leaves RBv, 311 each member RBridge in the RBv should do configuration consistency 312 check first. If no conflict is found or the conflict had been removed, 313 each member RBridge in the RBv recalculates the multi-destination 314 tree assignment and advertises the related trees using Affinity sub- 315 TLV. 317 For member RBridges node and link (all member link of LAG) failure, 318 other RBridges in the RBv should detect as soon as possible to 319 achieve fast failure recovery. Upon member RBridges node and link(all 320 member link of LAG) failure detection, other member RBridges in the 321 RBv will recalculate the multi-destination tree assignment and 322 advertise the related trees using Affinity sub-TLV. 324 So for CMT, communication protocol between member RBridges also 325 should be provided to achieve CMT configuration synchronization, 326 conflict elimination, node and link failure detection, and RBv 327 membership auto-discovery. Note that all these mechanisms SHOULD be 328 included in the CMT solution by itself. But they can also be provided 329 by the general communication channel for simplicity and robustness. 331 3.3. LACP configuration and 332 state synchronization 334 In IEEE802.1AX standard The Link Aggregation Control Protocol (LACP) 335 provides a standardized means for exchanging information between 336 Partner Systems on a link to allow their Link Aggregation Control 337 instances to reach agreement on the identity of the Link Aggregation 338 Group to which the link belongs, move the link to that Link 339 Aggregation Group, and enable its transmission and reception 340 functions in an orderly manner. The aggregated ports in one LAG are 341 located on one switch and cann't be located on two different switches 342 or chassis' in different locations. since IEEE802.1AX Link 343 Aggregation is only defined for a single system, the redundancy is 344 limited to a point to point connection between two devices and a 345 complete system failure on one end will bring down the LAG. 347 In the scenario that CE multi-homing to multiple RBridges in a edge 348 group link aggregation groups spanning two or multiple systems 349 should be provided. The standard as defined in IEEE802.1AX doesn't 350 provide for this. To support CE multi-homing with multi-chassis 351 Ethernet bundles, [802.1AX] LACP state should be synchronized or 352 shared between these systems. This ensures that the RBs can present a 353 single LACP bundle to the CE. This is required for initial system 354 bring-up and upon any configuration change. 356 Just similar to the description in [EVPN],at least the following LACP 357 specific configuration parameters should be synchronized amongst RBs 358 in RBv: 360 - System Identifier (MAC Address): uniquely identifies a LACP 362 speaker. 364 - System Priority: determines which LACP speaker's port 366 priorities are used in the Selection logic. 368 - Aggregator Identifier: uniquely identifies a bundle withina LACP 369 speaker. 371 - Aggregator MAC Address: identifies the MAC address of the 373 bundle. 375 - Aggregator Key: used to determine which ports can join an 377 Aggregator. 379 - Port Number: uniquely identifies an interface within a LACP 381 speaker. 383 - Port Key: determines the set of ports that can be bundled. 385 - Port Priority: determines a port's precedence level to join 387 a bundle in case the number of eligible ports exceeds the 389 maximum number of links allowed in a bundle. 391 Furthermore, the RBs should also synchronize operational (run-time) 393 data, in order for the LACP Selection logic state-machines to 395 execute. This operational data includes the following LACP 397 operational parameters, on a per port basis: 399 - Partner System Identifier: this is the CE System MAC address. 401 - Partner System Priority: the CE LACP System Priority 403 - Partner Port Number: CE's AC port number. 405 - Partner Port Priority: CE's AC Port Priority. 407 - Partner Key: CE's key for this AC. 409 - Partner State: CE's LACP State for the AC. 411 - Actor State: RB's LACP State for the AC. 413 - Port State: RB's AC port status. 415 The operational state needs to be communicated between RBs forming a 416 multi-chassis bundle during LACP initial bringup, upon any 417 configuration change and upon the occurrence of a failure. 419 If member RBridge of the virtual RBridge group has any node failure, 420 other RBridges of the group should invoke the Selection Logic and 421 select new SELECTED port. The failure detection timer is critical to 422 failure recovery performance. It is desired to achieve sub-second 423 detection of node failure (about 50 - 150 msec) in order to ensure 424 application SLA(service level agreement). 426 Upon detection of local link failure, RB1 in the RBv should notify 427 other RBs in the RBv immediately. Then other RBs in the RBv should 428 invoke the Selection Logic and select new SELECTED port as well. 429 Immediate notification of access-link state(up/down etc) changes 430 should also be provided to accomplish fast failure recovery. In other 431 words, the transmission of messages carrying link state of the LAG 432 should be on-demand rather than timer-based to minimize inter-chassis 433 state synchronization delay. 435 3.4. MAC table 436 synchronization 438 In active-active access scenario, virtual RBridge(RBv), along with 439 its pseudo-nickname(s), is introduced to address MAC flip-flopping on 440 remote RBridges. However, the RBv mechanism may cause new problems in 441 frame forwarding as described in [ESADI-EX]. For example, in Figure1 442 above native traffic from CE1 to CEx will enter a TRILL campus 443 through RB1 in an RBv, but the reverse traffic (i.e., traffic from 444 CEx to CE1) leaves the TRILL campus through RB2 in this RBv. Then RB1 445 loses the chance to learn where CEx is in data plane. If RB1 has no 446 other ways to get the location of CEx, it will have to always treat 447 the traffic from CE1 to CEx as unknown unicast traffic and flood it 448 to TRILL campus. Always flooding such traffic adds additional 449 forwarding burden on TRILL network. Thus, the learnt remote MAC 450 addresses SHOULD be shared among all member RBridges in an RBv. With 451 the shared information, RB1 can unicast traffic from CE1 to CEx 452 through the TRILL campus. 454 In addition to remote MAC addresses sharing, the local attached end 455 station MAC addresses should also be shared among all member RBridges 456 in an RBv. For example, native frames from CE1 to CEx will enter the 457 TRILL campus through one member RBridge of the RBv, such as RB1 in 458 Figure 1, so RB1 has CE1's MAC address; but with regard to traffic 459 returns from CEx to CE1, the traffic may be through RB2. If RB2 460 doesn't know the MAC address of ES1, it will always flood that to all 461 local access link. Always flooding such traffic consumes too much 462 link bandwidth and adds addition burden to local CEs. 464 To reduce flooding due to unknown unicast, MAC table that includes 465 local attached end station MAC addresses and remote MAC addresses 466 learnt from remote RBridges should be synchronized among all member 467 RBridges in an RBv. Communication protocol among member RBridges in 468 an RBv should be provided to satisfy the requirement. 470 3.5. Dynamic VLAN and 471 multicast group table 472 synchronization 474 To avoid duplicated frame from remote RBridges, VLAN and multicast 475 group based Designated Forwarder(DF) election [draft-hao-trill-dup- 476 avoidance-active-active-00] should be introduced for each MC-LAG, 477 only one RBridge in a edge group can forward the multicast traffic 478 from TRILL network to local CE. If VLANs is dynamically enabled 479 through VLAN registration protocol (VRP) (GVRP or MVRP), VLANs 480 enabled on for each MC-LAG should be synchronized among all RBridges 481 in a edge group. Similarly, If a CE dynamically joins a multicast 482 group through IGMP or MLD protocol, the multicast group should be 483 synchronized among all RBridges in a edge group. Each RBridge in a 484 edge group uses same algorithm to get consistent DF election result 485 per VLAN or per multicast group. 487 3.6. DHCP snooping table 488 synchronization 490 To harden the security on the LAN network, DHCP snooping feature is 491 normally enabled on edge RBs. With DHCP snooping, the physical 492 location of hosts can be tracked, only the IP addresses assigned for 493 the hosts can be used, only the authorized DHCP servers are 494 accessible. DHCP snooping can prevent attackers from adding their own 495 DHCP servers to the network. DHCP snooping allows only clients with 496 specific IP/MAC addresses to have access to the network. The 497 information tracked with DHCP snooping procedures should be 498 synchronized among edge RBs to ensure security. 500 4. Requirements for communication protocol in RBv 502 In summary, a communication protocol between member RBridges in RBv 503 should be provided to accomplish multi-homing access model. The 504 communication protocol is restricted to RBridge nodes in RBv edge 505 group and is used for configuration and state synchronization. It is 506 expected that LSP would not be used for this purpose since it may 507 cause campus wide fluctuation. Local behavior is preferred. After 508 member RBridges in RBv discover each other and establish connection 509 between each other, they can proceed with further state and 510 configuration synchronization which are addressed in the following 511 point. 513 The communication should accommodate multi-hop interconnection 514 between RBridges over TRILL campus. Because RBridges in RBv cann't 515 exchange information over access link of LAG, so RBridges in RBv 516 should exchange information over TRILL campus. The suggested control 517 channel for communication between member RBridges in RBv to exchange 518 state and configuration information is RBridge channel. Each member 519 RBridge establish connection to other RBridges of same RBv over 520 RBridge channel. This assumes that resiliency mechanisms are in place 521 to protect the route to the remote RBridge nodes, and hence loss of 522 TRILL data layer reachability to a given node can only mean that the 523 node itself has failed. 525 The communication protocol should satisfy the following requirements: 527 1. Support RBv membership static configuration and auto-discovery. A 528 mechanism that enables RB nodes to manage their RBv Membership 529 should be defined. RBv membership auto-discovery can simplify 530 configuration of RBv. After member RBridges in RBv discover each 531 other and establish connection between each other, the state and 532 configuration can be synchronized among them which are discussed 533 in the following point. 535 2. Support consistency check for static pseudo-nickname configuration 536 consistency. The pseudo-nickname configured on each member 537 RBridges in RBv should be same. If conflict exists, It is 538 recommended to send trap to NMS and let operator modify 539 configuration to eliminate conflict. Only when the conflict is 540 removed, each member RBridge in RBv can advertises the RBv's 541 pseudo-nickname in its LSPs. 543 3. Support dynamic pseudo-nickname allocation. To simplify 544 configuration of pseudo-nickname, dynamic pseudo-nickname 545 allocation through communication protocol should be allowed. After 546 pseudo-nickname is allocated, each member RBridge in RBv can 547 advertises the RBv's pseudo-nickname in its LSPs. 549 4. Support CMT configuration synchronization and conflict elimination. 550 CMT configuration should be synchronized in RBv to ensure 551 different member RBridges are assigned different distribution 552 trees. If conflict occurs, i.e. one tree is used by more than one 553 members, It is recommended to send trap to NMS. Conflict 554 elimination can rely on operator or automatic mechanism. After the 555 conflict is removed in local RBv, RBridges advertise Affinity 556 sub-TLVs to trill campus. 558 5. Support fast node failure detection. Upon detection other member 559 RBridges node failure, RBridges in RBv should invoke LACP re- 560 selection Logic and CMT re-calculation algorithm. 562 The communication protocol can either define its own keepAlive 563 mechanism for purpose of node failure detection or reuse existing 564 fault detection mechanisms. BFD over TRILL and TRILL OAM for RB 565 reachability monitoring are existing fault detection mechanisms 566 and may be used to detect RBridges node failure. 568 6. Support fast link failure detection. When a member RBridge in RBv 569 detects a failure of its access link, it should send an link 570 failure notification message immediately to inform other member 571 RBridges. Other member RBridges in RBv should invoke LACP re- 572 selection Logic and CMT re-calculation algorithm similar to node 573 failure process. 574 7. Support LACP configuration and state synchronization. To support 575 CE multi-homing with multi-chassis Ethernet bundles, LACP state 576 should be synchronized or shared between these systems. For CE 577 device, all RBridges in virtual RBridge group simulate one LACP 578 end system and perform same LACP selection logic. Member RBridges 579 in RBv can use RBridge channel as control channel to exchange LACP 580 configuration and state synchronization between each other. 582 8. Support MAC table synchronization. To reduce flooding due to 583 unknown unicast, communication protocol between member RBridges 584 should be provided to synchronize MAC table among all member 585 RBridges in an RBv. 587 9. Support Dynamic VLAN and multicast group table synchronization. 588 Dynamically joined VLANs and multicast groups on a edge RB should 589 be synchronized to other RBridges in a edge group. 591 10.Support DHCP snooping table synchronization. The information 592 tracked with DHCP snooping procedures on each edge RBridge should 593 be synchronized to other edge RBs in a edge group to ensure 594 security. 596 Additional requirements considerations such as flow-control, reliable 597 and in-order message delivery, and etc are being discussed. 599 5. Security Considerations 601 This document does not change the general TRILL security 602 considerations of the TRILL base protocol. 604 In the scenario where the members of an RBv are located in different 605 physical locations and connected over TRILL campus, transport 606 security between devices in an RBv should be provided with secure 607 authentication mechanism built into the communication protocol. 609 6. IANA Considerations 611 If RBridge channel is used for control channel of communication 612 protocol in RBv, then IANA is requested to allocate the new RBridge 613 channel protocol codes. 615 7. References 617 7.1. Normative References 619 [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 621 Ghanwani, "Routing Bridges (RBridges): Base Protocol 623 Specification", RFC 6325, July 2011. 625 [RFC6326] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. 627 Ghanwani, "TRILL Use of IS-IS", RFC 6326, July 2011. 629 [6326bis] Eastlake, D. et.al., ''Transparent Interconnection of Lots 631 of Links (TRILL) Use of IS-IS'', draft-eastlake-isisrfc6326bis- 633 07.txt, Work in Progress, December 2011. 635 [RFC6439] Eastlake, D. et.al., ''RBridge: Appointed Forwarder'', RFC 637 6439, November 2011. 639 [TRILLChannel] - Eastlake, D., V. Manral, Y. Li, S. Aldrin, D. Ward, 641 "RBridges: RBridge Channel Support in TRILL", draft-ietftrill- 643 rbridge-channel, work in progress. 645 [RFC6327] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., 647 and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 649 6327, July 2011 651 [TRILLPN] Zhai,H., et.al ''RBridge: Pseudonode Nickname'', draft-hu- 652 trill-pseudonode-nickname, Work in progress, November 2011. 654 [TRILL-CMT] " Coordinated Multicast Trees (CMT) for TRILL ", draft- 655 ietf-trill-cmt-01, November 2012. 657 [8021AX] IEEE, ''Link Aggregration'', 802.1AX-2008, 2008. 659 [EVPN] " BGP MPLS Based Ethernet VPN ", draft-ietf-l2vpn-evpn-02, 660 October 2012. 662 [ESADI-EX] Zhai,H., et.al '' RBridge: ESADI-Extension'', draft-zhai- 663 trill-esadi-extension-for-rbv-00, Work in progress, October 2012. 665 7.2. Informative References 667 [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 669 Systems", RFC 6165, April 2011. 671 [802.1D] "IEEE Standard for Local and metropolitan area networks 673 /Media Access Control (MAC) Bridges", 802.1D-2004, 9 June 675 2004. 677 8. Acknowledgments 679 The authors wish to acknowledge the important contributions of 680 Changbao Liu, Donald EastLake, Mingui Zhang. 682 Authors' Addresses 684 Weiguo Hao 685 Huawei Technologies 686 101 Software Avenue, 687 Nanjing 210012 688 China 689 Phone: +86-25-56623144 690 Email: haoweiguo@huawei.com 692 Yizhou Li 693 Huawei Technologies 694 101 Software Avenue, 695 Nanjing 210012 696 China 697 Phone: +86-25-56625375 698 Email: liyizhou@huawei.com 700 Liang Xia(Frank) 701 Huawei Technologies 702 101 Software Avenue, 703 Nanjing 210012 704 China 705 Phone: +86-25-56624539 706 Email: frank.xialiang@huawei.com 708 Hongjun Zhai 709 ZTE Corporation 710 68 Zijinghua Road, Yuhuatai District 711 Nanjing, Jiangsu 210012 712 China 713 Email: zhai.hongjun@zte.com.cn