idnits 2.17.1 draft-ietf-bmwg-ospfconv-term-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == Mismatching filename: the document gives the document name as 'draft-bmwg-ospfconv-term-08', but the file name used is 'draft-ietf-bmwg-ospfconv-term-08' == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (May 2004) is 7279 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 52, but not defined == Missing Reference: 'OSPF' is mentioned on line 291, but not defined -- No information found for draft-bmwg-ospfconv-intraarea - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'BENCHMARK' == Outdated reference: A later version (-09) exists of draft-ietf-ospf-scalability-06 Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ��� 3 Network Working Group Vishwas Manral 4 Internet Draft Netplane Systems 5 Russ White 6 Cisco Systems 7 Aman Shaikh 8 Expiration Date: November 2004 University of California 9 File Name: draft-bmwg-ospfconv-term-08.txt May 2004 11 OSPF Benchmarking Terminology and Concepts 12 draft-ietf-bmwg-ospfconv-term-08.txt 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its Areas, and its Working Groups. Note that other 21 groups may also distribute working documents as Internet Drafts. 23 Internet Drafts are draft documents valid for a maximum of six 24 months. Internet Drafts may be updated, replaced, or obsoleted by 25 other documents at any time. It is not appropriate to use Internet 26 Drafts as reference material or to cite them other than as a "working 27 draft" or "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http//www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http//www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright (C) The Internet Society (2002). All Rights Reserved. 39 Abstract 41 This draft explains the terminology and concepts used in OSPF 42 benchmarking. While some of these terms may be defined elsewhere, and 43 we will refer the reader to those definitions in some cases, we also 44 include discussions concerning these terms as they relate 45 specifically to the tasks involved in benchmarking the OSPF protocol. 47 1. Specification of Requirements 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in RFC 2119 [RFC2119]. 53 2. Motivation 55 This draft is a companion to [BENCHMARK], which describes basic Open 56 Shortest Path First [OSPF] testing methods. This draft explains 57 terminology and concepts used in OSPF Testing Framework Drafts, such 58 as [BENCHMARK]. 60 3. Common Definitions 62 Definitions in this section are well known industry and benchmarking 63 terms which may be defined elsewhere. 65 o White Box (Internal) Measurements 67 - Definition 69 White Box measurements are measurements reported and col- 70 lected on the Device Under Test (DUT) itself. 72 - Discussion 74 These measurement rely on output and event recording, along 75 with the clocking and timestamping available on the DUT 76 itself. Taking measurements on the DUT may impact the 77 actual outcome of the test, since it can increase processor 78 loading, memory utilization, and timing factors. Some dev- 79 ices may not have the required output readily available for 80 taking internal measurements, as well. 82 Note: White box measurements can be influenced by the 83 vendor's implementation of the various timers and process- 84 ing models. Whenever possible, internal measurements should 85 be compared to external measurements to verify and validate 86 them. 88 Because of the potential for variations in collection and 89 presentation methods across different DUTs, white box 90 measurements MUST NOT be used as a basis of comparison in 91 benchmarks. This has been a guiding principal of Bench- 92 marking Methodology Working Group. 94 o Black Box (External) Measurements 96 - Definition 98 Black Box measurements infer the performance of the DUT 99 through observation of its communications with other dev- 100 ices. 102 - Discussion 104 One example of a black box measurement is when a downstream 105 device receives complete routing information from the DUT, 106 it can be inferred that the DUT has transmitted all the 107 routing information available. External measurements of 108 internal operations may suffer in that they include not 109 just the protocol action times, but also propagation 110 delays, queuing delays, and other such factors. 112 For the purposes of [BENCHMARK], external techniques are 113 more readily applicable. 115 o Multi-device Measurements 117 - Measurements assessing communications (usually in combina- 118 tion with internal operations) between two or more DUTs. 119 Multi-device measurements may be internal or external. 121 4. Terms Defined Elsewhere 123 Terms in this section are defined elsewhere, and included only to 124 include a discussion of those terms in reference to [BENCHMARK]. 126 o Point-to-Point links 128 - Definition 130 See [OSPF], Section 1.2. 132 - Discussion 134 A point-to-point link can take lesser time to converge than 135 a broadcast link of the same speed because it does not have 136 the overhead of DR election. Point-to-point links can be 137 either numbered or unnumbered. However in the context of 138 [BENCHMARK] and [OSPF], the two can be regarded the same. 140 o Broadcast Link 142 - Definition 144 See [OSPF], Section 1.2. 146 - Discussion 148 The adjacency formation time on a broadcast link can be 149 more than that on a point-to-point link of the same speed, 150 because DR election has to take place. All routers on a 151 broadcast network form adjacency with the DR and BDR. 153 Async flooding also takes place thru the DR. In context of 154 convergence, it may take more time for an LSA to be flooded 155 from one DR-other router to another DR-other router, 156 because the LSA has to be first processed at the DR. 158 o Shortest Path First Execution Time 160 - Definition 161 The time taken by a router to complete the SPF process, as 162 described in [OSPF]. 164 - Discussion 166 This does not include the time taken by the router to give 167 routes to the forwarding engine. 169 Some implementations may force two intervals, the SPF hold 170 time and the SPF delay, between successive SPF calcula- 171 tions. If an SPF hold time exists, it should be subtracted 172 from the total SPF execution time. If an SPF delay exists, 173 it should be noted in the test results. 175 - Measurement Units 177 The SPF time is generally measured in milliseconds. 179 o Hello Interval 181 - Definition 183 See [OSPF], Section 7.1. 185 - Discussion 187 The hello interval should be the same for all routers on a 188 network. 190 Decreasing the hello interval can allow the router dead 191 interval (below) to be reduced, thus reducing convergence 192 times in those situations where the router dead interval 193 timing out causes an OSPF process to notice an adjacency 194 failure. Further discussion on small hello intervals is 195 given in [OSPF-SCALING]. 197 o Router Dead interval 199 - Definition 201 See [OSPF], Section 7.1. 203 - Discussion 205 This is advertised in the router's Hello Packets in the Router- 206 DeadInterval field. The router dead interval should be some mul- 207 tiple of the HelloInterval (say 4 times the hello interval), and 208 must be the same for all routers attached to a common network. 210 5. Concepts 212 5.1. The Meaning of Single Router Control Plane Convergence 214 A network is termed to be converged when all of the devices within 215 the network have a loop free path to each possible destination. Since 216 we are not testing network convergence, but performance for a partic- 217 ular device within a network, however, this definition needs to be 218 narrowed somewhat to fit within a single device view. 220 In this case, convergence will mean the point in time when the DUT 221 has performed all actions needed to react to the change in topology 222 represented by the test condition; for instance, an OSPF device must 223 flood any new information it has received, rebuild its shortest path 224 first (SPF) tree, and install any new paths or destinations in the 225 local routing information base (RIB, or routing table). 227 Note that the word convergence has two distinct meanings; the process 228 of a group of individuals meeting the same place, and the process of 229 a single individual meeting in the same place as an existing group. 230 This work focuses on the second meaning of the word, so we consider 231 the time required for a single device to adapt to a network change to 232 be Single Router Convergence. 234 This concept does not include the time required for the control plane 235 of the device to transfer the information required to forward packets 236 to the data plane, nor the amount of time between the data plane 237 receiving that information and being able to actually forward 238 traffic. 240 5.2. Measuring Convergence 242 Obviously, there are several elements to convergence, even under the 243 definition given above for a single device, including (but not lim- 244 ited to): 246 o The time it takes for the DUT to pass the information about a 247 network event on to its neighbors. 249 o The time it takes for the DUT to process information about a 250 network event and calculate a new Shortest Path Tree (SPT). 252 o The time it takes for the DUT to make changes in its local rib 253 reflecting the new shortest path tree. 255 5.3. Types of Network Events 257 A network event is an event which causes a change in the network 258 topology. 260 o Link or Neighbor Device Up 262 The time needed for an OSPF implementation to recoginize a new 263 link coming up on the device, build any necessarily adjacencies, 264 synchronize its database, and perform all other needed actions 265 to converge. 267 o Initialization 269 The time needed for an OSPF implementation to be initialized, 270 recognize any links across which OSPF must run, build any needed 271 adjacencies, synchronize its database, and perform other actions 272 needed to converge. 274 o Adjacency Down 276 The time needed for an OSPF implementation to recognize a link 277 down/adjacency loss based on hello timers alone, propogate any 278 information as necessary to its remaining adjacencies, and per- 279 form other actions needed to converge. 281 o Link Down 283 The time needed for an OSPF implementation to recognize a link 284 down based on layer 2 provided information, propogate any infor- 285 mation as needed to its remaining adjacencies, and perform other 286 actions needed to converge. 288 6. Security Considerations 290 This doecument does not modify the underlying security considerations 291 in [OSPF]. 293 7. Acknowedgements 295 The authors would like to thank Howard Berkowitz (hcb@clark.net), 296 Kevin Dubray, (kdubray@juniper.net), Scott Poretsky 297 (sporetsky@avici.com), and Randy Bush (randy@psg.com) for their dis- 298 cussion, ideas, and support. 300 8. Normative References 302 [BENCHMARK] 303 Manral, V., "Benchmarking Basic OSPF Single Router Control Plane 304 Convergence", draft-bmwg-ospfconv-intraarea-08, May 2004. 306 [OSPF]Moy, J., "OSPF Version 2", RFC 2328, April 1998. 308 9. Informative References 310 [OSPF-SCALING] 311 Choudhury, Gagan L., Editor, "Prioritized Treatment of Specific 312 OSPF Packets and Congestion Avoidance", draft-ietf-ospf- 313 scalability-06.txt, August 2003. 315 10. Authors' Addresses 317 Vishwas Manral, 318 Netplane Systems, 319 189 Prashasan Nagar, 320 Road number 72, 321 Jubilee Hills, 322 Hyderabad. 324 vmanral@netplane.com 326 Russ White 327 Cisco Systems, Inc. 328 7025 Kit Creek Rd. 330 Research Triangle Park, NC 27709 332 riw@cisco.com 334 Aman Shaikh 335 University of California 336 School of Engineering 337 1156 High Street 338 Santa Cruz, CA 95064 340 aman@soe.ucsc.edu