R. Boldy Internet Draft Time Warner Cable Intended status: Standards Track May 2, 2013 Expires: November 2, 2013 VPLS external Loop Protection Mechanism (VLPM) draft-l2vpn-vlpm-02.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 November 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 November, 2013 Page 1 Internet Draft draft-l2vpn-vlpm-02.txt Abstract In reference and response to draft-boldy-l2vpn-vplsloop-req-01, this document describes a solution in the form of a protocol function named VPLS External Loop Protection Mechanism (VLPM). VLPM is a protocol for a service provider to deploy at the PE to detect layer-2 loops in any external layer-2 segments (customer LAN) where customer deployed loop prevention methods may have failed. After detection of such a loop it facilitates configurable actions to protect the rest of the VPLS Domain from being affected 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 November, 2013 Page 2 Internet Draft draft-l2vpn-vlpm-02.txt Table of Contents Copyright Notice ...................................... 1 Abstract ...................................... 2 Conventions ...................................... 2 1. Introduction ...................................... 4 2. Terminology ...................................... 4 3. Method of Operation ...................................... 5 3.1. Standard Function ........................ 5 3.2. No-loop-condition behavior ........................ 6 3.3. Loop-Present condition behavior ........................ 6 3.4. Standard configurable variables ........................ 6 3.5. Standard configurable actions ....................... 7 4. Common Concerns & Backfire ....................... 7 5. Existing Vendor Function ..................................... 8 6. Security Considerations ..................................... 8 7.1. False UPF Injection ....................... 8 7.2. UPF Propagation Failure ....................... 9 8. IANA Considerations .................................. 9 9. Acknowledgements ..................................... 10 10. References ..................................... 10 10.1. Normative References ..................................... 10 10.2. Informative References..................................... 10 11. Author's Address ..................................... 10 Boldy Expires November, 2013 Page 3 Internet Draft draft-l2vpn-vlpm-02.txt 1. Introduction VPLS External Loop Protection Mechanism (VLPM) is an expected function of an MPLS Provider Edge (PE) Router configured with VPLS services in line with [RFC4761] and/or [RFC4762]. 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 Provider 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 November, 2013 Page 4 Internet Draft draft-l2vpn-vlpm-02.txt 3. Method of Operation To meet the requirements stated in draft-boldy-l2vpn-vplsloop-req-01 VLPM operates in the following method. 3.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. 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. Boldy Expires November, 2013 Page 5 Internet Draft draft-l2vpn-vlpm-02.txt 3.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. 3.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. 3.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. The configurable UPF Trigger Frequency MUST NOT exceed the configured UPF Generation Frequency. VLPM MUST NOT be configurable on internally facing virtual VPLS interfaces. Boldy Expires November, 2013 Page 6 Internet Draft draft-l2vpn-vlpm-02.txt 3.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. 4. 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. Boldy Expires November, 2013 Page 7 Internet Draft draft-l2vpn-vlpm-02.txt * 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. 5. Existing Vendor Functions At the time of writing there is one proprietary vendor implementation 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 event-script for another Vendor router platform that functions in a similar way and thus has similar drawbacks. 6. Security Considerations The security considerations for VLPM are as follows: 6.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. Boldy Expires November, 2013 Page 8 Internet Draft draft-l2vpn-vlpm-02.txt 6.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. 7. 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. Boldy Expires November, 2013 Page 9 Internet Draft draft-l2vpn-vlpm-02.txt 8. Acknowledgments The author wishes to thank the following individuals for their much valued review, contribution and/or assistance: Michael Damkot Lee Howard David Gam Stephanie Orsburn 9. References 9.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". 9.2. Informative References [MEF 6.1] Metro Ethernet Forum, Metro Ethernet Services Definitions Phase 2 MEF 6.1, June 2008. 10. 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 November, 2013 Page 10