draft-ietf-bmwg-acc-bench-meth-01.txt   draft-ietf-bmwg-acc-bench-meth-02.txt 
Network Working Group Network Working Group
INTERNET-DRAFT INTERNET-DRAFT
Expires in: April 2005 Expires in: October 2005
Scott Poretsky Scott Poretsky
Quarry Technologies Quarry Technologies
Shankar Rao Shankar Rao
Qwest Communications Qwest Communications
October 2004 February 2005
Methodology for Accelerated Stress Benchmarking Methodology for Accelerated Stress Benchmarking
<draft-ietf-bmwg-acc-bench-meth-01.txt> <draft-ietf-bmwg-acc-bench-meth-02.txt>
Intellectual Property Rights (IPR) statement: Intellectual Property Rights (IPR) statement:
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, or patent or other IPR claims of which I am aware have been disclosed, or
will be disclosed, and any of which I become aware will be disclosed, will be disclosed, and any of which I become aware will be disclosed,
in accordance with RFC 3668. in accordance with RFC 3668.
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
skipping to change at page 1, line 55 skipping to change at page 1, line 55
ABSTRACT ABSTRACT
Routers in an operational network are simultaneously configured with Routers in an operational network are simultaneously configured with
multiple protocols and security policies while forwarding traffic and multiple protocols and security policies while forwarding traffic and
being managed. To accurately benchmark a router for deployment it is being managed. To accurately benchmark a router for deployment it is
necessary that the router be tested in these simultaneous necessary that the router be tested in these simultaneous
operational conditions, which is known as Stress Testing. This operational conditions, which is known as Stress Testing. This
document provides the Methodology for performing Stress Benchmarking document provides the Methodology for performing Stress Benchmarking
of networking devices. Descriptions of Test Topology, Benchmarks and of networking devices. Descriptions of Test Topology, Benchmarks and
Reporting Format are provided in addition to procedures for Reporting Format are provided in addition to procedures for
conducting various test cases. The methodology is to be used with conducting various test cases. The methodology is to be used with
the companion terminology document [6]. the companion terminology document [4].
Table of Contents Table of Contents
1. Introduction ............................................... 2 1. Introduction ............................................... 2
2. Existing definitions ....................................... 3 2. Existing definitions ....................................... 3
3. Test Setup.................................................. 3 3. Test Setup.................................................. 3
3.1 Test Topologies............................................ 3 3.1 Test Topologies............................................ 3
3.2 Test Considerations........................................ 4 3.2 Test Considerations........................................ 3
3.3 Reporting Format........................................... 4 3.3 Reporting Format........................................... 4
3.3.1 Configuration Sets....................................... 4 3.3.1 Configuration Sets....................................... 5
3.3.2 Instability Conditions................................... 6 3.3.2 Instability Conditions................................... 6
3.3.3 Benchmarks............................................... 6 3.3.3 Benchmarks............................................... 6
4. Test Cases.................................................. 7 4. Test Cases.................................................. 7
4.1 Failed Primary EBGP Peer................................... 7 4.1 Failed Primary EBGP Peer................................... 7
4.2 Establish New EBGP Peer.................................... 7 4.2 Establish New EBGP Peer.................................... 8
4.3 BGP Route Explosion........................................ 8 4.3 BGP Route Explosion........................................ 8
4.4 BGP Policy Configuration................................... 8 4.4 BGP Policy Configuration................................... 9
4.5 Persistent BGP Flapping.................................... 9 4.5 Persistent BGP Flapping.................................... 9
4.6 DoS Attack................................................. 9 4.6 BGP Route Flap Dampening...................................10
5. Security Considerations..................................... 10 4.7 Nested Convergence Events..................................11
6. References.................................................. 10 4.8 Restart Under Load.........................................12
7. Author's Address............................................ 11 4.9 Destination Control Processor..............................12
4.10 Destination Control Processor with Rate-Limiting..........13
4.11 Destination Interfaces....................................13
4.12 DoS Attack................................................14
5. Security Considerations.....................................14
6. Normative References........................................14
7. Normative References........................................15
8. Author's Address............................................15
1. Introduction 1. Introduction
Router testing benchmarks have consistently been made in a Router testing benchmarks have consistently been made in a
monolithic fashion wherein a single protocol or behavior is monolithic fashion wherein a single protocol or behavior is
measured in an isolated environment. It is important to know the measured in an isolated environment. It is important to know the
limits for a networking device's behavior for each protocol in isolation, limits for a networking device's behavior for each protocol in isolation,
however this does not produce a reliable benchmark of the device's however this does not produce a reliable benchmark of the device's
behavior in an operational network. behavior in an operational network.
Routers in an operational network are simultaneously configured with Routers in an operational network are simultaneously configured with
multiple protocols and security policies while forwarding traffic multiple protocols and security policies while forwarding traffic
and being managed. To accurately benchmark a router for deployment and being managed. To accurately benchmark a router for deployment
it is necessary to test that router in operational conditions by it is necessary to test that router in operational conditions by
simultaneously configuring and scaling network protocols and security simultaneously configuring and scaling network protocols and security
policies, forwarding traffic, and managing the device. It is helpful policies, forwarding traffic, and managing the device. It is helpful
to accelerate these network operational conditions with Instability to accelerate these network operational conditions with Instability
Conditions [6] so that the networking devices are stress tested. Conditions [4] so that the networking devices are stress tested.
This document provides the Methodology for performing Stress
Benchmarking of networking devices. Descriptions of Test Topology,
Benchmarks and Reporting Format are provided in addition to
procedures for conducting various test cases. The methodology is
to be used with the companion terminology document [4].
Stress Testing of networking devices provides the following benefits: Stress Testing of networking devices provides the following benefits:
1. Evaluation of multiple protocols enabled simultaneously as 1. Evaluation of multiple protocols enabled simultaneously as
configured in deployed networks configured in deployed networks
2. Evaluation of System and Software Stability 2. Evaluation of System and Software Stability
3. Evaluation of Manageability under stressful conditions 3. Evaluation of Manageability under stressful conditions
4. Identification of Software Coding bugs such as: 4. Identification of Buffer Overflow conditions
5. Identification of Software Coding bugs such as:
a. Memory Leaks a. Memory Leaks
b. Suboptimal CPU Utilization b. Suboptimal CPU Utilization
c. Coding Logic c. Coding Logic
These benefits produce significant advantages for network operations: These benefits produce significant advantages for network operations:
1. Increased stability of routers and protocols 1. Increased stability of routers and protocols
2. Hardened routers to DoS attacks 2. Hardened routers to DoS attacks
3. Verified manageability under stress 3. Verified manageability under stress
4. Planning router resources for growth and scale 4. Planning router resources for growth and scale
This document provides the Methodology for performing Stress
Benchmarking of networking devices. Descriptions of Test Topology,
Benchmarks and Reporting Format are provided in addition to
procedures for conducting various test cases. The methodology is
to be used with the companion terminology document [6].
2. Existing definitions 2. Existing definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
this document are to be interpreted as described in RFC 2119. document are to be interpreted as described in BCP 14, RFC 2119
[Br97]. RFC 2119 defines the use of these key words to help make the
intent of standards track documents as clear as possible. While this
document uses these keywords, this document is not a standards track
document.
Terms related to Accelerated Stress Benchmarking are defined in [6]. Terms related to Accelerated Stress Benchmarking are defined in [4].
3. Test Setup 3. Test Setup
3.1 Test Topologies 3.1 Test Topologies
Figure 1 shows the physical configuration to be used for the Figure 1 shows the physical configuration to be used for the
methodologies provided in this document. The number of methodologies provided in this document. The number of interfaces
interfaces between the tester and DUT will scale depending upon between the tester and DUT will scale depending upon the number of
the number of control protocol sessions and traffic control protocol sessions and traffic forwarding interfaces. A
forwarding interfaces. A separate device may be required to separate device may be required to externally manage the device in
externally manage the device in the case that the test equipment the case that the test equipment does not support such
does not support such functionality. functionality. Figure 2 shows the logical configuration for the
stress test methodologies. Each plane may be emulated by single or
Figure 2 shows the logical configuration for the stress test
methodologies. Each plane may be emulated by single or
multiple test equipment. multiple test equipment.
3.2 Test Considerations
The Accelerated Stress Benchmarking test can be applied in
service provider test environments to benchmark DUTs under
stress in an environment that is reflective of an operational
network. A particular Configuration Set is defined and the
DUT is benchmarked using this configuration set and the
Instability Conditions. Varying Configuration Sets and/or
Instability Conditions applied in an iterative fashion can
provide an accurate characterization of the DUT
to help determine future network deployments.
___________ ___________
| DUT | | DUT |
___|Management | ___|Management |
| | | | | |
| ----------- | -----------
\/ \/
___________ ___________
| | | |
| DUT | | DUT |
|--->| |<---| |--->| |<---|
skipping to change at page 4, line 24 skipping to change at page 4, line 45
| ----------- | | ----------- |
| | | |
| ___________ | | ___________ |
| | Data | | | | Data | |
|--->| Plane |<---| |--->| Plane |<---|
| | | |
----------- -----------
Figure 2. Logical Configuration Figure 2. Logical Configuration
3.2 Test Considerations
The Accelerated Stress Benchmarking test can be applied in
service provider test environments to benchmark DUTs under
stress in an environment that is reflective of an operational
network. A particular Configuration Set is defined and the
DUT is benchmarked using this configuration set and the
Instability Conditions. Varying Configuration Sets and/or
Instability Conditions applied in an iterative fashion can
provide an accurate characterization of the DUT
to help determine future network deployments.
3.3 Reporting Format 3.3 Reporting Format
Each methodology requires reporting of information for test Each methodology requires reporting of information for test
repeatability when benchmarking the same or different devices. repeatability when benchmarking the same or different devices.
The information that are the Configuration Sets, Instability The information that are the Configuration Sets, Instability
Conditions, and Benchmarks, as defined in [6]. Example Conditions, and Benchmarks, as defined in [4]. Example
reporting formats for each are provided below. reporting formats for each are provided below.
3.3.1 Configuration Sets 3.3.1 Configuration Sets
Example Routing Protocol Configuration Set- Example Routing Protocol Configuration Set-
PARAMETER UNITS PARAMETER UNITS
BGP Enabled/Disabled BGP Enabled/Disabled
Number of EBGP Peers Peers Number of EBGP Peers Peers
Number of IBGP Peers Peers Number of IBGP Peers Peers
Number of BGP Route Instances Routes Number of BGP Route Instances Routes
Number of BGP Installed Routes Routes Number of BGP Installed Routes Routes
skipping to change at page 7, line 47 skipping to change at page 8, line 18
The purpose of this test is to benchmark the performance The purpose of this test is to benchmark the performance
of the DUT during stress conditions when establishing a of the DUT during stress conditions when establishing a
new EBGP Peer from which routes are learned. new EBGP Peer from which routes are learned.
Procedure Procedure
1. Report Configuration Set 1. Report Configuration Set
2. Begin Startup Conditions with the DUT 2. Begin Startup Conditions with the DUT
3. Establish Configuration Sets with the DUT 3. Establish Configuration Sets with the DUT
4. Report benchmarks (for stability) 4. Report benchmarks (for stability)
5. Apply Instability Conditions 5. Apply Instability Conditions
6. Configure new EBGP peering session at DUT and peering router. 6. Configure a new EBGP peering session at DUT and peering router.
Physical and Data Link Layer connectivity SHOULD already exist Physical and Data Link Layer connectivity SHOULD already exist
to perform this step. Establishment of the peering session to perform this step. Establishment of the peering session
SHOULD result in the DUT learning 100,000 or greater routes from MUST result in the DUT learning 100,000 or greater routes from
the BGP peer and advertising 100,000 or greater routes to the BGP peer and advertising 100,000 or greater routes to
the BGP peer the BGP peer
7. Report benchmarks (for instability) 7. Report benchmarks (for instability)
8. Stop applying all Instability Conditions 8. Stop applying all Instability Conditions
9. Report benchmarks (for recovery) 9. Report benchmarks (for recovery)
10. Optional - Change Configuration Set and/or Instability 10. Optional - Change Configuration Set and/or Instability
Conditions for next iteration Conditions for next iteration
Results Results
It is expected that there will be zero packet loss as the DUT It is expected that there will be zero packet loss as the DUT
skipping to change at page 8, line 28 skipping to change at page 8, line 51
Procedure Procedure
1. Report Configuration Set 1. Report Configuration Set
2. Begin Startup Conditions with the DUT 2. Begin Startup Conditions with the DUT
3. Establish Configuration Sets with the DUT 3. Establish Configuration Sets with the DUT
4. Report benchmarks (for stability) 4. Report benchmarks (for stability)
5. Apply Instability Conditions 5. Apply Instability Conditions
6. Advertise 1M BGP routes to the DUT from a single EBGP 6. Advertise 1M BGP routes to the DUT from a single EBGP
neighbor. neighbor.
7. Report benchmarks (for instability) 7. Report benchmarks (for instability)
8. Stop applying all Instability Conditions 8. Stop applying all Instability Conditions, including BGP route
advertisement.
9. Report benchmarks (for recovery) 9. Report benchmarks (for recovery)
10. Optional - Change Configuration Set and/or Instability 10. Optional - Change Configuration Set and/or Instability
Conditions for next iteration Conditions for next iteration
Results Results
It is expected that there will be no additional packet loss from It is expected that there will be no additional packet loss from
the advertisement of routes from the BGP neighbor. Other the advertisement of routes from the BGP neighbor. Other
DUT operation should be stable without session loss. DUT operation should be stable without session loss.
4.4 BGP Policy Configuration 4.4 BGP Policy Configuration
Objective Objective
The purpose of this test is to benchmark the performance The purpose of this test is to benchmark the performance
of the DUT during stress conditions when there is continuous of the DUT during stress conditions when there is continuous
skipping to change at page 9, line 4 skipping to change at page 9, line 26
Procedure Procedure
1. Report Configuration Set 1. Report Configuration Set
2. Begin Startup Conditions with the DUT 2. Begin Startup Conditions with the DUT
3. Establish Configuration Sets with the DUT 3. Establish Configuration Sets with the DUT
4. Report benchmarks (for stability) 4. Report benchmarks (for stability)
5. Apply Instability Conditions 5. Apply Instability Conditions
6. Configure BGP Policy on the DUT for each established neighbor. 6. Configure BGP Policy on the DUT for each established neighbor.
The BGP Policy SHOULD filter 25% of the routes learned from The BGP Policy SHOULD filter 25% of the routes learned from
that neighbor. Note that the specific policy configuration that neighbor. Note that the specific policy configuration
to achieve the filtering may be device specific. to achieve the filtering may be device specific.
7. Every 30 minutes remove the BGP Policy configuration and then 7. Every 30 minutes remove the BGP Policy configuration and then
configure it gain so that it is reapplied. configure it gain so that it is reapplied.
8. Report benchmarks (for instability) 8. Report benchmarks (for instability)
9. Stop applying all Instability Conditions 9. Stop applying all Instability Conditions, including Policy
changes
10. Report benchmarks (for recovery) 10. Report benchmarks (for recovery)
11. Optional - Change Configuration Set and/or Instability 11. Optional - Change Configuration Set and/or Instability
Conditions for next iteration Conditions for next iteration
Results Results
It is expected that there will be no packet loss resulting from It is expected that there will be no packet loss resulting from
the continuous configuration and removal of BGP Policy for BGP the continuous configuration and removal of BGP Policy for BGP
neighbors. Other DUT operation should be stable without session neighbors. Other DUT operation should be stable without session
loss. loss.
skipping to change at page 9, line 34 skipping to change at page 10, line 6
sessions for an infinite period. sessions for an infinite period.
Procedure Procedure
1. Report Configuration Set 1. Report Configuration Set
2. Begin Startup Conditions with the DUT 2. Begin Startup Conditions with the DUT
3. Establish Configuration Sets with the DUT 3. Establish Configuration Sets with the DUT
4. Report benchmarks (for stability) 4. Report benchmarks (for stability)
5. Apply Instability Conditions 5. Apply Instability Conditions
6. Repeatedly flap an IBGP and an EBGP peering session. 6. Repeatedly flap an IBGP and an EBGP peering session.
This SHOULD be achieved by losing physical layer connectivity This SHOULD be achieved by losing physical layer connectivity
via a local fiber pull. Loss of the EBGP peering session SHOULD via a local interface shutdown/no shutdown every 180 seconds with
cause the DUT to withdraw 10,000 or greater routes. Route Flap a delay of 10 seconds between the shut and no shut.
Dampening SHOULD NOT be enabled. The loss of the EBGP peering session MUST cause the DUT to withdraw
100,000 or greater routes that are re-learned when the session
re-establishes. Route Flap Dampening SHOULD NOT be enabled.
7. Report benchmarks (for instability) 7. Report benchmarks (for instability)
8. Stop applying all Instability Conditions 8. Stop applying all Instability Conditions, including flapping
9. Report benchmarks (for recovery) 9. Report benchmarks (for recovery)
10. Optional - Change Configuration Set and/or Instability 10. Optional - Change Configuration Set and/or Instability
Conditions for next iteration Conditions for next iteration
Results Results
It is expected that there will be significant packet loss It is expected that there will be significant packet loss
from repeated convergence events. Other DUT operation should be from repeated Convergence Events. Other DUT operation should be
stable without session loss. Recovery time should not be infinite. stable without session loss. Recovery time should not be infinite.
4.6 DoS Attack 4.6 BGP Route Flap Dampening
Objective
The purpose of this test is to benchmark the performance
of the DUT during stress conditions when flapping BGP Peering
sessions for an infinite period and route flap dampening is
enabled.
Procedure
1. Report Configuration Set
2. Configure Route Flap Dampening on the DUT with DEFAULT parameter
values.
3. Begin Startup Conditions with the DUT
4. Establish Configuration Sets with the DUT
5. Report benchmarks (for stability)
6. Apply Instability Conditions
7. Repeatedly flap an IBGP and an EBGP peering session.
This SHOULD be achieved by losing physical layer connectivity
via a local interface shutdown/no shutdown every 180 seconds with
a delay of 10 seconds between the shut and no shut.
The loss of the EBGP peering session MUST cause the DUT to withdraw
100,000 or greater routes that are re-learned when the session
re-establishes.
8. Report benchmarks (for instability)
9. Stop applying all Instability Conditions
10. Report benchmarks (for recovery)
11. Optional - Change Route Flap Dampening parameter values
12. Optional - Change Configuration Set and/or Instability
Conditions for next iteration
Results
It is expected that there will be significant packet loss
from repeated Convergence Events and flap dampening. Other DUT operation
should be stable without session loss. Recovery time should not be infinite.
4.7 Nested Convergence Events [5]
Objective
The purpose of this test is to benchmark the performance
of the DUT during stress conditions when flapping BGP Peering
sessions causes Nested Convergence Events.
Procedure
1. Report Configuration Set
2. Begin Startup Conditions with the DUT
3. Establish Configuration Sets with the DUT
4. Report benchmarks (for stability)
5. Apply Instability Conditions
6. Repeatedly flap an IBGP and an EBGP peering session.
This SHOULD be achieved by losing physical layer connectivity
via a local interface shutdown/no shutdown every 10 seconds with
a delay of 1 second between the shut and no shut.
The loss of the EBGP peering session MUST cause the DUT to withdraw
100,000 or greater routes that are re-learned when the session
re-establishes. Route Flap Dampening SHOULD NOT be enabled.
7. Report benchmarks (for instability)
8. Stop applying all Instability Conditions, including flapping
9. Report benchmarks (for recovery)
10. Optional - Change Configuration Set and/or Instability
Conditions for next iteration
Results
It is expected that there will be significant packet loss
from Nested Convergence Events. New Other DUT operation should be
stable without session loss. Recovery time should not be infinite.
4.8 Restart Under Load
Objective
The purpose of this test is to benchmark the performance of the DUT
during restart when stress conditions are applied.
Procedure
1. Report Configuration Set
2. Begin Startup Conditions with the DUT
3. Establish Configuration Sets with the DUT
4. Report benchmarks (for stability)
5. Restart DUT. This marks the beginning on the recovery period.
6. Report benchmarks (for recovery)
7. Optional - Change Configuration Set and/or Instability
Conditions for next iteration
NOTE 1: Restart via the DUT's Command Line Interface rather than
power cycle is typically more stressful than power cycle
since hardware can maintain state.
NOTE 2: Instability Conditions are not applied for this test case.
Results
DUT should re-establish all control protocol sessions and have
a Recovery Time [4] that is not infinite.
4.9 Destination Control Processor
Objective
The purpose of this test is to benchmark the performance
of the DUT during stress conditions when traffic is destined for
the Control Processor of the DUT.
Procedure
1. Report Configuration Set
2. Begin Startup Conditions with the DUT
3. Start Configuration Sets with the DUT, except Data Plane
Configuration Set
4. Report benchmarks (for stability)
5. Apply Instability Conditions
6. Send offered load at maximum forwarding rate of DUT interfaces
to all DUT interfaces. Traffic MUST be configured so that the
offered load has a destination address that is the DUT's central
control processor
7. Report benchmarks (for instability)
8. Stop applying all Instability Conditions, including data traffic
9. Report benchmarks (for recovery)
10. Optional - Change Configuration Set and/or Instability
Conditions for next iteration
Results
Results will vary with specific vendor implementations.
It is possible that significant session loss is observed.
4.10 Destination Control Processor with Rate-Limiting
Objective
The purpose of this test is to benchmark the performance
of the DUT during stress conditions when traffic is destined for
the Control processor of the DUT.
Procedure
1. Report Configuration Set
2. Apply policy filter to rate-limit traffic arriving at the Central
Processor to be only 1% of the offered load.
3. Begin Startup Conditions with the DUT
4. Start Configuration Sets with the DUT, except Data Plane
Configuration Set
5. Report benchmarks (for stability)
6. Apply Instability Conditions
7. Send offered load at maximum forwarding rate of DUT interfaces
to all DUT interfaces. Traffic MUST be configured so that the
offered load has a destination address that is the DUT's central
control processor
8. Report benchmarks (for instability)
9. Stop applying all Instability Conditions, including data traffic
10. Report benchmarks (for recovery)
11. Optional - Change Configuration Set and/or Instability
Conditions for next iteration
Results
Results will vary with specific vendor implementations. There should be
no session loss observed.
4.11 Destination Interfaces
Objective
The purpose of this test is to benchmark the performance
of the DUT during stress conditions when traffic is destined for
the interfaces of the DUT.
Procedure
1. Report Configuration Set
2. Begin Startup Conditions with the DUT
3. Start Configuration Sets with the DUT, except Data Plane
Configuration Set
4. Report benchmarks (for stability)
5. Apply Instability Conditions
6. Send offered load at maximum forwarding rate of DUT interfaces
to all DUT interfaces. Traffic MUST be configured so that the
offered load has destination addresses of the interfaces receiving
traffic.
7. Report benchmarks (for instability)
8. Stop applying all Instability Conditions, including data traffic
9. Report benchmarks (for recovery)
10. Optional - Change Configuration Set and/or Instability
Conditions for next iteration
Results
Results will vary with specific vendor implementations.
There should be no session loss observed.
4.12 DoS Attack
Objective Objective
The purpose of this test is to benchmark the performance of the The purpose of this test is to benchmark the performance of the
DUT during stress conditions while experiencing a DoS attack. DUT during stress conditions while experiencing a DoS attack.
Procedure Procedure
1. Report Configuration Set 1. Report Configuration Set
2. Begin Startup Conditions with the DUT 2. Begin Startup Conditions with the DUT
3. Establish Configuration Sets with the DUT 3. Establish Configuration Sets with the DUT
4. Report benchmarks (for stability) 4. Report benchmarks (for stability)
skipping to change at page 10, line 29 skipping to change at page 14, line 38
Results Results
DUT should be able to defend against DoS attack without additional DUT should be able to defend against DoS attack without additional
packet loss or session loss. packet loss or session loss.
5. Security Considerations 5. Security Considerations
Documents of this type do not directly affect the security of Documents of this type do not directly affect the security of
the Internet or of corporate networks as long as benchmarking the Internet or of corporate networks as long as benchmarking
is not performed on devices or systems connected to operating is not performed on devices or systems connected to operating
networks. networks.
6. References 6. Normative References
[1] Bradner, S., Editor, "Benchmarking Terminology for Network [1] Bradner, S., Editor, "Benchmarking Terminology for Network
Interconnection Devices", RFC 1242, October 1991. Interconnection Devices", RFC 1242, February 1991.
[2] Mandeville, R., "Benchmarking Terminology for LAN Switching [2] Mandeville, R., "Benchmarking Terminology for LAN Switching
Devices", RFC 2285, June 1998. Devices", RFC 2285, June 1998.
[3] Bradner, S. and McQuaid, J., "Benchmarking Methodology for [3] Bradner, S. and McQuaid, J., "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999. Network Interconnect Devices", RFC 2544, March 1999.
[4] "Core Router Evaluation for Higher Availability", Scott [4] Poretsky, S. and Rao, S., "Terminology for Accelerated
Stress Benchmarking", draft-ietf-bmwg-acc-bench-term-05,
work in progress, February 2005.
[5] Poretsky, S., "Benchmarking Terminology for IGP Data Plane
Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-05,
work in progress, February 2005.
7. Informative References
[RFC3871] RFC 3871 "Operational Security Requirements for Large
Internet Service Provider (ISP) IP Network Infrastructure.
G. Jones, Ed.. IETF, September 2004.
[NANOG25] "Core Router Evaluation for Higher Availability", Scott
Poretsky, NANOG 25, June 8, 2002, Toronto, CA. Poretsky, NANOG 25, June 8, 2002, Toronto, CA.
[5] "Router Stress Testing to Validate Readiness for Network [IEEECQR] "Router Stress Testing to Validate Readiness for Network
Deployment", Scott Poretsky, IEEE CQR 2003. Deployment", Scott Poretsky, IEEE CQR 2003.
[6] Poretsky, S. and Rao, S., "Terminology for Accelerated [CONVMETH] Poretsky, S., "Benchmarking Methodology for IGP Data Plane
Stress Benchmarking", draft-ietf-bmwg-acc-bench-term-04, Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-meth-05,
work in progress, October 2004. work in progress, February 2005.
7. Author's Address 8. Author's Address
Scott Poretsky Scott Poretsky
Quarry Technologies Quarry Technologies
8 New England Executive Park 8 New England Executive Park
Burlington, MA 01803 Burlington, MA 01803
USA USA
Phone: + 1 781 395 5090 Phone: + 1 781 395 5090
EMail: sporetsky@quarrytech.com EMail: sporetsky@quarrytech.com
skipping to change at page 12, line 17 skipping to change at page 16, line 39
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMA- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMA-
TION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF TION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject to Copyright (C) The Internet Society (2005). This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except as the rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights. set forth therein, the authors retain all their rights.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/