draft-ietf-bmwg-igp-dataplane-conv-meth-04.txt   draft-ietf-bmwg-igp-dataplane-conv-meth-05.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
Brent Imhoff Brent Imhoff
LightCore LightCore
October 2004 February 2005
Benchmarking Methodology for Benchmarking Methodology for
IGP Data Plane Route Convergence IGP Data Plane Route Convergence
<draft-ietf-bmwg-igp-dataplane-conv-meth-04.txt> <draft-ietf-bmwg-igp-dataplane-conv-meth-05.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 2, line 13 skipping to change at page 2, line 13
defined in [2]. defined in [2].
IGP Data Plane Route Convergence IGP Data Plane Route Convergence
Table of Contents Table of Contents
1. Introduction ...............................................2 1. Introduction ...............................................2
2. Existing definitions .......................................2 2. Existing definitions .......................................2
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........................................4
3.2.1 IGP Selection............................................4
3.2.2 BGP Configuration........................................4
3.2.3 IGP Route Scaling........................................5
3.2.4 Timers...................................................5
3.2.5 Convergence Time Metrics.................................5
3.2.6 Offered Load.............................................5
3.2.7 Interface Types..........................................5
3.3 Reporting Format...........................................6 3.3 Reporting Format...........................................6
4. Test Cases..................................................6 4. Test Cases..................................................6
4.1 Convergence Due to Link Failure............................6 4.1 Convergence Due to Link Failure............................6
4.1.1 Convergence Due to Local Interface Failure...............6 4.1.1 Convergence Due to Local Interface Failure...............6
4.1.2 Convergence Due to Neighbor Interface Failure............7 4.1.2 Convergence Due to Neighbor Interface Failure............7
4.1.3 Convergence Due to Remote Interface Failure..............7 4.1.3 Convergence Due to Remote Interface Failure..............7
4.2 Convergence Due to Layer 2 Session Failure.................8 4.2 Convergence Due to Layer 2 Session Failure.................8
4.3 Convergence Due to IGP Adjacency Failure...................9 4.3 Convergence Due to IGP Adjacency Failure...................9
4.4 Convergence Due to Route Withdrawal........................9 4.4 Convergence Due to Route Withdrawal........................9
4.5 Convergence Due to Cost Change.............................10 4.5 Convergence Due to Cost Change.............................10
4.6 Convergence Due to ECMP Member Interface Failure...........10 4.6 Convergence Due to ECMP Member Interface Failure...........10
4.7 Convergence Due to Parallel Link Interface Failure.........11 4.7 Convergence Due to Parallel Link Interface Failure.........11
5. Security Considerations.....................................12 5. Security Considerations.....................................12
6. References..................................................12 6. Normative References........................................12
7. Author's Address............................................12 7. Author's Address............................................12
1. Introduction 1. Introduction
This draft describes the methodology for benchmarking IGP Route This draft describes the methodology for benchmarking IGP Route
Convergence. The applicability of this testing is described in Convergence. The applicability of this testing is described in
[1] and the new terminology that it introduces is defined in [2]. [1] and the new terminology that it introduces is defined in [2].
Service Providers use IGP Convergence time as a key metric of Service Providers use IGP Convergence time as a key metric of
router design and architecture. Customers of Service Providers router design and architecture. Customers of Service Providers
observe convergence time by packet loss, so IGP Route Convergence observe convergence time by packet loss, so IGP Route Convergence
is considered a Direct Measure of Quality (DMOQ). The test cases is considered a Direct Measure of Quality (DMOQ). The test cases
in this document are black-box tests that emulate the network in this document are black-box tests that emulate the network
events that cause route convergence, as described in [1]. The events that cause route convergence, as described in [1]. The
black-box test designs benchmark the data plane accounting for black-box test designs benchmark the data plane accounting for
all of the factors contributing to convergence time, as discussed all of the factors contributing to convergence time, as discussed
in [1]. The methodology (and terminology) for benchmarking route in [1]. The methodology (and terminology) for benchmarking route
convergence can be applied to any link-state IGP such as ISIS [3] convergence can be applied to any link-state IGP such as ISIS [3]
and OSPF [4]. and OSPF [4]. These methodologies apply to IPv4 and IPv6 traffic
as well as IPv4 and IPv6 IGPs.
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
Terms related to IGP Convergence are defined in [2]. [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.
IGP Data Plane Route Convergence IGP Data Plane Route Convergence
3. Test Setup 3. Test Setup
3.1 Test Topologies 3.1 Test Topologies
Figure 1 shows the test topology to measure IGP Route Convergence due Figure 1 shows the test topology to measure IGP Route Convergence due
to local Convergence Events such as SONET Link Failure, Layer 2 Session to local Convergence Events such as SONET Link Failure, Layer 2 Session
Failure, IGP Adjacency Failure, Route Withdrawal, and route cost Failure, IGP Adjacency Failure, Route Withdrawal, and route cost
change. These test cases discussed in section 4 provide route change. These test cases discussed in section 4 provide route
convergence times that account for the Event Detection time, SPF convergence times that account for the Event Detection time, SPF
skipping to change at page 5, line 23 skipping to change at page 5, line 23
network. The number of areas (for OSPF) and levels (for ISIS) can network. The number of areas (for OSPF) and levels (for ISIS) can
impact the benchmark results. impact the benchmark results.
3.2.4 Timers 3.2.4 Timers
There are some timers that will impact the measured IGP Convergence There are some timers that will impact the measured IGP Convergence
time. The following timers should be configured to the minimum value time. The following timers should be configured to the minimum value
prior to beginning execution of the test cases: prior to beginning execution of the test cases:
Timer Recommended Value Timer Recommended Value
----- ----------------- ----- -----------------
SONET Failure Indication Delay <10milliseconds Failure Indication Delay <10milliseconds
IGP Hello Timer 1 second IGP Hello Timer 1 second
IGP Dead-Interval 3 seconds IGP Dead-Interval 3 seconds
LSA Generation Delay 0 LSA Generation Delay 0
LSA Flood Packet Pacing 0 LSA Flood Packet Pacing 0
LSA Retransmission Packet Pacing 0 LSA Retransmission Packet Pacing 0
SPF Delay 0 SPF Delay 0
3.2.5 Convergence Time Metrics 3.2.5 Convergence Time Metrics
The recommended value for the Packet Sampling Interval [2] is The recommended value for the Packet Sampling Interval [2] is
100 milliseconds. Rate-Derived Convergence Time [2] is the 100 milliseconds. Rate-Derived Convergence Time [2] is the
preferred benchmark for IGP Route Convergence. This benchmark preferred benchmark for IGP Route Convergence. This benchmark
must always be reported when the must always be reported when the Packet Sampling Interval [2]
Packet Sampling Interval [2] <= 100 milliseconds. <= 100 milliseconds. If the test equipment does not permit
If the test equipment does not permit the Packet Sampling the Packet Sampling Interval to be set as low as 100 msec,
Interval to be set as low as 100 msec, then both the then both the Rate-Derived Convergence Time and Loss-Derived
Rate-Derived Convergence Time and Loss-Derived Convergence Convergence Time [2] must be reported. The Packet Sampling
Time [2] must be reported. Interval value is the smallest measurable convergence time.
3.2.6 Offered Load 3.2.6 Offered Load
An offered Load of maximum forwarding rate at a fixed packet size An offered Load of maximum forwarding rate at a fixed packet size
is recommended for accurate measurement. The duration of offered is recommended for accurate measurement. Forwarding Rate must be
load must be greater than the convergence time. The destinations measured at the Preferred Egress Interface and the Next-Best
for the offered load must be distributed such that all routes are Egress Interface. The duration of offered load must be greater
matched. This enables Full Convergence [2] to be observed. than the convergence time. The destinations for the offered load
must be distributed such that all routes are matched. This
enables Full Convergence [2] to be observed.
3.2.7 Interface Types 3.2.7 Interface Types
All test cases in this methodology document may be executed with All test cases in this methodology document may be executed with
any interface type. SONET is recommended and specifically any interface type. All interfaces MUST BE the same media and
mentioned in the procedures because it can be configured to have link speed for each test case. Media and protocols MUST be
no or negligible affect on the measured convergence time. configured for minimum failure detection delay to minimize the
Ethernet (10Mb, 100Mb, 1Gb, and 10Gb) is not preferred since contribution to the measured Convergence time. For example,
broadcast media are unable to detect loss of host and rely upon configure SONET with minimum carrier-loss-delay.
IGP Hellos to detect session loss.
IGP Data Plane Route Convergence IGP Data Plane Route Convergence
3.3 Reporting Format 3.3 Reporting Format
For each test case, it is recommended that the following reporting For each test case, it is recommended that the following reporting
format be completed: format be completed:
Parameter Units Parameter Units
--------- ----- --------- -----
IGP (ISIS or OSPF) IGP (ISIS or OSPF)
skipping to change at page 12, line 22 skipping to change at page 12, line 22
The measured IGP Convergence time is influenced by the Local The measured IGP Convergence time is influenced by the Local
SONET indication, Tree Build Time, and Hardware Update Time. SONET indication, Tree Build Time, and Hardware Update Time.
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 corporate networks as long as benchmarking the Internet or 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] Poretsky, S., "Benchmarking Applicability for IGP [1] Poretsky, S., "Benchmarking Applicability for IGP
Convergence", draft-ietf-bmwg-igp-dataplane-conv-app-04, work Convergence", draft-ietf-bmwg-igp-dataplane-conv-app-05, work
in progress, October 2004. in progress, February 2005.
[2] Poretsky, S., Imhoff, B., "Benchmarking Terminology for IGP [2] Poretsky, S., Imhoff, B., "Benchmarking Terminology for IGP
Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-04, work Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-05, work
in progress, October 2004 in progress, February 2005
[3] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual [3] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual
Environments", RFC 1195, December 1990. Environments", RFC 1195, December 1990.
[4] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. [4] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998.
7. Author's Address 7. Author's Address
Scott Poretsky Scott Poretsky
Quarry Technologies Quarry Technologies
skipping to change at page 13, line 40 skipping to change at page 13, line 40
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/