Network Working Group P. Kwok Internet-Draft P. Dutta Intended status: Standards Track Alcatel-Lucent Expires: October 2, 2013 March 31, 2013 MAC Flush Loop Detection in VPLS draft-ietf-l2vpn-vpls-macflush-ld-03 Abstract MAC Address Withdrawal is a mechanism described in [RFC4762] to remove or unlearn MAC addresses that have been dynamically learned in a VPLS instance, for faster convergence on topology change. Failure of mechanisms that control loop free connectivity among VPLS PE-rs nodes may cause MAC Address Withdrawal messages looping among those nodes, leading to Denial of Service (DoS) or complete failure of control plane in the PE-rs nodes. This document describes a mechanism to detect and prevent loops of MAC Address Withdrawal messages in a VPLS PE-rs node on such failures. Requirements Language 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]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 7, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Kwok & Dutta Expires October 2, 2013 [Page 1] Internet-Draft MAC Flush Loop Detection March 2013 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3.1. MTU-s Initiated MAC Flush . . . . . . . . . . . . . . . . 6 3.1.1. MAC Flush Loop Due to Misconfiguration . . . . . . . . 7 3.2. PE-rs Initiated MAC Flush . . . . . . . . . . . . . . . . 10 4. Loop Detection in MAC Flush . . . . . . . . . . . . . . . . . 10 4.1. Loop Detection Procedure in MAC Flush Message . . . . . . 11 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Major Contributing Authors . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Kwok & Dutta Expires October 2, 2013 [Page 2] Internet-Draft MAC Flush Loop Detection March 2013 1. Introduction A method of Virtual Private LAN Service (VPLS) is described in [RFC4762]. A full mesh of Pseudowire (PW)s is established between PE-rs (Provider Edge - Routing and Switching Capable) nodes to construct the VPLS core. The mesh topology provides a LAN segment or broadcast domain that is fully capable of learning and forwarding based on Ethernet MAC addresses at the PE-rs nodes. Since every PE-rs node is now directly connected to every other PE-rs nodes in the core via a PW, the topology forms a loop in data plane. A simple loop breaking rule is used - the "spilt horizon" rule described in section 4.4 in [RFC4762], whereby a PE-rs node does not forward traffic from one PW to another in the same VPLS mesh. Various mechanisms used to enforce split-horizon rule in the VPLS full mesh are out of scope of this document. For scalability, this VPLS full mesh core configuration can be augmented with additional non-meshed spoke or MTU-s (Multi-Tenant Unit - Switching Capable) [RFC4762] nodes to provide a Hierarchical VPLS (H-VPLS) service [RFC4762]. "Spoke" PW connecting the MTU-s node and "hosting" PE-rs node can forward traffic to and receive traffic from a "Mesh" PW in the VPLS core. To protect from connection failure of the spoke PW or the hosting PE-rs node, the MTU-s node may be dual-homed into two PE-rs nodes in the same VPLS instance (see Figure 1). The dual homed connectivity also forms a loop that requires a loop breaking mechanism. The various loop breaking mechanisms used in H-VPLS dual homing are out of scope of this document. MAC Address Withdrawal [RFC4762] is required to remove or unlearn MAC addresses for faster convergence on topology change in H-VPLS (e.g., failure of the primary spoke PW for a dual-homed MTU-s). In this document the term "MAC Flush Message" means the LDP Address Withdraw Message MAC List TLV used for MAC Address Withdrawal in VPLS. Lack of of mechanisms or failure of mechanisms that control data plane loop free connectivity among VPLS PE-rs nodes may also cause loops of MAC Flush Messages in the LDP control plane among the participating PE-rs nodes. Such looping of MAC Flush Messages may is similar to denial of service (DoS) attacks which may lead to complete failure of the control plane in the node(s). This document describes the looping problem with MAC Flush Messages and defines a mechanism to detect and prevent such loops in the LDP control plane. Note misconfiguration in VPLS networks may cause loops and broadcast storms in traffic forwarding as well. Data path loop detection and prevention is outside the scope of this document. Implementations may deploy methodologies available in native service forwarding to Kwok & Dutta Expires October 2, 2013 [Page 3] Internet-Draft MAC Flush Loop Detection March 2013 detect and prevent such loops in data path. The control plane may not necessarily benefit from these capabilities since the control messages are handled differently at each hop. 2. Terminology This document uses the terminology defined in [RFC5036] and [RFC4762]. Throughout this document VPLS means the emulated bridged LAN service offered to a customer. H-VPLS means the hierarchical Connectivity or layout of MTU-s and PE devices offering the VPLS [RFC4762]. The terms spoke node and MTU-s in H-VPLS are used interchangeably. "Spoke PW" means the PW that provides connectivity between MTU-s and PE-rs nodes. "Mesh PW" means the PW that provides connectivity between PE-rs nodes in a VPLS full mesh core. "MAC Flush Message" means LDP Address Withdraw Message with MAC List TLV with MAC List TLV. MAC Flush Message in the "context of a PW" means the Message that has been received over the LDP session that is used to set up the PW used to provide connectivity in VPLS. The MAC Flush Message carries the context of the PW in terms on FEC TLV associated with the PW [RFC4762][RFC4447]. In general, "MAC Flush" means the method of initiating and processing of MAC Flush Messages across a VPLS instance. 3. Problem Statement This section describes MAC Flush Loop in the LDP control plane. Kwok & Dutta Expires October 2, 2013 [Page 4] Internet-Draft MAC Flush Loop Detection March 2013 PE1-rs PE3-rs +--------+ +--------+ | | | | | -- | | -- | Customer Site 1 | / \ |---------------| / \ |..-> Z X->CE-1 /-----| \ s/ | | \S / | \ primary spoke PW | -- | /---| -- | \ / +--------+ / +--------+ \ (MTU-s) / | \ / | +--------+/ | \ / | | | | \ / | | -- | | \ / | | / \ | | H-VPLS Full Mesh Core| | \S / | | / \ | | -- | | / \ | /+--------+\ | / \ | / backup spoke PW | / \ | / \ +--------+ \-----+--------+ Y->CE-2 \ | | | | Customer Site 2 \------| -- | | -- | | / \ |---------------| / \ |..-> | \s / | | \S / | | -- | | -- | +--------+ +--------+ PE2-rs PE4-rs Figure 1: Dual homed MTU-s in two tier hierarchy H-VPLS An example of usage of the MAC Flush mechanism is the dual-homed H-VPLS where an edge node termed as MTU-s is connected to two hosting PE-rs nodes via primary spoke PW and backup spoke PW respectively (see Figure 1). This model is described in [RFC4762]. Such redundancy is designed to protect against the failure of primary spoke PW or hosting primary PE-rs node. There could be multiple methods of dual homing in H-VPLS that are not described in [RFC4762]. For example, note the following statement from section 10.2.1 in [RFC4762]: "How a spoke is designated primary or secondary is outside the scope of this document. For example, a spanning tree instance running between only the MTU-s and the two PE-rs nodes is one possible method. Another method could be configuration". When the MTU-s switches over to the backup PW (activates the backup PW), it is required to flush the MAC addresses learned in the corresponding VSI (Virtual Switch Instance) in all PE-rs devices participating in full mesh, to avoid black holing of frames to those Kwok & Dutta Expires October 2, 2013 [Page 5] Internet-Draft MAC Flush Loop Detection March 2013 addresses. In Figure 1, the MTU-s is dual-homed to PE1-rs and PE2-rs. Only the primary spoke PW is active at MTU-s, thus PE1-rs is acting as the active device (designated forwarder) to reach the full mesh in the VPLS instance. The MAC addresses of nodes located at access sites (behind CE1 and CE2) are learned at PE1-rs over the primary spoke PW. Let's say X represents a set of such MAC addresses located behind CE-1. As packets flow from X to Z, PE2-rs, PE3-rs and PE4-rs learn about X on their respective mesh PWs terminating at PE1-rs. When MTU-s switches to the backup spoke PW and activates it, PE2-rs becomes the active device (designated forwarder) to reach the full mesh core. Traffic entering the H-VPLS from CE-1 and CE-2 is diverted by the MTU-s to the spoke PW to PE2-rs. Traffic destined from PE2-rs, PE3-rs and PE4-rs to X will be blackholed till MAC address ageing timer expires (default is 5 minutes) or a packet flows from X to Z through PE2-rs. To avoid traffic blackholing the MAC addresses that have been learned in the upstream VPLS full-mesh through PE1-rs, those addresses must be relearned or removed from the MAC FIBs in the VSIs at PE2-rs, PE3-rs and PE4-rs. This is accomplished by sending a MAC Flush Message with the list of MAC addresses to be removed to all PE-rs devices in the VPLS. In order to minimize the impact on LDP convergence time and scalability when a MAC List TLV contains a large number of MAC addresses, many implementations use a MAC Flush Message with an empty MAC List. 3.1. MTU-s Initiated MAC Flush When dual homing in H-VPLS is achieved by manual configuration in MTU-S node, the hosting PE-rs nodes are dual homing "agnostic". It is the MTU-s node that controls the primary and backup status of spoke PWs connected to PE1-rs and PE2-rs respectively. In figure 1, PE2-rs can send and receive traffic over the backup spoke PW any time and only MTU-s blocks the traffic on the spoke PW at its end. For example Broadcast, Unicast Unlearned and Multicast (BUM) traffic received from the VPLS core is continually forwarded by PE3-rs node over the backup spoke PW to get it dropped by MTU-s node. Therefore PE2-rs node (PE-rs node with now-active PW) cannot initiate MAC Flush message on activation of backup PW by MTU-s. When the backup PW is made active by the MTU-s node, it initiates a MAC Flush Message to PE2-rs node. The Message is sent over in the context of the newly activated spoke PW. On receiving the MAC Flush Message from MTU-s node, PE2-rs node would flush all the MAC addresses it has learned except the ones learned over the newly activated spoke PW (Here it is assumed that MTU-s initiated a MAC Flush Message with Kwok & Dutta Expires October 2, 2013 [Page 6] Internet-Draft MAC Flush Loop Detection March 2013 empty MAC List). PE2-rs node further "propagates" the MAC Flush Message to all other PE-rs nodes in the VPLS core to incur the same MAC flushing action in peer PE-rs nodes. The MAC Flush forwarding rules in LDP control plane strictly follow the "split-horizon" forwarding rules in H-VPLS data plane (Refer to section 4.4 in [RFC4762]). So a MAC Flush is forwarded in the context of mesh PW(s) only when it is received in the context of a spoke PW. When a PE-rs node receives a MAC Flush in the context of a mesh PW then it is not forwarded in the control plane further - means not forwarded to any mesh or spoke PWs. MTU-s initiated method of MAC Flushing is modeled after Topology Change Notification (TCN) in Rapid Spanning Tree Protocol (RSTP)[IEEE.802.1Q-2011]. When a bridge switches from a failed link to the backup link, the bridge sends out a TCN message over the newly activated link. The upstream bridge upon receiving this message flushes its entire MAC addresses except the ones received over this link and sends the TCN message out of its other ports in that spanning tree instance. The message is further relayed along the spanning tree by the other bridges. MTU-s initiated MAC Flushing may be also applicable when RSTP may be used to ensure loop free connectivity and failure protection between MTU-s node and host PE-rs node (Refer to section 11.2 in [RFC4762]). This method of MTU-s initiated MAC Flush is not explicitly described in [RFC4762], although it mentions about dual-homing with manual configuration or with xSTP (Any of the Spanning Tree Protocol Family) . Note that forced switchover to backup spoke PW can be also performed at MTU-s node administratively due to maintenance activities on the formerly primary spoke PW. 3.1.1. MAC Flush Loop Due to Misconfiguration In the figure below, PE1-rs, PE2-rs, PE3-rs and PE4-rs comprises of the VPLS full mesh core. The loop free connectivity between the PE-rs devices is supposed to be ensured by split-horizon forwarding rules between mesh PWs that connects the VPLS core[RFC4762]. Kwok & Dutta Expires October 2, 2013 [Page 7] Internet-Draft MAC Flush Loop Detection March 2013 PE1-rs PE3-rs +--------+ +--------+ | | | | | -- | | -- | | / \ |-----| / \ |-> /------| \ s/ | | \S / | primary spoke PW | -- | -| -- | / +--------+ / +--------+ (MTU-s) / \ / +--------+/ | \ / | | | | \ / | | -- | | \ / | | / \ | | H-VPLS Full Mesh Core| | \S / | | / \ | | -- | | / \ | +--------+\ / \ | backup spoke PW | \ \ +--------+ \--------+--------+ \ | | | | \------| -- | | -- | | / \ |------| / \ |-> | \s / | | \S / | | -- | | -- | +--------+ +--------+ PE2-rs PE4-rs Figure 2: Dual homed MTU-s in two tier hierarchy H-VPLS with misconfiguration in core Figure 2. above describes a set of misconfigurations in the H-VPLS topology, which are as follows: 1. The PW that connects between PE2-rs and PE3-rs has been misconfigured at PE3-rs as spoke PW instead of mesh PW. 2. The PW that connects between PE3-rs and PE1-rs has been misconfigured at PE1-rs as spoke PW instead of mesh PW. 3. The PW that connects between PE1-rs and PE2-rs has been misconfigured at PE2-rs as spoke PW instead of mesh PW. Such misconfiguration can occur due to configuration error in manual provisioning of a VPLS instance. Further such misconfiguration may also happen due to misconfiguration of the protocol(s) used to automate provisioning of VPLS instances. Note the misconfiguration now has created a loop in data plane along the path PE1-rs->PE2-rs->PE3-rs->PE1-rs. An example is as follows: Kwok & Dutta Expires October 2, 2013 [Page 8] Internet-Draft MAC Flush Loop Detection March 2013 1. BUM traffic received by PE1-rs from MTU-s over the primary spoke PW would be flooded to PE2-rs and PE3-rs (would be also forwarded to MTU-s over the backup spoke PW if PE2-rs is dual-homing agnostic). 2. PE2-rs on receiving the packets from PE1-rs on a spoke PW, PE2-rs would forward to PE3-rs over the mesh PW. 3. PE3-rs on receiving the packets from PE2-rs on a spoke PW, PE3-rs would forward to PE1-rs and PE4-rs over the respective mesh PWs. 4. PE1-rs on receiving the packets from PE3-rs on a spoke PW, PE1-rs would forward to PE2-rs and PE4-rs over the respective mesh PWs. Implementations may deploy several data plane loop breaking methods that are available in native service forwarding to break such loops in data path. Data plane loop breaking methods are outside the scope of this document. In this misconfigured topology, MTU-s activates the backup spoke PW to PE2-rs and initiates a MAC Flush Message towards PE2-rs. Since MAC flush forwarding rules are derived from the VPLS split-horizon rules data plane, a MAC flush loop would occur in the LDP control plane along PE2-rs->PE3-rs->PE1-rs->PE2-rs as follows: 1. PE2-rs on receiving the MAC Flush Message from MTU-s in the context of a spoke PW, PE2-rs would perform required flushing action and would forward the MAC Flush Message towards PE3-rs and PE4-rs in the context of respective mesh PWs. Note that PE2-rs would also forward the message to PE1-rs as well since the PW connecting to PE1-rs has been misconfigured as spoke. 2. PE3-rs on receiving the MAC Flush Message from PE2-rs in the context of a spoke PW, PE3-rs would perform required flushing action and would forward the MAC Flush Message to PE1-rs and PE4-rs in the context of respective mesh PWs. 3. PE1-rs on receiving the MAC Flush Message from PE3-rs in the context of a spoke PW, PE1-rs would perform required flushing action and would forward the MAC Flush Message to PE2-rs and PE4-rs in the context of respective mesh PWs. Each such loop of a MAC Flush Message causes replication to (N-1) messages, where N is number of PE-rs devices a replicating PE-rs is connected to. Such looping of MAC Flush Messages may lead to a denial of service (DoS) attacks or complete failure of the control plane in the node(s) and bring down services in the entire network. The LDP control plane in PE-rs or MTU-s nodes requires a fault tolerant mechanism to detect such loops and to protect against such Kwok & Dutta Expires October 2, 2013 [Page 9] Internet-Draft MAC Flush Loop Detection March 2013 failures. 3.2. PE-rs Initiated MAC Flush PE-rs initiated MAC Flush [RFC4762] specifies that on failure of the primary PW, it is the PE2-rs node (Figure 2) that initiates MAC flush towards the core. This is specified in section 10.2.2 in [RFC4762]. However note that PE2-rs node can initiate MAC Flush only when PE2-rs is dual homing "aware" - that is, there is some redundancy management protocol running between MTU-s and its host PE-rs devices. The scope of this document is not specific to any dual homing protocols. One example could be BGP based multi-homing in LDP based VPLS that uses the procedures defined in [I-D.ietf-l2vpn-vpls-multihoming]. In this method of dual-homing, PE3-rs would neither forward any traffic to MTU-s neither would receive any traffic from MTU-s while PE1-rs is acting a primary (or designated forwarder). When PE2-rs detects that the backup spoke PW is now active then PE2-rs initiates a MAC Flush Message towards all peer PE-rs nodes in the VPLS full-mesh core. The MAC Flush Processing and Forwarding Rules are same as explained in section 3.1. When a VPLS topology is misconfigured as described in Figure 2, a MAC Flush loop would occur in the same way as explained in section 3.1.1. 4. Loop Detection in MAC Flush This section describes the method for Detection and Protection against MAC Flush loops in the control plane. MAC Flush Loop Detection is a configurable option in a VPLS capable PE-rs or MTU-s node that provides a mechanism for finding and preventing MAC Flush messages from looping across the VPLS network. The mechanism makes use of LDP Path Vector TLVs defined in [RFC5036]. For loop detection in MAC Flush, Path Vector TLVs are carried in the MAC Flush Messages. The following shows the encoding of Path Vector TLV when used for MAC Flush Loop Detection. For backward compatibility with [RFC4762] the U bit and F bit MUST be set as 1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1| Path Vector (0x0104) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Kwok & Dutta Expires October 2, 2013 [Page 10] Internet-Draft MAC Flush Loop Detection March 2013 | LSR Id 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSR Id n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. Path Vector TLV in MAC Flush. The method builds on the following basic property of the TLV: - A Path Vector TLV contains a list of the PE-rs devices that the containing MAC Flush Message has traversed. A PE-rs is identified in a Path Vector list by its unique LDP LSR Identifier (LSR-ID), which is the first four octets of its LDP Identifier([RFC5036]). When a PE-rs propagates a MAC flush message containing a Path Vector, it appends its LSR-ID to the Path Vector list. An LSR that receives a message with a Path Vector that contains its LSR-ID, detects that the message has traversed a loop. The following paragraphs describe the MAC Flush Loop Detection Procedures. For these paragraphs, and only these paragraphs, "MUST" is redefined to mean "MUST if configured for Loop Detection". Further the term "PE-rs device" is used specify a VPLS capable PE-rs or a MTU-s device. 4.1. Loop Detection Procedure in MAC Flush Message The rules that govern use of the Path Vector TLV are LDP MAC Flush messages by a PE-rs when MAC Flush Loop Detection is enabled are the following: o If PE-rs device is originating the MAC Flush Message, it MUST include a Path Vector TLV of length 1 containing its own LSR-ID along with the MAC Flush Message originated to downstream PE-rs. o If PE-rs device is propagating the MAC flush as a result of having received a MAC Flush from an upstream PE-rs, then: * If the MAC Flush message contains no Path Vector TLV, then PE-rs MUST include a Path Vector TLV of length 1 containing its own LSR-ID along with the MAC Flush Message propagated to downstream PE-rs. * If the MAC Flush contains a Path Vector TLV then: Kwok & Dutta Expires October 2, 2013 [Page 11] Internet-Draft MAC Flush Loop Detection March 2013 + If the Path Vector TLV contains its LSR-ID then the PE-rs device detects the MAC flush message has traveled in a loop and it MUST drop the MAC Flush Message without processing, else + If the Path Vector TLV exceeds the maximum allowable length, then the PE-rs device detects that the MAC flush message has traveled in a loop and it MUST drop the MAC Flush Message without processing, else, + the TLV PE-rs device MUST add its own LSR ID to the Path Vector, and MUST pass the resulting Path Vector to its downstream PE-rs along with the propagated MAC flush message. By the definition of Path Vector TLV in [RFC5036], it supports the notion of a maximum allowable Path Vector Length; a PE-rs node that detects a Path Vector has reached the maximum length behaves as if containing message has traversed a loop. Such limit MAY be a locally configurable option in an implementation based on the scope of H-VPLS topology. The limit MAY also be driven by payload size limitations of MAC flush messages. 5. Applicability If MAC Flush Loop Detection is desired in VPLS Network, then it should be enabled on all PE-rs nodes within that VPLS Network, otherwise Loop Detection will not operate properly and may result in undetected loops or in falsely detected loops. PE-rs nodes that are configured for MAC Flush Loop Detection are not expected to store the Path Vectors as part of the VPLS service. There could be other H-VPLS topologies where the problem and the solution described in this document may be applicable. 6. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 7. Security Considerations Kwok & Dutta Expires October 2, 2013 [Page 12] Internet-Draft MAC Flush Loop Detection March 2013 - Control plane aspects - LDP security (authentication) methods as described in [RFC5036] is applicable here. Further this document implements security considerations as in [RFC4447] and [RFC4762]. - Data plane aspects - This specification does not have any impact on the VPLS forwarding plane. 8. Major Contributing Authors The authors would like to thank Don Fedyk who made a major contribution to development of this document. Don Fedyk Alcatel-Lucent, EMail: donald.fedyk@alcatel-lucent.com 9. Acknowledgements The authors would like acknowledge the comments and suggestions from Wim Henderickx, Vach Kompella, Florin Balus, Mustapha Aissaoui, Mathew Bocci, Miroslav Vrana, Nabil Bitar, Giles Heron and Ali Sajassi. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. Kwok & Dutta Expires October 2, 2013 [Page 13] Internet-Draft MAC Flush Loop Detection March 2013 10.2. Informative References [I-D.ietf-l2vpn-vpls-multihoming] Kothari, B., Kompella, K., Henderickx, W., Balus, F., and J. Uttaro, "BGP based Multi-homing in Virtual Private LAN Service", draft-ietf-l2vpn-vpls-multihoming-05 (work in progress), February 2013. [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. [IEEE.802.1Q-2011] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q, 2011. Authors' Addresses Paul Kwok Alcatel-Lucent 701 E Middlefield Road Mountain View, CA 94043 USA Email: paul.kwok@alcatel-lucent.com Pranjal Kumar Dutta Alcatel-Lucent 701 E Middlefield Road Mountain View, CA 94043 USA Email: pranjal.dutta@alcatel-lucent.com Kwok & Dutta Expires October 2, 2013 [Page 14]