draft-ietf-bmwg-ospfconv-term-08.txt   draft-ietf-bmwg-ospfconv-term-09.txt 
Network Working Group Vishwas Manral Network Working Group Vishwas Manral
Internet Draft Netplane Systems Internet Draft Netplane Systems
Russ White Russ White
Cisco Systems Cisco Systems
Aman Shaikh Aman Shaikh
Expiration Date: November 2004 University of California Expiration Date: December 2004 University of California
File Name: draft-bmwg-ospfconv-term-08.txt May 2004 File Name: draft-bmwg-ospfconv-term-09.txt June 2004
OSPF Benchmarking Terminology and Concepts OSPF Benchmarking Terminology and Concepts
draft-ietf-bmwg-ospfconv-term-08.txt draft-bmwg-ospfconv-term-09.txt
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 other Task Force (IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet Drafts. groups may also distribute working documents as Internet Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 34
other documents at any time. It is not appropriate to use Internet other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working Drafts as reference material or to cite them other than as a "working
draft" or "work in progress". draft" or "work in 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.
Copyright Notice This document may not be modified, and derivative works of it may not
be created, except to publish it as an RFC and to translate it into
Copyright (C) The Internet Society (2002). All Rights Reserved. languages other than English.
Abstract Abstract
This draft explains the terminology and concepts used in OSPF This draft explains the terminology and concepts used in OSPF
benchmarking. While some of these terms may be defined elsewhere, and benchmarking. While some of these terms may be defined elsewhere, and
we will refer the reader to those definitions in some cases, we also we will refer the reader to those definitions in some cases, we also
include discussions concerning these terms as they relate include discussions concerning these terms as they relate
specifically to the tasks involved in benchmarking the OSPF protocol. specifically to the tasks involved in benchmarking the OSPF protocol.
1. Specification of Requirements 1. Specification of Requirements
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 this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
[RFC2119] keywords in this document are used to assure methodological
control, which is very important in the specification of benchmarks.
This document does not specify a network related protocol.
2. Motivation 2. Introduction
This draft is a companion to [BENCHMARK], which describes basic Open This draft is a companion to [BENCHMARK], which describes basic Open
Shortest Path First [OSPF] testing methods. This draft explains Shortest Path First [OSPF] testing methods. This draft explains
terminology and concepts used in OSPF Testing Framework Drafts, such terminology and concepts used in OSPF Testing Framework Drafts, such
as [BENCHMARK]. as [BENCHMARK].
3. Common Definitions 3. Common Definitions
Definitions in this section are well known industry and benchmarking Definitions in this section are well known industry and benchmarking
terms which may be defined elsewhere. terms which may be defined elsewhere.
skipping to change at page 2, line 47 skipping to change at page 3, line 6
ices may not have the required output readily available for ices may not have the required output readily available for
taking internal measurements, as well. taking internal measurements, as well.
Note: White box measurements can be influenced by the Note: White box measurements can be influenced by the
vendor's implementation of the various timers and process- vendor's implementation of the various timers and process-
ing models. Whenever possible, internal measurements should ing models. Whenever possible, internal measurements should
be compared to external measurements to verify and validate be compared to external measurements to verify and validate
them. them.
Because of the potential for variations in collection and Because of the potential for variations in collection and
presentation methods across different DUTs, white box presentation methods across different DUTs, white box meas-
measurements MUST NOT be used as a basis of comparison in urements MUST NOT be used as a basis of comparison in
benchmarks. This has been a guiding principal of Bench- benchmarks. This has been a guiding principal of Bench-
marking Methodology Working Group. marking Methodology Working Group.
o Black Box (External) Measurements o Black Box (External) Measurements
- Definition - Definition
Black Box measurements infer the performance of the DUT Black Box measurements infer the performance of the DUT
through observation of its communications with other dev- through observation of its communications with other dev-
ices. ices.
skipping to change at page 4, line 37 skipping to change at page 4, line 37
See [OSPF], Section 1.2. See [OSPF], Section 1.2.
- Discussion - Discussion
The adjacency formation time on a broadcast link can be The adjacency formation time on a broadcast link can be
more than that on a point-to-point link of the same speed, more than that on a point-to-point link of the same speed,
because DR election has to take place. All routers on a because DR election has to take place. All routers on a
broadcast network form adjacency with the DR and BDR. broadcast network form adjacency with the DR and BDR.
Async flooding also takes place thru the DR. In context of Asynchronous flooding also takes place thru the DR. In con-
convergence, it may take more time for an LSA to be flooded text of convergence, it may take more time for an LSA to be
from one DR-other router to another DR-other router, flooded from one DR-other router to another DR-other
because the LSA has to be first processed at the DR. router, because the LSA has to be first processed at the
DR.
o Shortest Path First Execution Time o Shortest Path First Execution Time
- Definition - Definition
The time taken by a router to complete the SPF process, as The time taken by a router to complete the SPF process, as
described in [OSPF]. described in [OSPF].
- Discussion - Discussion
This does not include the time taken by the router to give This does not include the time taken by the router to give
routes to the forwarding engine. routes to the forwarding engine.
Some implementations may force two intervals, the SPF hold Some implementations may force two intervals, the SPF hold
time and the SPF delay, between successive SPF calcula- time and the SPF delay, between successive SPF calcula-
skipping to change at page 7, line 19 skipping to change at page 7, line 27
o The time it takes for the DUT to make changes in its local rib o The time it takes for the DUT to make changes in its local rib
reflecting the new shortest path tree. reflecting the new shortest path tree.
5.3. Types of Network Events 5.3. Types of Network Events
A network event is an event which causes a change in the network A network event is an event which causes a change in the network
topology. topology.
o Link or Neighbor Device Up o Link or Neighbor Device Up
The time needed for an OSPF implementation to recoginize a new The time needed for an OSPF implementation to recognize a new
link coming up on the device, build any necessarily adjacencies, link coming up on the device, build any necessarily adjacencies,
synchronize its database, and perform all other needed actions synchronize its database, and perform all other needed actions
to converge. to converge.
o Initialization o Initialization
The time needed for an OSPF implementation to be initialized, The time needed for an OSPF implementation to be initialized,
recognize any links across which OSPF must run, build any needed recognize any links across which OSPF must run, build any needed
adjacencies, synchronize its database, and perform other actions adjacencies, synchronize its database, and perform other actions
needed to converge. needed to converge.
o Adjacency Down o Adjacency Down
The time needed for an OSPF implementation to recognize a link The time needed for an OSPF implementation to recognize a link
down/adjacency loss based on hello timers alone, propogate any down/adjacency loss based on hello timers alone, propagate any
information as necessary to its remaining adjacencies, and per- information as necessary to its remaining adjacencies, and per-
form other actions needed to converge. form other actions needed to converge.
o Link Down o Link Down
The time needed for an OSPF implementation to recognize a link The time needed for an OSPF implementation to recognize a link
down based on layer 2 provided information, propogate any infor- down based on layer 2 provided information, propagate any infor-
mation as needed to its remaining adjacencies, and perform other mation as needed to its remaining adjacencies, and perform other
actions needed to converge. actions needed to converge.
6. Security Considerations 6. IANA Considerations
This doecument does not modify the underlying security considerations This document requires no IANA considerations.
7. Security Considerations
This document does not modify the underlying security considerations
in [OSPF]. in [OSPF].
7. Acknowedgements 8. Acknowledgements
The authors would like to thank Howard Berkowitz (hcb@clark.net), The authors would like to thank Howard Berkowitz (hcb@clark.net),
Kevin Dubray, (kdubray@juniper.net), Scott Poretsky Kevin Dubray, (kdubray@juniper.net), Scott Poretsky
(sporetsky@avici.com), and Randy Bush (randy@psg.com) for their dis- (sporetsky@avici.com), and Randy Bush (randy@psg.com) for their dis-
cussion, ideas, and support. cussion, ideas, and support.
8. Normative References 9. Normative References
[BENCHMARK] [BENCHMARK]
Manral, V., "Benchmarking Basic OSPF Single Router Control Plane Manral, V., "Benchmarking Basic OSPF Single Router Control Plane
Convergence", draft-bmwg-ospfconv-intraarea-08, May 2004. Convergence", draft-bmwg-ospfconv-intraarea-09, May 2004.
[OSPF]Moy, J., "OSPF Version 2", RFC 2328, April 1998. [OSPF]Moy, J., "OSPF Version 2", RFC 2328, April 1998.
9. Informative References [RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
10. Informative References
[OSPF-SCALING] [OSPF-SCALING]
Choudhury, Gagan L., Editor, "Prioritized Treatment of Specific Choudhury, Gagan L., Editor, "Prioritized Treatment of Specific
OSPF Packets and Congestion Avoidance", draft-ietf-ospf- OSPF Packets and Congestion Avoidance", draft-ietf-ospf-
scalability-06.txt, August 2003. scalability-06.txt, August 2003.
10. Authors' Addresses 11. Authors' Addresses
Vishwas Manral, Vishwas Manral,
Netplane Systems, Netplane Systems,
189 Prashasan Nagar, 189 Prashasan Nagar,
Road number 72, Road number 72,
Jubilee Hills, Jubilee Hills,
Hyderabad. Hyderabad.
vmanral@netplane.com vmanral@netplane.com
skipping to change at line 341 skipping to change at page 10, line 4
riw@cisco.com riw@cisco.com
Aman Shaikh Aman Shaikh
University of California University of California
School of Engineering School of Engineering
1156 High Street 1156 High Street
Santa Cruz, CA 95064 Santa Cruz, CA 95064
aman@soe.ucsc.edu aman@soe.ucsc.edu
12. Full 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.
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 INFOR-
MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
13. Intellectual Property
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
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
such proprietary rights by implementers or users of this specifica-
tion can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
 End of changes. 

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