draft-ietf-bmwg-protection-meth-13.txt   draft-ietf-bmwg-protection-meth-14.txt 
Network Working Group R. Papneja Network Working Group R. Papneja
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Informational S. Vapiwala Intended status: Informational S. Vapiwala
Expires: May 13, 2013 J. Karthik Expires: May 28, 2013 J. Karthik
Cisco Systems Cisco Systems
S. Poretsky S. Poretsky
Allot Communications Allot Communications
S. Rao S. Rao
Qwest Communications Qwest Communications
JL. Le Roux JL. Le Roux
France Telecom France Telecom
November 14, 2012 November 29, 2012
Methodology for Benchmarking MPLS-TE Fast Reroute Protection Methodology for Benchmarking MPLS-TE Fast Reroute Protection
draft-ietf-bmwg-protection-meth-13.txt draft-ietf-bmwg-protection-meth-14.txt
Abstract Abstract
This draft describes the methodology for benchmarking MPLS Fast This draft describes the methodology for benchmarking MPLS Fast
Reroute (FRR) protection mechanisms for link and node protection. Reroute (FRR) protection mechanisms for link and node protection.
This document provides test methodologies and testbed setup for This document provides test methodologies and testbed setup for
measuring failover times of Fast Reroute techniques while considering measuring failover times of Fast Reroute techniques while considering
factors (such as underlying links) that might impact factors (such as underlying links) that might impact
recovery times for real-time applications bound to MPLS traffic recovery times for real-time applications bound to MPLS traffic
engineered (MPLS-TE) tunnels. engineered (MPLS-TE) tunnels.
skipping to change at page 5, line 30 skipping to change at page 5, line 30
network failures, which impacts the network's ability and performance network failures, which impacts the network's ability and performance
for failure recovery. It therefore becomes imperative for service for failure recovery. It therefore becomes imperative for service
providers to have a common benchmark to understand the performance providers to have a common benchmark to understand the performance
behaviors of network elements. behaviors of network elements.
There are two factors impacting service availability: frequency of There are two factors impacting service availability: frequency of
failures and duration for which the failures persist. Failures can failures and duration for which the failures persist. Failures can
be classified further into two types: correlated and uncorrelated. be classified further into two types: correlated and uncorrelated.
Correlated and uncorrelated failures may be planned or unplanned. Correlated and uncorrelated failures may be planned or unplanned.
Planned failures are predictable. Network implementations should be Planned failures are generally predictable. Network implementations
able to handle both planned and unplanned failures and recover should be able to handle both planned and unplanned failures and
gracefully within a time frame to maintain service assurance. Hence, recover gracefully within a time frame to maintain service assurance.
failover recovery time is one of the most important benchmark that a Hence, failover recovery time is one of the most important benchmark
service provider considers in choosing the building blocks for their that a service provider considers in choosing the building blocks
network infrastructure. for their network infrastructure.
A correlated failure is a result of the occurrence of two or more A correlated failure is a result of the occurrence of two or more
failures. A typical example is failure of a logical resource (e.g. failures. A typical example is failure of a logical resource (e.g.
layer-2 links) due to a dependency on a common physical resource layer-2 links) due to a dependency on a common physical resource
(e.g. common conduit) that fails. Within the context of MPLS (e.g. common conduit) that fails. Within the context of MPLS
protection mechanisms, failures that arise due to Shared Risk Link protection mechanisms, failures that arise due to Shared Risk Link
Groups (SRLG) [RFC 4090] can be considered as correlated failures. Groups (SRLG) [RFC 4202] can be considered as correlated failures.
MPLS FRR [RFC 4090] allows for the possibility that the Label MPLS FRR [RFC 4090] allows for the possibility that the Label
Switched Paths can be re-optimized in the minutes following Failover. Switched Paths can be re-optimized in the minutes following Failover.
IP Traffic would be re-routed according to the preferred path for the IP Traffic would be re-routed according to the preferred path for the
post-failure topology. Thus, MPLS-FRR may include additional steps post-failure topology. Thus, MPLS-FRR may include additional steps
following the occurrence of the failure detection [RFC 6414] and following the occurrence of the failure detection [RFC 6414] and
failover event [RFC 6414]. failover event [RFC 6414].
(1) Failover Event - Primary Path (Working Path) fails (1) Failover Event - Primary Path (Working Path) fails
skipping to change at page 6, line 32 skipping to change at page 6, line 32
This document provides detailed test cases along with different This document provides detailed test cases along with different
topologies and scenarios that should be considered to effectively topologies and scenarios that should be considered to effectively
benchmark MPLS FRR protection mechanisms and failover times on the benchmark MPLS FRR protection mechanisms and failover times on the
Data Plane. Different Failover Events and scaling considerations are Data Plane. Different Failover Events and scaling considerations are
also provided in this document. also provided in this document.
All benchmarking test-cases defined in this document apply to All benchmarking test-cases defined in this document apply to
Facility backup [RFC 4090]. The test cases cover set of interesting Facility backup [RFC 4090]. The test cases cover set of interesting
failure scenarios and the associated procedures benchmark the failure scenarios and the associated procedures benchmark the
performance of the Device Under Test (DUT) to recover from failures. performance of the Device Under Test (DUT) to recover from failures.
Data plane traffic is used to benchmark failover times. Data plane traffic is used to benchmark failover times. Testing
scenarios related to MPLS-TE protection mechanisms when applied
to MPLS Transport Profile and IP fast reroute applied to MPLS
networks were not considered and are out of scope of this document.
However, the test setups considered for MPLS based Layer 3 and
Layer 2 services consider LDP over MPLS RSVP-TE configurations.
Benchmarking of correlated failures is out of scope of this document. Benchmarking of correlated failures is out of scope of this document.
Detection using Bi-directional Forwarding Detection (BFD) is outside Detection using Bi-directional Forwarding Detection (BFD) is outside
the scope of this document, but mentioned in discussion sections. the scope of this document, but mentioned in discussion sections.
The Performance of control plane is outside the scope of this The Performance of control plane is outside the scope of this
benchmarking. benchmarking.
As described above, MPLS-FRR may include a Re-optimization of the As described above, MPLS-FRR may include a Re-optimization of the
Working Path, with possible packet transfer impairments. Working Path, with possible packet transfer impairments.
skipping to change at page 9, line 4 skipping to change at page 9, line 4
(7) Traffic generation (section 5.7) (7) Traffic generation (section 5.7)
5.1. Failover Events [RFC 6414] 5.1. Failover Events [RFC 6414]
The failover to the backup tunnel is primarily triggered by either The failover to the backup tunnel is primarily triggered by either
link or node failures observed downstream of the Point of Local link or node failures observed downstream of the Point of Local
repair (PLR). The failure events are listed below. repair (PLR). The failure events are listed below.
Link Failure Events Link Failure Events
- Interface Shutdown on PLR side with POS Alarm - Interface Shutdown on PLR side with physical/link Alarm
- Interface Shutdown on remote side with POS Alarm - Interface Shutdown on remote side with physical/link Alarm
- Interface Shutdown on PLR side with RSVP hello enabled - Interface Shutdown on PLR side with RSVP hello enabled
- Interface Shutdown on remote side with RSVP hello enabled - Interface Shutdown on remote side with RSVP hello enabled
- Interface Shutdown on PLR side with BFD - Interface Shutdown on PLR side with BFD
- Interface Shutdown on remote side with BFD - Interface Shutdown on remote side with BFD
- Fiber Pull on the PLR side (Both TX & RX or just the TX) - Fiber Pull on the PLR side (Both TX & RX or just the TX)
- Fiber Pull on the remote side (Both TX & RX or just the RX) - Fiber Pull on the remote side (Both TX & RX or just the RX)
- Online insertion and removal (OIR) on PLR side - Online insertion and removal (OIR) on PLR side
- OIR on remote side - OIR on remote side
- Sub-interface failure on PLR side (e.g. shutting down of a VLAN) - Sub-interface failure on PLR side (e.g. shutting down of a VLAN)
- Sub-interface failure on remote side - Sub-interface failure on remote side
skipping to change at page 30, line 50 skipping to change at page 30, line 50
12.1. Informative References 12.1. Informative References
[RFC 2285] Mandeville, R., "Benchmarking Terminology for LAN [RFC 2285] Mandeville, R., "Benchmarking Terminology for LAN
Switching Devices", RFC 2285, February 1998. Switching Devices", RFC 2285, February 1998.
[RFC 4689] Poretsky, S., Perser, J., Erramilli, S., and S. Khurana, [RFC 4689] Poretsky, S., Perser, J., Erramilli, S., and S. Khurana,
"Terminology for Benchmarking Network-layer Traffic "Terminology for Benchmarking Network-layer Traffic
Control Mechanisms", RFC 4689, October 2006. Control Mechanisms", RFC 4689, October 2006.
[RFC 4202] Kompella, K., Rekhter, Y., "Routing Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4202, October 2005.
12.2. Normative References 12.2. Normative References
[RFC 1242] Bradner, S., "Benchmarking terminology for network [RFC 1242] Bradner, S., "Benchmarking terminology for network
interconnection devices", RFC 1242, July 1991. interconnection devices", RFC 1242, July 1991.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute [RFC 4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
 End of changes. 8 change blocks. 
13 lines changed or deleted 22 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/