TRILL Weiguo Hao Yizhou Li Internet Draft Huawei Technologies HJ. Zhai ZTE Corporation Intended status: Standards Track February 12, 2014 Expires: August 2014 The problem statement of RBridge edge group state synchronization draft-hao-trill-rb-syn-02.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any Hao & Li Expires August 11, 2014 [Page 1] Internet-Draft problem statement of RBridge edge group January 2013 time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on August 11, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract In TRILL multi-homing scenario, the concept of virtual RBridge in [TRILLPN], was introduced to address the MAC flip-flopping problem at remote RBridges. Based on virtual RBridge mechanism, Coordinated Multicast Trees (CMT) solution in [CMT] was introduced to solve the related RPF issues. In this document, additional problems are described regarding virtual Bridges members' state synchronization in multi-homing scenario, including virtual RBridge membership auto discovery, pseudo-nickname static configuration consistency check, dynamic pseudo-nickname allocation, CMT configuration synchronization ,LACP configuration and state synchronization, node/link failure detection, MAC table synchronization, DHCP snooping information, and dynamically joined VLANs and multicast groups. To Hao & Li Expires August 12, 2014 [Page 2] Internet-Draft problem statement of RBridge edge group January 2013 address these problems, a communication protocol among members of a virtual RBridge group should be provided. Requirements for this protocol is also discussed. Table of Contents 1. Introduction ................................................ 3 2. Conventions used in this document............................ 5 3. Problem Statement ........................................... 6 3.1. RBv membership configuration and state synchronization...6 3.2. CMT configuration and state synchronization .............7 3.3. LACP configuration and state synchronization ............8 3.4. MAC table synchronization.............................. 10 3.5. Dynamic VLAN and multicast group table synchronization..11 3.6. DHCP snooping table synchronization ....................11 4. Requirements for communication protocol in RBv ..............11 5. Security Considerations..................................... 14 6. IANA Considerations ........................................ 14 7. References ................................................. 14 7.1. Normative References................................... 14 7.2. Informative References................................. 15 8. Acknowledgments ............................................ 15 1. Introduction TRILL (Transparent Interconnection of Lots of Links) presented in[RFC6325] and other related documents, provides methods of utilizing all available paths for active forwarding with minimum configuration. TRILL utilizes IS-IS (Intermediate System to Intermediate System) as its control plane and encapsulates native frames with a TRILL header. +------+ | CEx | +------+ | +------+ |(RBx) | +------+ | Hao & Li Expires August 12, 2014 [Page 3] Internet-Draft problem statement of RBridge edge group January 2013 ------------------- / \ | | | TRILL Campus | | | \ / -------------------- | | | -------- | -------- | | | +------+ +------+ +------+ |(RB1) | |(RB2) | | (RBk)| +------+ +------+ +------+ | | | | | ___________| |______ | | |LAG1 LAG2 | | +------+ +------+ | CE1 | | CE2 | +------+ +------+ Figure 1 Reference Topology In order to improve the reliability of connection to TRILL network , CE devices typically are multi-homed to edge RBridges and treat all of the uplinks as a single Link Aggregation (LAG) bundle [802.1AX] in the scenario shown by Figure 1. In this scenario, When remote RBridge RBx receives a frame originated by CE1, the ingress RBridge maybe either one of the edge RBridges i.e. RB1 or RB2. The learning on RBx for source MAC will flip-flop between RB1's and RB2's nicknames. In [TRILLPN], the concept of Virtual RBridge, along with its pseudo- nickname, is introduced to address the MAC flip-flopping problem in remote RBridges. A Virtual RBridge (RBv) represents a group of different ports on different edge RBridges, on which these RBridges provide end-station service to a set of their attached CE devices. After joining RBv, such an RBridge port is called a member port of RBv, and such an RBridge becomes a member RBridge of RBv. In an RBridge RBv is identified by its virtual nickname in TRILL campus, and virtual nickname is also referred to as pseudo-nickname in this specification. Hao & Li Expires August 12, 2014 [Page 4] Internet-Draft problem statement of RBridge edge group January 2013 An RBridge port can join at most one RBv at any time, but different ports on the same RBridge can join the same RBv or different RBvs. After joining an RBv, such a port becomes a member port of the RBv, and the RBridge becomes a member RBridge of the RBv. Furthermore, for a member RBridge, it MUST move out of RBv and clear the RBv's information from its self-originated LSPs when it loses the last member port from this group, due to port down, configuration, and etc. Based on the concept of Virtual RBridge and pseudo-nickname, Coordinated Multicast Trees (CMT) [CMT] solution was introduced to solve the related RPF issues. In CMT solution, different member RBridges are assigned different distribution trees for forwarding the multi-destination TRILL data frames that using RBv's pseudo-nickname as ingress nickname in their TRILL header. When a member RBridge joins into or leaves from a virtual RBridge group RBv due to its last member ports up/down or its configuration changing, the distribution trees assigned to different member RBridges may change. For TRILL multi-homing scenario, pseudo-nickname and CMT is not sufficient to provide a complete solution. Additional problems such as RBv membership management, LACP configuration and state synchronization, node and access link failure detection, and etc still exist. This draft is going to talk about those problem in more details. 2. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. In this document, the characters ">>" preceding an indented line(s) indicates a compliance requirement statement using the key words listed above. This convention aids reviewers in quickly identifying or finding the explicit compliance requirements of this RFC. Hao & Li Expires August 12, 2014 [Page 5] Internet-Draft problem statement of RBridge edge group January 2013 TRILL: Transparent Interconnection of Lots of Links. TRILL presented in [RFC6325] and other related documents, provides methods of utilizing all available paths for active forwarding, with minimum configuration. TRILL utilizes IS-IS (Intermediate System to Intermediate System) as its control plane and encapsulates native frames with a TRILL header. CE: Classical Ethernet device, that is a device that performs forwarding based on 802.1Q bridging. This also can be end-station or a server. CMT: Coordinated Multicast Trees. LACP: Link Aggregation Control Protocol. LAG: Link Aggregation, as specified in [8021AX]. RB: Router Bridge. RBs are a switch that implements the TRILL protocol and combine the advantages of bridges and routers. 3. Problem Statement For TRILL multi-homing scenario, the following problems should be addressed: 3.1. RBv membership configuration and state synchronization A Virtual RBridge (RBv) is identified by its virtual nickname referred as pseudo-nickname in [PSEUDO-NICK]. RBv must allow static member configuration by network operator. If each member of RBv statically configures its RBridge ports with a pseudo-nickname, the pseudo-nickname should be consistent among all member RBridges in RBv. Communication protocol between member RBridges should be provided to ensure pseudo-nickname configuration consistency in RBv. Member RBridges in RBv should notify each other to find if conflict of pseudo-nickname configuration exists when pseudo-nickname is configured. If conflict exists, It is recommended to send trap to network management system (NMS) and let operator modify configuration to eliminate conflict. Only when the conflict is removed, each member RBridge can advertises the RBv's pseudo-nickname using the nickname sub-TLV [rfc6326bis], along with its regular nickname(s), in its LSPs. Hao & Li Expires August 12, 2014 [Page 6] Internet-Draft problem statement of RBridge edge group January 2013 The communication protocol is an inter-chassis communication protocol among RBridges in RBv to synchronize configuration and/or running state data. The communication protocol should run over TRILL campus to accommodate multi-hop interconnection among member RBridges in RBv. To simplify configuration of pseudo-nickname, dynamic pseudo-nickname allocation through communication protocol should be allowed. For TRILL VLAN-x Appointed Forwarder, TRILL Hello protocol specified in [RFC6325] is used for DRB election and for VLAN-x AFs appointment on those ports. Pseudo-nickname can be dynamic allocated by DRB and be notified to other member RBs through TRILL Hello. For LAG multi-homed access scenario, as no Hello running on LAG member ports RBv membership auto-discovery and pseudo-nickname dynamic allocation are not achievable using the Hello based mechanism. Some new method is required for such purpose. One of the potential ways is to use the member communication protocol as follows. As all member RBridges in RBv can exchange message through TRILL campus although there is no HELLOs on LAG access port side, dynamic pseudo-nickname allocation can be accomplished through communication protocol over TRILL campus. The member RBridges in RBv select one RB as DRB and let DRB assign pseudo-nickname dynamically. After pseudo- nickname is allocated, each member RBridge in RBv can advertises the RBv's pseudo-nickname in its LSPs. 3.2. CMT configuration and state synchronization CMT configuration should be synchronized between RBridges in RBv to ensure different member RBridges assigned to different distribution trees. If different RBridges in one RBv associate the same virtual RBridge as their child in the same tree or trees, conflict occurs and there should be a mechanism to remove the conflict. It is recommended to send trap to NMS if conflict occurs. Network operator may manually eliminate the conflict by modify configurations. Automatic mechanism should also be provided to remove the conflict. After the conflict is removed in local RBv, RBridges can advertise Affinity sub-TLVs to trill campus. If RBv membership changes when a member RBridges joins or leaves RBv, each member RBridge in the RBv should do configuration consistency check first. If no conflict is found or the conflict had been removed, each member RBridge in the RBv recalculates the multi-destination tree assignment and advertises the related trees using Affinity sub- TLV. Hao & Li Expires August 12, 2014 [Page 7] Internet-Draft problem statement of RBridge edge group January 2013 For member RBridges node and link (all member link of LAG) failure, other RBridges in the RBv should detect as soon as possible to achieve fast failure recovery. Upon member RBridges node and link(all member link of LAG) failure detection, other member RBridges in the RBv will recalculate the multi-destination tree assignment and advertise the related trees using Affinity sub-TLV. So for CMT, communication protocol between member RBridges also should be provided to achieve CMT configuration synchronization, conflict elimination, node and link failure detection, and RBv membership auto-discovery. 3.3. LACP configuration and state synchronization In IEEE802.1AX?standard The Link Aggregation Control Protocol (LACP) provides a standardized means for exchanging information between Partner Systems on a link to allow their Link Aggregation Control instances to reach agreement on the identity of the Link Aggregation Group to which the link belongs, move the link to that Link Aggregation Group, and enable its transmission and reception functions in an orderly manner. The aggregated ports in one LAG are located on one switch and cann't be located on two different switches or chassis' in different locations. since IEEE802.1AX?Link Aggregation is only defined for a single system, the redundancy is limited to a point to point connection between two devices and a complete system failure on one end will bring down the LAG. In the scenario that CE multi-homing to multiple RBridges in a edge group link aggregation groups spanning two or multiple systems should be provided. The standard as defined in IEEE802.1AX?doesn't provide for this. To support CE multi-homing with multi-chassis Ethernet bundles, [802.1AX] LACP state should be synchronized or shared between these systems. This ensures that the RBs can present a single LACP bundle to the CE. This is required for initial system bring-up and upon any configuration change. Just similar to the description in [EVPN],at least the following LACP specific configuration parameters should be synchronized amongst RBs in RBv: - System Identifier (MAC Address): uniquely identifies a LACP speaker. - System Priority: determines which LACP speaker's port Hao & Li Expires August 12, 2014 [Page 8] Internet-Draft problem statement of RBridge edge group January 2013 priorities are used in the Selection logic. - Aggregator Identifier: uniquely identifies a bundle withina LACP speaker. - Aggregator MAC Address: identifies the MAC address of the bundle. - Aggregator Key: used to determine which ports can join an Aggregator. - Port Number: uniquely identifies an interface within a LACP speaker. - Port Key: determines the set of ports that can be bundled. - Port Priority: determines a port's precedence level to join a bundle in case the number of eligible ports exceeds the maximum number of links allowed in a bundle. Furthermore, the RBs should also synchronize operational (run-time) data, in order for the LACP Selection logic state-machines to execute. This operational data includes the following LACP operational parameters, on a per port basis: - Partner System Identifier: this is the CE System MAC address. - Partner System Priority: the CE LACP System Priority - Partner Port Number: CE's AC port number. - Partner Port Priority: CE's AC Port Priority. - Partner Key: CE's key for this AC. - Partner State: CE's LACP State for the AC. - Actor State: RB's LACP State for the AC. Hao & Li Expires August 12, 2014 [Page 9] Internet-Draft problem statement of RBridge edge group January 2013 - Port State: RB's AC port status. The operational state needs to be communicated between RBs forming a multi-chassis bundle during LACP initial bringup, upon any configuration change and upon the occurrence of a failure. If member RBridge of the virtual RBridge group has any node failure, other RBridges of the group should invoke the Selection Logic and select new SELECTED port. The failure detection timer is critical to failure recovery performance. It is desired to achieve sub-second detection of node failure (~ 50 - 150 msec) in order to ensure application SLA(service level agreement). Upon detection of local link failure, RB1 in the RBv should notify other RBs in the RBv immediately. Then other RBs in the RBv should invoke the Selection Logic and select new SELECTED port as well. Immediate notification of access-link state(up/down etc) changes should also be provided to accomplish fast failure recovery. In other words, the transmission of messages carrying link state of the LAG should be on-demand rather than timer-based to minimize inter-chassis state synchronization delay. 3.4. MAC table synchronization In active-active access scenario, virtual RBridge(RBv), along with its pseudo-nickname(s), is introduced to address MAC flip-flopping on remote RBridges. However, the RBv mechanism may cause new problems in frame forwarding as described in [ESADI-EX]. For example, in Figure1 above native traffic from CE1 to CEx will enter a TRILL campus through RB1 in an RBv, but the reverse traffic (i.e., traffic from CEx to CE1) leaves the TRILL campus through RB2 in this RBv. Then RB1 loses the chance to learn where CEx is in data plane. If RB1 has no other ways to get the location of CEx, it will have to always treat the traffic from CE1 to CEx as unknown unicast traffic and flood it to TRILL campus. Always flooding such traffic adds additional forwarding burden on TRILL network. Thus, the learnt remote MAC addresses SHOULD be shared among all member RBridges in an RBv. With the shared information, RB1 can unicast traffic from CE1 to CEx through the TRILL campus. In addition to remote MAC addresses sharing, the local attached end station MAC addresses should also be shared among all member RBridges in an RBv. For example, native frames from CE1 to CEx will enter the TRILL campus through one member RBridge of the RBv, such as RB1 in Figure 1, so RB1 has CE1's MAC address; but with regard to traffic returns from CEx to CE1, the traffic may be through RB2. If RB2 Hao & Li Expires August 12, 2014 [Page 10] Internet-Draft problem statement of RBridge edge group January 2013 doesn't know the MAC address of ES1, it will always flood that to all local access link. Always flooding such traffic consumes too much link bandwidth and adds addition burden to local CEs. To reduce flooding due to unknown unicast, MAC table that includes local attached end station MAC addresses and remote MAC addresses learnt from remote RBridges should be synchronized among all member RBridges in an RBv. Communication protocol among member RBridges in an RBv should be provided to satisfy the requirement. 3.5. Dynamic VLAN and multicast group table synchronization To avoid duplicated frame from remote RBridges, VLAN and multicast group based Designated Forwarder(DF) election [draft-hao-trill-dup- avoidance-active-active-00] should be introduced for each MC-LAG, only one RBridge in a edge group can forward the multicast traffic from TRILL network to local CE. If VLANs is dynamically enabled through VLAN registration protocol (VRP) (GVRP or MVRP), VLANs enabled on for each MC-LAG should be synchronized among all RBridges in a edge group. Similarly, If a CE dynamically joins a multicast group through IGMP or MLD protocol, the multicast group should be synchronized among all RBridges in a edge group. Each RBridge in a edge group uses same algorithm to get consistent DF election result per VLAN or per multicast group. 3.6. DHCP snooping table synchronization To harden the security on the LAN network, DHCP snooping feature is normally enabled on edge RBs. With DHCP snooping, the physical location of hosts can be tracked, only the IP addresses assigned for the hosts can be used, only the authorized DHCP servers are accessible. DHCP snooping can prevent attackers from adding their own DHCP servers to the network. DHCP snooping allows only clients with specific IP/MAC addresses to have access to the network. The information tracked with DHCP snooping procedures should be synchronized among edge RBs to ensure security. 4. Requirements for communication protocol in RBv In summary, a communication protocol between member RBridges in RBv should be provided to accomplish multi-homing access model. The communication protocol is restricted to RBridge nodes in RBv edge group and is used for configuration and state synchronization. It is expected that LSP would not be used for this purpose since it may Hao & Li Expires August 12, 2014 [Page 11] Internet-Draft problem statement of RBridge edge group January 2013 cause campus wide fluctuation. Local behavior is preferred. After member RBridges in RBv discover each other and establish connection between each other, they can proceed with further state and configuration synchronization which are addressed in the following point. The communication should accommodate multi-hop interconnection between RBridges over TRILL campus. Because RBridges in RBv cann't exchange information over access link of LAG, so RBridges in RBv should exchange information over TRILL campus. The suggested control channel for communication between member RBridges in RBv to exchange state and configuration information is RBridge channel. Each member RBridge establish connection to other RBridges of same RBv over RBridge channel. This assumes that resiliency mechanisms are in place to protect the route to the remote RBridge nodes, and hence loss of TRILL data layer reachability to a given node can only mean that the node itself has failed. The communication protocol should satisfy the following requirements: 1. Support RBv membership static configuration and auto-discovery. A mechanism that enables RB nodes to manage their RBv Membership should be defined. RBv membership auto-discovery can simplify configuration of RBv. After member RBridges in RBv discover each other and establish connection between each other, the state and configuration can be synchronized among them which are discussed in the following point. 2. Support consistency check for static pseudo-nickname configuration consistency. The pseudo-nickname configured on each member RBridges in RBv should be same. If conflict exists, It is recommended to send trap to NMS and let operator modify configuration to eliminate conflict. Only when the conflict is removed, each member RBridge in RBv can advertises the RBv's pseudo-nickname in its LSPs. 3. Support dynamic pseudo-nickname allocation. To simplify configuration of pseudo-nickname, dynamic pseudo-nickname allocation through communication protocol should be allowed. After pseudo-nickname is allocated, each member RBridge in RBv can advertises the RBv's pseudo-nickname in its LSPs. Hao & Li Expires August 12, 2014 [Page 12] Internet-Draft problem statement of RBridge edge group January 2013 4. Support CMT configuration synchronization and conflict elimination. CMT configuration should be synchronized in RBv to ensure different member RBridges are assigned different distribution trees. If conflict occurs, i.e. one tree is used by more than one members, It is recommended to send trap to NMS. Conflict elimination can rely on operator or automatic mechanism. After the conflict is removed in local RBv, RBridges advertise Affinity sub-TLVs to trill campus. 5. Support fast node failure detection. Upon detection other member RBridges node failure, RBridges in RBv should invoke LACP re- selection Logic and CMT re-calculation algorithm. The communication protocol can either define its own keepAlive mechanism for purpose of node failure detection or reuse existing fault detection mechanisms. BFD over TRILL and TRILL OAM for RB reachability monitoring are existing fault detection mechanisms and may be used to detect RBridges node failure. 6. Support fast link failure detection. When a member RBridge in RBv detects a failure of its access link, it should send an link failure notification message immediately to inform other member RBridges. Other member RBridges in RBv should invoke LACP re- selection Logic and CMT re-calculation algorithm similar to node failure process. 7. Support LACP configuration and state synchronization. To support CE multi-homing with multi-chassis Ethernet bundles, LACP state should be synchronized or shared between these systems. For CE device, all RBridges in virtual RBridge group simulate one LACP end system and perform same LACP selection logic. Member RBridges in RBv can use RBridge channel as control channel to exchange LACP configuration and state synchronization between each other. 8. Support MAC table synchronization. To reduce flooding due to unknown unicast, communication protocol between member RBridges should be provided to synchronize MAC table among all member RBridges in an RBv. 9. Support Dynamic VLAN and multicast group table synchronization. Dynamically joined VLANs and multicast groups on a edge RB should be synchronized to other RBridges in a edge group. Hao & Li Expires August 12, 2014 [Page 13] Internet-Draft problem statement of RBridge edge group January 2013 10.Support DHCP snooping table synchronization. The information tracked with DHCP snooping procedures on each edge RBridge should be synchronized to other edge RBs in a edge group to ensure security. Additional requirements considerations such as flow-control, reliable and in-order message delivery, and etc are being discussed. 5. Security Considerations This document does not change the general TRILL security considerations of the TRILL base protocol. In the scenario where the members of an RBv are located in different physical locations and connected over TRILL campus, transport security between devices in an RBv should be provided with secure authentication mechanism built into the communication protocol. 6. IANA Considerations If RBridge channel is used for control channel of communication protocol in RBv, then IANA is requested to allocate the new RBridge channel protocol codes. 7. References 7.1. Normative References [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011. [RFC6326] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. Ghanwani, "TRILL Use of IS-IS", RFC 6326, July 2011. [6326bis] Eastlake, D. et.al., ''Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS'', draft-eastlake-isisrfc6326bis- 07.txt, Work in Progress, December 2011. [RFC6439] Eastlake, D. et.al., ''RBridge: Appointed Forwarder'', RFC 6439, November 2011. Hao & Li Expires August 12, 2014 [Page 14] Internet-Draft problem statement of RBridge edge group January 2013 [TRILLChannel] - Eastlake, D., V. Manral, Y. Li, S. Aldrin, D. Ward, "RBridges: RBridge Channel Support in TRILL", draft-ietftrill- rbridge-channel, work in progress. [RFC6327] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 6327, July 2011 [TRILLPN] Zhai,H., et.al ''RBridge: Pseudonode Nickname'', draft-hu- trill-pseudonode-nickname, Work in progress, November 2011. [TRILL-CMT] " Coordinated Multicast Trees (CMT) for TRILL ", draft- ietf-trill-cmt-01, November 2012. [8021AX] IEEE, ''Link Aggregration'', 802.1AX-2008, 2008. [EVPN] " BGP MPLS Based Ethernet VPN ", draft-ietf-l2vpn-evpn-02, October 2012. [ESADI-EX] Zhai,H., et.al '' RBridge: ESADI-Extension'', draft-zhai- trill-esadi-extension-for-rbv-00, Work in progress, October 2012. 7.2. Informative References [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, April 2011. [802.1D] "IEEE Standard for Local and metropolitan area networks /Media Access Control (MAC) Bridges", 802.1D-2004, 9 June 2004. 8. Acknowledgments The authors wish to acknowledge the important contributions of Changbao Liu, Donald EastLake, Mingui Zhang. Authors' Addresses Weiguo Hao Hao & Li Expires August 12, 2014 [Page 15] Internet-Draft problem statement of RBridge edge group January 2013 Huawei Technologies 101 Software Avenue, Nanjing 210012 China Phone: +86-25-56623144 Email: haoweiguo@huawei.com Yizhou Li Huawei Technologies 101 Software Avenue, Nanjing 210012 China Phone: +86-25-56625375 Email: liyizhou@huawei.com Hongjun Zhai ZTE Corporation 68 Zijinghua Road, Yuhuatai District Nanjing, Jiangsu 210012 China Email: zhai.hongjun@zte.com.cn Hao & Li Expires August 12, 2014 [Page 16]