Internet DRAFT - draft-ietf-l2vpn-vpls-macflush-ld
draft-ietf-l2vpn-vpls-macflush-ld
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
+--------+ +--------+
| | | |
| -- | | -- |
| / \ |<spoke>-----<mesh>| / \ |->
/------| \ s/ | | \S / |
primary spoke PW | -- | <spoke>-| -- |
/ +--------+ / +--------+
(MTU-s) / <mesh> \ / <mesh>
+--------+/ | \ / |
| | | \ / |
| -- | | \ / |
| / \ | | H-VPLS Full Mesh Core|
| \S / | | / \ |
| -- | | / \ |
+--------+\ <spoke> / \ |
backup spoke PW | <mesh> \ <mesh> <mesh>
\ +--------+ \--------+--------+
\ | | | |
\------| -- | | -- |
| / \ |-<mesh>-----<mesh>| / \ |->
| \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]