R. Boldy Internet Draft Time Warner Cable Intended status: Standards Track March 13, 2013 Expires: September 13, 2013 VPLS external Loop Protection Mechanism (VLPM) draft-l2vpn-vlpm-01.txt 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), 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 13th, 2013. 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. This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English. Boldy Expires September, 2013 Page 1 Internet Draft draft-l2vpn-vlpm-01.txt Abstract Virtual Private LAN Service (VPLS) as defined in RFC4761 [RFC4761] and RFC4762 [RFC4762] implementations are highly susceptible to layer-2 loops external to the PE customer-facing interface. Such loops impact performance and can have a detrimental effect on all VPLS traffic throughout the entire instance under certain conditions. Current Layer-2 loop detection and protection mechanisms do not function effectively here. This document describes a protocol function (VPLS External Loop Protection Mechanism (VLPM)) to offer VPLS service providers a mechanism for detecting such layer-2 loops and facilitating configurable actions without the need for inter-operation with customer network protocols, other VPLS PEs or sites. Conventions 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 [RFC 2119] when and only when capitalized as shown above. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. Boldy Expires September, 2013 Page 2 Internet Draft draft-l2vpn-vlpm-01.txt Table of Contents Copyright Notice ...................................... 1 Abstract ...................................... 2 Conventions ...................................... 2 1. Introduction ...................................... 4 2. Terminology ...................................... 4 3. Problem Scope ...................................... 5 3.1. Type of Loop ...................................... 5 3.2. Instance Specific Traffic Flow ........................ 6 3.3. Size of the layer-2 broadcast domain ........................ 6 3.4. Scenario ........................ 6 4. Requirements ...................................... 7 5. Method of Operation ...................................... 8 5.1. Standard Function ........................ 8 5.2. No-loop-condition behavior ........................ 9 5.3. Loop-Present condition behavior ........................ 9 5.4. Standard configurable variables ........................ 9 5.5. Standard configurable actions ....................... 10 6. Common Concerns & Backfire ....................... 11 7. Existing Vendor Function ..................................... 12 8. Security Considerations ..................................... 12 8.1. False UPF Injection ....................... 12 8.2. UPF Propagation Failure ....................... 12 9. IANA Considerations .................................. 13 10. Acknowledgements ..................................... 13 11. References ..................................... 13 11.1. Normative References ..................................... 13 11.2. Informative References..................................... 14 12. Author's Address ..................................... 14 Boldy Expires September, 2013 Page 3 Internet Draft draft-l2vpn-vlpm-01.txt 1. Introduction VPLS External Loop Protection Mechanism (VLPM) is an expected function of an MPLS Perimeter Edge (PE) Router. Regardless of how physically or logically a VPLS external connection is made into a PE, the VPLS instance within each PE builds a per- instance MAC-address table much like a physical ethernet switch. Unlike a physical ethernet switch or a collection of them the layer-2 broadcast domain of a VPLS instance straddles operational boundaries between the customer and the service-provider. This difference, along with vendor configuration variables and capability, is what makes the deployment of well-known layer 2 loop protection and prevention mechanisms difficult and provides the need for VLPM. 2. Terminology Herein this document uses the following terminology: External Interface: Any connection into a VPLS instance on a MPLS Perimeter Edge (PE) router. External layer-2 segment: The per-customer-site layer-2 broadcast domain that is connected to, but external of the service provider controlled VPLS instance. External Loop: A loop that is a layer-2 loop itself or creates a layer-2 loop within the external layer-2 segment. Loop-Connected-PE: A PE that has an interface from which an external loop is present. Unknown-Unicast-Probe-Frame: An ethernet frame with a specifically (UPF) assigned IANA EUI-48 Unicast MAC address used by VLPM. Boldy Expires September, 2013 Page 4 Internet Draft draft-l2vpn-vlpm-01.txt 3. Problem Definition and Scope When an external-loop is created within the VPLS broadcast domain, there are serious negative data-plane impacts. The scope and severity of these issues varies due to several related factors. The following identifies the three main contributing factors: 3.1. Type of Loop Including but not limited to: 1. Layer-1 loop at the PE interface or within the same ethernet collision domain. 2. Layer-2 loop external to the PE within a broadcast domain that includes only one PE interface. 3. Layer-2 loop external to the PE within a broadcast domain that includes more than one PE interface. An example of each of these is shown in Figure 1 below using the following abbreviations: PE: MPLS Perimeter Edge Router CS: Customer Switch CR: Customer Router Loops are shown by number referencing the above list. All layer-2 links are assumed to be in the same VLAN. +----+ . . (3) . . . . . | CS | . +----+ . | . | . +----+ . . .....| PE |....... . . +----+ . . . . +----+ . . VPLS . ---| CS |---(2) . . INSTANCE . -| +----+ +----+ +----+ +----+ |- | CS |-------| PE |.............| PE |---------| +----+ +----+ +----+ | | -| | --- (1) +----+ | CR | Figure 1 +----+ Boldy Expires September, 2013 Page 5 Internet Draft draft-l2vpn-vlpm-01.txt 3.2. Instance Specific Traffic Flow The extent to which traffic flows over the Loop-Connected-PE, either by specific instance learning restrictions or by a higher layer communication topology. At layer-2 this simply is the number of connections from the same or other PEs that send frames to connections on the Loop-Connected-PE. 3.3. Size of the VPLS layer-2 broadcast domain Determined by: 1. Number of individual interfaces from all PEs participating in the specific VPLS instance. 2. Number of PEs containing interfaces participating in the specific VPLS instance. 3. Number of MAC-Addresses being learnt from all PE interfaces participating in the specific VPLS instance. 4. OSI functional level of the device externally connected to each interface. 3.4. Scenario To understand the scope and severity of any external loop on a VPLS instance,this section walks through a simplified and linear process for a very basic three-site VPLS instance sending very occasional frames based on the topology in Figure 2 below. +----+ .......|PE 2|........ . +----+ . . . . VPLS . . INSTANCE . +----+ +----+ +----+ +----+ |PC B|-------|PE 1|............|PE 3|-------|PC A| +----+ +----+ +----+ +----+ | (Loop) +----+ |PC C| +----+ Figure 2 Boldy Expires September, 2013 Page 6 Internet Draft draft-l2vpn-vlpm-01.txt Example. 1. PC B sends a frame to PC C 2. PE 1 adds PC Bs MAC-Address to its MAC-Table for this VPLS instance. 3. Due to a previous MAC-Table entry on PE1 (created by a frame from PC C sent when the loop was not present) the frame is unicast out the interface connecting to PC C. 4. The frame loops back at the external loop to PE1. 5. PE1 now learns that the MAC-Address of PC B is out the interface towards PC C. 6. Now PC A sends a frame to PC B 7. PE3 has a previous entry in its MAC-Table to send it to PE1 8. PE1 sends the frame to the interface towards PC C 9. The frame now loops back into PE1 with the source-address of PC A 10. PC B now sends a frame to PC A which is now sent to the interface towards PC C and may never get to PC A. As is clear, this example is highly simplified. Due to traffic streams MAC-learning would be flapping for all unicast frames sent towards the loop on PE 1. At a certain rate this will cause flooding of what should be known unicast frames which then propagates looped frames to other PEs in the VPLS instance. This in-turn populates their MAC-Address tables with incorrect information. This has the affect of sending more traffic towards the loop thus creating more and more MAC-Table instability and thus more flooding which, without interruption, will eventually prevent higher layer protocols from functioning. The affect of the above in a real-world network with 1000s of traffic flows and expected legitimate broadcast traffic can result in total loss of service for the entire VPLS instance within a very short timeframe. 4. Requirement Ethernet loop detection and protection is nothing new. There are several clearly defined and adopted protocols for this function and it is not the intent of this document to discuss any one or all or these in relation to VLPM except to identify requirement that are not addressed by such protocols. These requirements are detailed here: 1. The protection mechanism MUST be configurable solely on the service provider PE router, independent of customer device capability and configuration within the scope of industry standard default behavior of such devices. 2. The protection mechanism MUST be able to be deployed on a per- interface basis as well as globally per-PE, per-VPLS instance. Boldy Expires September, 2013 Page 7 Internet Draft draft-l2vpn-vlpm-01.txt 3. The protection mechanism MUST have no dependencies to the extent to which it may or may not be deployed on other interfaces, other interfaces in the same VPLS instance on other PEs, or other VPLS instances, except for necessary hardware limitations on the number of interfaces consecutively supported per device. 4. The protection mechanism MUST NOT require a topographical view of the network. 5. The protection mechanism MUST NOT alter or be dependent upon other frames transmitted within the layer-2 broadcast domain. 6. The protection mechanism MUST NOT restrict or in any way interfere with the operation of other protocols deployed within the layer-2 broadcast domain, including other layer-2 broadcast protection mechanisms except for when a loop- condition is detected and the configured action has indirect affects. 7. The protection mechanism MUST provide per-VPLS instance and per- interface level configurable parameters for protection options and loop-condition actions. 5. Method of Operation To meet the requirements noted above, VLPM operates in the following method. 5.1. Standard function A customer-facing PE MUST send an untagged ethernet frame from every external interface within a VPLS instance that is configured for VLPM using the VPLS instance or interface specific configured VLPM parameters. Each frame MUST be sourced from the specific external-interface using the BIA MAC-address of that interface and MUST use a fixed, specific destination MAC-address that is defined and allocated by IANA as an EUI-64 unicast MAC-address solely for this function of VLPM. This frame is referred to as the VLPM Unknown-Unicast-Probe-Frame or UPF and is expected to be processed and treated as any unknown unicast frame within a layer-2 broadcast domain by all devices. It is expected and REQUIRED that split-horizon rule is in effect by default on all layer-2 devices within the external layer-2 broadcast domain - i.e. the frame is flooded to all ports on a device except the ingress port, thus being propagated throughout the entirety of the external layer-2 segment. Boldy Expires September, 2013 Page 8 Internet Draft draft-l2vpn-vlpm-01.txt Each UPF MUST be generated by the PE at a default, per-interface or per-vpls-instance set interval of time. It is expected that the required minimum generation rate can be very low ~ 1 Frame Per Second (FPS) but should be configurable. The rate at which an interface sends the UPF correlates to the speed at which a loop can be recognized by VLPM to a certain extent, however past a certain ceiling it is expected to plateau. 5.2. No-Loop condition behavior When no loop is present within the external layer-2 segment the following is REQUIRED: * The UPF SHOULD propagate through the entirety of the segment * The UPF and all copies SHOULD be eventually discarded * The PE emanating interface SHALL NOT receive the UPF * Other PE interface within the VPLS instance SHALL NOT receive the UPF. 5.3. Loop-present condition behavior When a loop is present within the external layer-2 segment the following is REQUIRED: * The UPF SHOULD propagate through the entirety of the segment that is not restricted by the loop. * The PE emanating interface SHOULD receive the UPF or a copy of it. * Other PE interface within the VPLS instance MAY receive the UPF only if connected to the same logical external layer-2 segment where the loop resides, either by design or error. * Any PE that is configured for VLPM, and receives a UPF on a VLPM active interface, MUST drop the frame after it has been processed by VLPM. A UPF MUST NOT be forwarded within the VPLS instance or locally switched at the PE. 5.4. Standard configurable variables The PE interface or VPLS Instance that supports VLPM MUST allow for the configuration of the following variables: * Frequency of the UPF generation in Frames per second (FPS) between 1 and 60. (UPF Generation Frequency). * Frequency threshold of UPFs received in order to trigger configured actions. (UPF Trigger Frequency). * Source MAC-Address action-list. Either configured on the interface specifically or by means of a reference to a mac- access-list. * Source MAC-Address ignore-list. Either configured on the interface specifically or by means of a reference to a mac- access-list. Boldy Expires September, 2013 Page 9 Internet Draft draft-l2vpn-vlpm-01.txt The configurable UPF Trigger Frequency MUST NOT exceed the configured UPF Generation Frequency. VLPM MUST NOT be configurable on internally facing virtual VPLS interfaces. 5.5. Standard configurable actions The PE interface or VPLS Instance that supports VLPM MUST allow for the configuration of the following actions upon receipt of a UPF: * No action. * Any other allowable configured action only if the source MAC address of the UPF is not in the configured ignore-list. * Any other configured action only if the source MAC Address of the UPF is included in the configured action-list. * Creation of a syslog message. * Sending of an SNMP trap message. * Disabling MAC address learning in the VPLS instance for the external interface. * Discarding all traffic to and from the external interface for a configurable hold-time. * Disabling flooding of frames received from and to the associated interface. * Disabling of the associated logical or physical external interface requiring manual enabling (e.g. error-disable state) These actions MUST be configurable independently of each other and in combination with each other where logic permits. For example, it MUST be possible to configure the sending of an SNMP trap, sending a syslog message and disabling the external interface due to the receipt of a UPFs that cross the configured UPF trigger threshold. Boldy Expires September, 2013 Page 10 Internet Draft draft-l2vpn-vlpm-01.txt 6. Common Concerns & Backfire Theory Backfire is the technique of setting a smaller, controlled, fire to contain a larger wildfire. On the surface this technique of starting a fire to prevent a fire can be seen as strange. In the same way, sending of intentional unknown unicast frames into a layer-2 broadcast domain that may contain a loop may seem to be counter intuitive on the surface. However, it should be understood in the following context: * The expected required and configurable frame-rate of VLPM is very low. Under loop condition it is expected that the volume of other broadcast, multicast or unknown unicast frames within the external layer-2 broadcast domain would vastly outweigh any VLPM frames making their negative affect exceedingly minimal. * The intent of VLPM is to protect the larger VPLS instance and the rest of the connected customer network (not the specific external layer-2 broadcast segment) from the effects of an external loop. To this end VLPM allows for the local segment to be restricted or isolated from the larger layer-2 broadcast domain. Once restricted or isolated from the VPLS instance the condition of the layer-2 broadcast segment is of no concern to VLPM other than a stable, non-loop condition should exist before the segment is reconnected without restriction into the VPLS instance. * Prevention, resolution and/or specific identification of the cause of any loop are outside the scope and purpose of VLPM however restriction or isolation of the layer-2 broadcast segment will make troubleshooting within the segment easier as traffic volume should be reduced to that of only locally sourced frames. 7. Existing Vendor Functions At the time of writing there is one proprietary vendor implementation by Alcatel-Lucent known as "mac-move" that attempts to address this issue. This feature works by recognizing the learning of a MAC-Address on an interface that is different to an interface on which it was previously learnt. Although useful this feature addresses the issue from a MAC-Learning of customer traffic and is susceptible to false-positives. It also is reliant upon customer traffic and MAC-Learning of all customer frames which VLPM is not. There is also a non-vendor written JunOS event-script for MX-Series routers that functions in a similar way to the Alcatel-Lucent TimOS function and thus has similar drawbacks. Boldy Expires September, 2013 Page 11 Internet Draft draft-l2vpn-vlpm-01.txt 8. Security Considerations The security considerations for VLPM are as follows: 8.1. False UPF Injection Injection of a UPF into the layer-2 broadcast domain from an interface other than the service-provider PE interface would result in a false-positive and unnecessary implementation of the configured action on the PE external interface. To mitigate this happening accidentally it is recommended that VLPM only be supported on VPLS aware PE devices. To further protect against this and the possibility of malicious injection of such a frame the action-list and ignore-list features provides some basic protection. It is possible however for such a malicious frame to be crafted with a spoofed source MAC Address of the PE BIA interface. Such a malicious attack would require knowledge and access to the customer network to an extent that existing best practice security methods should prevent. 8.2. UPF Propagation Failure Under excessive conditions any loop in a layer-2 broadcast domain can result in a device ability to correctly switch traffic including the expected standard behavior of flooding unknown unicast frames. This MAY result in UPFs not being presented back to a VLPM configured interface as expected. The functions of UPF generation frequency and UPF trigger frequency should be configured with a high level of network congestion in mind. Where a device fails and prevents such frames from being able to be presented to a VLPM interface, even sporadically, it is expected that this would also prevent all other frames thus rendering VLPM action moot. Boldy Expires September, 2013 Page 12 Internet Draft draft-l2vpn-vlpm-01.txt 9. IANA Considerations IANA is requested to assign the registration of a specific EUI-48 unicast MAC address for use by VLPM as its destination MAC address. This document makes no assumptions as to which address will or should be allocation only to point to the following IANA reference that shows available unallocated address space: http://www.iana.org/assignments/ethernet-numbers/ethernet- numbers.xml The requirement is stated as a wholly reserved and specific EUI-48 unicast mac-address that would allow a frame to be treated, by any layer-2 ethernet device, as an unknown unicast frame when used as a destination address within an ethernet frame header. The need for such an address is detailed as below: * To ensure full propagation of the probe frame within any relevant broadcast domain segment. * To provide a non-hardware specific destination address that clearly identifies the purpose and intent of the VLPM frame for both identification on receipt by PE interfaces configured for VLPM and general network forensic assistance. * To ensure that no other protocol or device can legitimately generate a frame using the destination address being watch for by VLPM. * To allow for future development of the protocol. 10. Acknowledgments The author wishes to thank the following individuals for their much valued review, contribution and/or assistance: Michael Damkot Lee Howard David Gam 11. References 11.1. Normative References [RFC4761] Rekhter, Y., Kompella, K., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761,January 2007. [RFC4762] Lasserre, M., Kompella, V., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC4762, January 2007. [RFC 2119] S. Bradner, "Key words for use in RFCs to indicate requirement levels". Boldy Expires September, 2013 Page 13 Internet Draft draft-l2vpn-vlpm-01.txt 11.2. Informative References [MEF 6.1] Metro Ethernet Forum, Metro Ethernet Services Definitions Phase 2 MEF 6.1, June 2008. 12. Author's Addresses Comments are solicited and should be addressed to the author(s). Rich Boldy Time Warner Cable Email: richard.boldy@twcable.com Boldy Expires September, 2013 Page 14