R. Boldy Internet Draft Time Warner Cable Intended status: Standards Track March 21, 2013 Expires: September 21, 2013 VPLS External Loop Detection and Protection Requirements draft-boldy-l2vpn-vplsloop-req-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 21th, 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-boldy-l2vpn-vplsloop-req-01.txt Abstract Virtual Private LAN Service (VPLS) implementations, as defined in [RFC4761] and [RFC4762], are highly susceptible to layer-2 loops external to the PE customer-facing interface. Such loops impact performance and can have a detrimental affect 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 the requirements for a protocol function 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 customer sourced frames. 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-boldy-l2vpn-vplsloop-req-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 ..................................... 8 5. Existing Vendor Function ..................................... 9 6. Security Considerations ..................................... 9 6.1. False UPF Injection ....................... 9 6.2. Malicious Trigger ....................... 9 7. IANA Considerations ................................... 9 8. Acknowledgements ..................................... 10 9. References ..................................... 10 9.1. Normative References ..................................... 10 9.2. Informative References ..................................... 10 10. Author's Address ..................................... 10 Boldy Expires September, 2013 Page 3 Internet Draft draft-boldy-l2vpn-vplsloop-req-01.txt 1. Introduction Regardless of how physically or logically a VPLS external connection is made into an MPLS Perimeter Edge Router (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 makes the deployment and ongoing operational aspects of well-known layer-2 loop protection mechanisms difficult and provides the need for a solution that is solely owned and operated by the service-provider at the PE, on a per-connection basis. 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. Boldy Expires September, 2013 Page 4 Internet Draft draft-boldy-l2vpn-vplsloop-req-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-boldy-l2vpn-vplsloop-req-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-boldy-l2vpn-vplsloop-req-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 PE-1 (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 PE-1. 5. PE-1 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. PE-3 has a previous entry in its MAC-Table to send it to PE-1 8. PE-1 sends the frame incorrectly to the interface towards PC-C 9. The frame now loops back into PE-1 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. Boldy Expires September, 2013 Page 7 Internet Draft draft-boldy-l2vpn-vplsloop-req-01.txt 4. Requirements 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 except to identify requirement that are not addressed as a whole or individually 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. 3. The protection mechanism MUST have no dependencies to the extent to which it may or may not be deployed on other interfaces, 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. i.e. Any protocol solution MUST NOT have any stateful dependancies. 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 loop 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. 8. The protection mechanism MUST provide the following loop-condition actions related to the layer-2 segment where the loop is detected: isolate it from the VPLS instance; prevent broadcast traffic entering the VPLS instance; stop MAC-Learning; send an SNMP trap message; create a syslog message. These actions should be configurable in isolation and/or in conjunction with each other where logic permits. 9. The protection mechanism must allow for clear identification of any specific protocol frames for network forensic accountability. 10. The protection mechanism MUST have no dependancies on other protocols. Boldy Expires September, 2013 Page 8 Internet Draft draft-boldy-l2vpn-vplsloop-req-01.txt 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. This is in violation of requirement 5 in Section 4. There is also a non-vendor written script for another vendor Operating Software that functions in a similar way and thus has the same drawbacks. 6. Security Considerations The security considerations are as follows: 6.1 False Positives The solution MUST account for and protect against action due to a false loop-condition to an extent that is reasonable to expect within the scope and expected normal operation of the service. 6.2 Malicious Trigger The solution MUST account for and protect against action due to the malicious attempt to trigger a false loop-condition to an extent that is reasonable to expect within the scope of expected security best-practice for the service. 7. IANA Considerations None. 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 Boldy Expires September, 2013 Page 9 Internet Draft draft-boldy-l2vpn-vplsloop-req-01.txt 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 September, 2013 Page 10