Internet DRAFT - draft-l2vpn-vlpm
draft-l2vpn-vlpm
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
