draft-ietf-bmwg-igp-dataplane-conv-meth-02.txt   draft-ietf-bmwg-igp-dataplane-conv-meth-03.txt 
Network Working Group Network Working Group
INTERNET-DRAFT INTERNET-DRAFT
Expires in: July 2004 Expires in: January 2005
Scott Poretsky Scott Poretsky
Quarry Technologies Quarry Technologies
Brent Imhoff Brent Imhoff
Wiltel Communications
January 2004 July 2004
Benchmarking Methodology for Benchmarking Methodology for
IGP Data Plane Route Convergence IGP Data Plane Route Convergence
<draft-ietf-bmwg-igp-dataplane-conv-meth-02.txt> <draft-ietf-bmwg-igp-dataplane-conv-meth-03.txt>
Intellectual Property Rights (IPR) statement:
By submitting this Internet-Draft, I certify that any applicable
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,
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
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 49 skipping to change at page 2, line 5
ABSTRACT ABSTRACT
This draft describes the methodology for benchmarking IGP Route This draft describes the methodology for benchmarking IGP Route
Convergence as described in Applicability document [1] and Convergence as described in Applicability document [1] and
Terminology document [2]. The methodology and terminology are Terminology document [2]. The methodology and terminology are
to be used for benchmarking route convergence and can be applied to be used for benchmarking route convergence and can be applied
to any link-state IGP such as ISIS [3] and OSPF [4]. The terms to any link-state IGP such as ISIS [3] and OSPF [4]. The terms
used in the procedures provided within this document are used in the procedures provided within this document are
defined in [2]. defined in [2].
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.1 IGP Selection............................................4
IGP Data Plane Route Convergence
3.2.2 BGP Configuration........................................4 3.2.2 BGP Configuration........................................4
3.2.3 IGP Route Scaling........................................5 3.2.3 IGP Route Scaling........................................5
3.2.4 Timers...................................................5 3.2.4 Timers...................................................5
3.2.5 Convergence Time Metrics.................................5 3.2.5 Convergence Time Metrics.................................5
3.2.6 Offered Load.............................................5 3.2.6 Offered Load.............................................5
3.2.7 Interface Types..........................................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
skipping to change at page 2, line 27 skipping to change at page 2, line 35
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 PPP Session Failure.....................8 4.2 Convergence Due to PPP 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. References..................................................12
7. Author's Address............................................12 7. Author's Address............................................12
8. Full Copyright Statement....................................13
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].
2. Existing definitions 2. Existing definitions
For the sake of clarity and continuity this RFC adopts the template
for definitions set out in Section 2 of RFC 1242. Definitions are
indexed and grouped together in sections for ease of reference.
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 document are to be interpreted as described in RFC 2119. this document are to be interpreted as described in RFC 2119.
Terms related to IGP Convergence are defined in [2].
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, PPP Session to local Convergence Events such as SONET Link Failure, PPP 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
skipping to change at page 3, line 55 skipping to change at page 3, line 55
^ | | Egress Interface | | ^ | | Egress Interface | |
| ----- ----------- | ----- -----------
| | | |
|-------------------------------------- |--------------------------------------
Ingress Interface Ingress Interface
Figure 2. IGP Route Convergence Test Topology Figure 2. IGP Route Convergence Test Topology
for Remote Changes for Remote Changes
Figure 3 shows the test topology to measure IGP Route Convergence Figure 3 shows the test topology to measure IGP Route Convergence
time with members of an ECMP Set. These times are measured by time with members of an Equal Cost Multipath (ECMP) Set. These times are
observing packet loss in the data plane. In this topology, the DUT measured by observing packet loss in the data plane. In this topology,
the DUT
IGP Data Plane Route Convergence IGP Data Plane Route Convergence
is configured with each Egress interface as a member of an ECMP set is configured with each Egress interface as a member of an ECMP set
and the Tester emulates multiple next-hop routers (emulates one and the Tester emulates multiple next-hop routers (emulates one
router for each member). router for each member).
--------- Ingress Interface --------- --------- Ingress Interface ---------
| |<--------------------------------| | | |<--------------------------------| |
| | | | | | | |
| | ECMP Set Interface 1 | | | | ECMP Set Interface 1 | |
skipping to change at page 5, line 13 skipping to change at page 5, line 13
Convergence times be benchmarked without BGP routes installed. Convergence times be benchmarked without BGP routes installed.
IGP Data Plane Route Convergence IGP Data Plane Route Convergence
3.2.3 IGP Route Scaling 3.2.3 IGP Route Scaling
The number of IGP routes will impact the measured IGP Route The number of IGP routes will impact the measured IGP Route
Convergence because convergence for the entire IGP route table is Convergence because convergence for the entire IGP route table is
measured. For results similar to those that would be observed in measured. For results similar to those that would be observed in
an operational network it is recommended that the number of an operational network it is recommended that the number of
installed routes closely approximate that for routers in the installed routes closely approximate that for routers in the
network. network. The number of areas (for OSPF) and levels (for ISIS) can
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 SONET Failure Indication Delay <10milliseconds
IGP Hello Timer 1 second IGP Hello Timer 1 second
skipping to change at page 5, line 44 skipping to change at page 5, line 45
must always be reported when the must always be reported when the
Packet Sampling Interval [2] <= 100 milliseconds. Packet Sampling Interval [2] <= 100 milliseconds.
If the test equipment does not permit the Packet Sampling If the test equipment does not permit the Packet Sampling
Interval to be set as low as 100 msec, then both the Interval to be set as low as 100 msec, then both the
Rate-Derived Convergence Time and Loss-Derived Convergence Rate-Derived Convergence Time and Loss-Derived Convergence
Time [2] must be reported. Time [2] must be reported.
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. The duration of offered
load must be greater than the convergence time. load must be greater 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. SONET is recommended and specifically
mentioned in the procedures because it can be configured to have mentioned in the procedures because it can be configured to have
no or negligible affect on the measured convergence time. no or negligible affect on the measured convergence time.
Ethernet (10Mb, 100Mb, 1Gb, and 10Gb) is not preferred since Ethernet (10Mb, 100Mb, 1Gb, and 10Gb) is not preferred since
broadcast media are unable to detect loss of host and rely upon broadcast media are unable to detect loss of host and rely upon
IGP Hellos to detect session loss. IGP Hellos to detect session loss.
skipping to change at page 12, line 17 skipping to change at page 12, line 17
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. References
[1] Poretsky, S., "Benchmarking Applicability for IGP [1] Poretsky, S., "Benchmarking Applicability for IGP
Convergence", draft-ietf-bmwg-igp-dataplane-conv-app-02, work Convergence", draft-ietf-bmwg-igp-dataplane-conv-app-03, work
in progress, January 2004. in progress, July 2004.
[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-02, work Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-03, work
in progress, January 2004 in progress, July 2004
[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
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
Brent Imhoff Brent Imhoff
WilTel Communications
3180 Rider Trail South
Bridgeton, MO 63045
USA USA
EMail: bimhoff@planetspork.com
Phone: +1 314 595 6853
EMail: brent.imhoff@wcg.com
IGP Data Plane Route Convergence IGP Data Plane Route Convergence
8. Full Copyright Statement Intellectual Property Statement
Copyright (C) The Internet Society (1998). All Rights
Reserved.
This document and translations of it may be copied and The IETF takes no position regarding the validity or scope of any Intel-
furnished to others, and derivative works that comment on or lectual Property Rights or other rights that might be claimed to pertain
otherwise explain it or assist in its implementation may be to the implementation or use of the technology described in this docu-
prepared, copied, published and distributed, in whole or in ment or the extent to which any license under such rights might or might
part, without restriction of any kind, provided that the above not be available; nor does it represent that it has made any independent
copyright notice and this paragraph are included on all such effort to identify any such rights. Information on the procedures with
copies and derivative works. However, this document itself may respect to rights in RFC documents can be found in BCP 78 and BCP 79.
not be modified in any way, such as by removing the copyright
notice or references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will Copies of IPR disclosures made to the IETF Secretariat and any
not be revoked by the Internet Society or its successors or assurances of licenses to be made available, or the result of an attempt
assigns. This document and the information contained herein is made to obtain a general license or permission for the use of such
provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE proprietary rights by implementers or users of this specification can be
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, obtained from the IETF on-line IPR repository at
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY http://www.ietf.org/ipr.
THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS The IETF invites any interested party to bring to its attention any
FOR A PARTICULAR PURPOSE. copyrights, patents or patent applications, or other proprietary rights
that may cover technology that may be required to implement this stan-
dard. Please address the information to the IETF at ietf-ipr@ietf.org.
Disclaimer of Warranty
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
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
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except as
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/