L2VPN Working Group Paul Kwok
Internet Draft Pranjal Kumar Dutta
Intended status: Standard Alcatel-Lucent
Expires: September 2010
March 7, 2010
MAC Flush Loop Detection in VPLS
draft-pkwok-l2vpn-vpls-macflush-ld-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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
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 September 7, 2010.
Abstract
MAC Address Withdrawal is a mechanism described in [RFC4762] to
remove or unlearn MAC addresses that have been dynamically learned,
for faster convergence. Failure of mechanisms that control loop free
connectivity (e.g Split Horizon) among VPLS PE 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 nodes. This document describes a mechanism to detect and prevent
loops of MAC Address Withdrawal messages in a VPLS PE node on such
failures.
Kwok, et. al. Expires September 7, 2010 [Page 1]
Internet-Draft MAC Flush Loop Detection March 2010
Table of Contents
1. Introduction...................................................2
2. Conventions used in this document..............................3
3. Terminology....................................................3
4. Problem Statement..............................................4
5. Loop Detection in MAC Flush....................................5
6. Applicability..................................................7
7. Security Considerations........................................7
8. IANA Considerations............................................7
9. References.....................................................7
9.1. Normative References......................................7
9.2. Informative References....................................8
10. Acknowledgments...............................................8
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 devices to construct the VPLS core. The mesh topology provides a
LAN segment or broadcast domain that is fully capable of learning and
forwarding on Ethernet MAC addresses at the PE devices. Since every
PE is now directly connected to every other PE in the core via a PW,
the topology forms a loop. A simpler loop breaking rule is used - the
"spilt horizon" rule, whereby a PE does not forward traffic from one
PW to another in the same VPLS mesh. Various mechanisms used to
enforce split horizon in the VPLS full mesh is 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 [RFC4762] nodes
to provide a Hierarchical VPLS (H-VPLS) service [RFC4762]. To protect
from connection failure of the spoke PW or the PE, the MTU-s or
the PE is dual-homed into two PE devices in the same VPLS
instance [Figure 1]. The dual homed connectivity forms a loop that
requires loop breaking mechanism. Various loop breaking mechanisms
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 link for a dual-homed VPLS capable switch). In
this document the term "MAC Flush Message" means the LDP Address
Withdraw Message with MAC List TLV used for MAC address withdrawal in
VPLS.
Kwok, et. al. Expires September 7, 2010 [Page 2]
Internet-Draft MAC Flush Loop Detection March 2010
Failure of mechanisms that control loop free connectivity among VPLS
PE nodes may cause MAC Flush messages looping among the nodes. This
document describes a mechanism to detect and prevent such loops on
MAC Flush messages.
Note that such misconfiguration may cause loops, 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 detect and
prevent such loops in data path.
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 [RFC2119].
3. 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.
Kwok, et. al. Expires September 7, 2010 [Page 3]
Internet-Draft MAC Flush Loop Detection March 2010
4. Problem Statement
This section describes the problem in detail.
PE-1 PE-3
+--------+ +--------+
| | | |
| -- | | -- |
| / \ |------------------| / \ |->
/------| \ s/ | | \S / |
primary spoke PW | -- | /------| -- |
/ +--------+ / +--------+
(MTU-s)/ | \ / |
+--------+/ | \ / |
| | | \ / |
| -- | | \ / |
| / \ | | H-VPLS Full Mesh Core|
| \S / | | / \ |
| -- | | / \ |
+--------+\ | / \ |
backup spoke PW | / \ |
\ +--------+ \--------+--------+
\ | | | |
\------| -- | | -- |
| / \ |------------------| / \ |->
| \s / | | \S / |
| -- | | -- |
+--------+ +--------+
PE-2 PE-4
Figure 1: Dual homed MTU-s in two tier hierarchy H-VPLS
When a MAC flush message is received by a PE device, it is processed
locally and propagated to all other PE devices participating in the
full mesh. The scope of MAC flush propagation in the full mesh is
limited by the same split horizon rules applied for forwarding VPLS
service traffic. MAC flush message received from a PE device
Kwok, et. al. Expires September 7, 2010 [Page 4]
Internet-Draft MAC Flush Loop Detection March 2010
participating in full mesh is not forwarded to another PE device in
the same full mesh. Due to failure of split horizon control
mechanisms or misconfiguration in the VPLS topology, a loop may get
created. Similarly, due to failure of loop breaking mechanism in
dual-homed topology a loop may get created among the participating PE
and/or MTU-s devices. In such a scenario, a MAC flush message may be
propagated by a PE or MTU-s to cause loops of MAC flush messages
through the control plane. Each such loop of a MAC flush message
causes replication to (N-1) messages, where N is number of PE devices
the replicating PE is connected to. Such looping of MAC flush
messages may lead to denial of service (DoS) attacks or complete
failure of the control plane. The control plane in PE or MTU-s
devices requires a fault tolerant mechanism to detect such loops and
protect against such failures. This document describes a loop
detection procedure in MAC Flush in a VPLS.
5. Loop Detection in MAC Flush
MAC Flush Loop Detection is a configurable option in a VPLS capable
PE or MTU-s device 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 [RFC
5036]. 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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR Id 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR Id n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Path Vector TLV in MAC Flush.
Kwok, et. al. Expires September 7, 2010 [Page 5]
Internet-Draft MAC Flush Loop Detection March 2010
The method builds on the following basic property of the TLV:
- A Path Vector TLV contains a list of the PEs that the
containing MAC flush message has traversed. A PE is identified
in a Path Vector list by its unique LDP LSR Identifier, which
is the first four octets of its LDP Identifier. When a PE
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 device" is used specify a VPLS capable PE or a MTU-s
device.
5.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 when MAC Flush Loop Detection is enabled are the
following:
- If PE device is originating the MAC Flush Message, it MUST
include a Path Vector TLV of length 1 containing its own LSR
Id.
- If PE device is propagating the MAC flush as a result of
having received a MAC Flush from an upstream PE, then if the
MAC Flush contains a Path Vector TLV :
PE device MUST add its own LSR Id to the Path Vector, and
MUST pass the resulting Path Vector to its downstream PE
along with the MAC flush message propagated. If the MAC
flush message contains no Path Vector TLV, then PE MUST
include a Path Vector TLV of length 1 containing its own
LSR Id.
- If PE device receives a MAC Flush Message from another PE
device with a Path Vector TLV containing its LSR Id or which
exceeds the maximum allowable length, then PE device detects
that the MAC flush message has traveled in a loop. By the
definition of Path Vector TLV in [RFC5036], supports the
notion of a maximum allowable Path Vector Length; a PE 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
Kwok, et. al. Expires September 7, 2010 [Page 6]
Internet-Draft MAC Flush Loop Detection March 2010
the scope of H-VPLS topology. The limit MAY also be driven by
payload size limitations of MAC flush messages.
- When PE device detects a loop, it MUST drop the MAC flush
message without processing and MUST NOT propagate the message
further.
6. Applicability
If MAC Flush Loop Detection is desired in VPLS Network, then it
should be turned on in all PE devices within that VPLS Network, else
Loop Detection will not operate properly and may result in undetected
loops or in falsely detected loops.
PE devices that are configured for MAC Flush Loop Detection are not
expected to store the Path Vectors as part of the VPLS service.
7. Security Considerations
- 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. IANA Considerations
This document does not require any IANA consideration.
9. References
9.1. Normative References
[RFC4762] Lasserre, M. and Kompella, V., "Virtual Private LAN
Services using LDP", RFC 4762, January 2007.
[RFC5036] Andersson, L., et al. "LDP Specification", RFC5036,
October 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Kwok, et. al. Expires September 7, 2010 [Page 7]
Internet-Draft MAC Flush Loop Detection March 2010
9.2. Informative References
[L2VPN-SIG] Rosen, E., et al. "Provisioning, Autodiscovery,
and Signaling in L2VPNs", work in progress.
[RFC4664] Andersson, L., et al. "Framework for Layer 2
Virtual Private Networks (L2VPNs)", RFC 4664,
September 2006.
[RFC4447] Martini. and et al., "Pseudowire Setup and
Maintenance Using Label Distribution Protocol
(LDP)", RFC 4447, April 2006
10. Acknowledgments
The authors would like acknowledge the comments and suggestions from
Wim Henderickx, Vach Kompella, Florin Balus, Mustapha Aissaoui,
Mathew Bocci and Miroslav Vrana.
This document was prepared using 2-Word-v2.0.template.dot.
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, et. al. Expires September 7, 2010 [Page 8]
Internet-Draft MAC Flush Loop Detection March 2010
Copyright Notice
Copyright (c) 2010 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.
Kwok, et. al. Expires September 7, 2010 [Page 9]