draft-ietf-bmwg-igp-dataplane-conv-meth-06.txt   draft-ietf-bmwg-igp-dataplane-conv-meth-07.txt 
Network Working Group Network Working Group
INTERNET-DRAFT INTERNET-DRAFT
Expires in: December 2005 Expires in: January 2006
Scott Poretsky Scott Poretsky
Quarry Technologies Reef Point Systems
Brent Imhoff Brent Imhoff
LightCore LightCore
June 2005 July 2005
Benchmarking Methodology for Benchmarking Methodology for
IGP Data Plane Route Convergence IGP Data Plane Route Convergence
<draft-ietf-bmwg-igp-dataplane-conv-meth-06.txt> <draft-ietf-bmwg-igp-dataplane-conv-meth-07.txt>
Intellectual Property Rights (IPR) statement: Intellectual Property Rights (IPR) statement:
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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 June also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and June be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
skipping to change at page 2, line 48 skipping to change at page 2, line 48
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]. These methodologies apply to IPv4 and IPv6 traffic and OSPF [4]. These methodologies apply to IPv4 and IPv6 traffic
as well as IPv4 and IPv6 IGPs. 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", "JUNE", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, 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 [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 intent of standards track documents as clear as possible. While this
document uses these keywords, this document is not a standards track document uses these keywords, this document is not a standards track
document. 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
skipping to change at page 4, line 54 skipping to change at page 4, line 54
for Parallel Link Convergence for Parallel Link Convergence
3.2 Test Considerations 3.2 Test Considerations
3.2.1 IGP Selection 3.2.1 IGP Selection
The test cases described in section 4 can be used for ISIS or The test cases described in section 4 can be used for ISIS or
OSPF. The Route Convergence test methodology for both is OSPF. The Route Convergence test methodology for both is
identical. The IGP adjacencies are established on the Preferred identical. The IGP adjacencies are established on the Preferred
Egress Interface and Next-Best Egress Interface. Egress Interface and Next-Best Egress Interface.
3.2.2 BGP Configuration 3.2.2 BGP Configuration
The obtained results for IGP Route Convergence June vary if The obtained results for IGP Route Convergence may vary if
BGP routes are installed. It is recommended that the IGP BGP routes are installed. It is recommended that the IGP
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
skipping to change at page 5, line 44 skipping to change at page 5, line 44
preferred benchmark for IGP Route Convergence. This benchmark preferred benchmark for IGP Route Convergence. This benchmark
must always be reported when the Packet Sampling Interval [2] must always be reported when the Packet Sampling Interval [2]
<= 100 milliseconds. If the test equipment does not permit <= 100 milliseconds. If the test equipment does not permit
the Packet Sampling Interval to be set as low as 100 msec, the Packet Sampling Interval to be set as low as 100 msec,
then both the Rate-Derived Convergence Time and Loss-Derived then both the Rate-Derived Convergence Time and Loss-Derived
Convergence Time [2] must be reported. The Packet Sampling Convergence Time [2] must be reported. The Packet Sampling
Interval value MUST be the smallest measurable convergence Interval value MUST be the smallest measurable convergence
time. time.
3.2.6 Interface Types 3.2.6 Interface Types
All test cases in this methodology document June be executed with All test cases in this methodology document may be executed with
any interface type. All interfaces MUST be the same media and any interface type. All interfaces MUST be the same media and
Throughout [5,6] for each test case. Media and protocols MUST Throughout [5,6] for each test case. Media and protocols MUST
be configured for minimum failure detection delay to minimize be configured for minimum failure detection delay to minimize
the contribution to the measured Convergence time. For example, the contribution to the measured Convergence time. For example,
configure SONET with minimum carrier-loss-delay or Bi-directional configure SONET with minimum carrier-loss-delay or Bi-directional
Forwarding Detection (BFD) [7]. Forwarding Detection (BFD) [7].
IGP Data Plane Route Convergence IGP Data Plane Route Convergence
3.2.7 Offered Load 3.2.7 Offered Load
skipping to change at page 13, line 25 skipping to change at page 13, line 25
link failure indication, Tree Build Time, and Hardware Update Time. link failure 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. Normative 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-06, work Convergence", draft-ietf-bmwg-igp-dataplane-conv-app-07, work
in progress, June 2005. in progress, July 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-06, work Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-07, work
in progress, June 2005 in progress, July 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, IETF, December 1990. Environments", RFC 1195, IETF, December 1990.
[4] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. [4] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998.
[5] Bradner, S., "Benchmarking Terminology for Network Interconnection [5] Bradner, S., "Benchmarking Terminology for Network Interconnection
Devices", RFC 1242, IETF, July 1991. Devices", RFC 1242, IETF, July 1991.
[6] Bradner, S. and McQuaid, J., "Benchmarking Methodology for [6] Bradner, S. and McQuaid, J., "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, IETF, March 1999. Network Interconnect Devices", RFC 2544, IETF, March 1999.
[7] Katz, D. and Ward, D., "Bidirectional Forwarding Detection", [7] Katz, D. and Ward, D., "Bidirectional Forwarding Detection",
draft-ietf-bfd-base-02.txt, work in progress, IETF, draft-ietf-bfd-base-02.txt, work in progress, IETF,
March 2005. March 2005.
7. Author's Address 7. Author's Address
Scott Poretsky Scott Poretsky
Quarry Technologies Reef Point Systems
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
IGP Data Plane Route Convergence IGP Data Plane Route Convergence
Brent Imhoff Brent Imhoff
LightCore LightCore
skipping to change at page 14, line 47 skipping to change at page 14, line 47
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that June cover technology that June be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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