Internet DRAFT - draft-boldy-l2vpn-vplsloop-req
draft-boldy-l2vpn-vplsloop-req
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
