idnits 2.17.1 draft-ietf-bmwg-ospfconv-term-05.txt: ** The Abstract section seems to be numbered 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 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 8 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 a Security Considerations 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.) ** The abstract seems to contain references ([BENCHMARK]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2003) is 7619 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 section? 'BENCHMARK' on line 281 looks like a reference -- Missing reference section? 'OSPF' on line 184 looks like a reference -- Missing reference section? 'CONGESTION' on line 289 looks like a reference -- Missing reference section? 'MARKING' on line 293 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Vishwas Manral 3 Internet Draft Netplane Systems 4 Russ White 5 Cisco Systems 6 Aman Shaikh 7 Expiration Date: December 2003 University of California 8 File Name: draft-ietf-bmwg-ospfconv-term-05.txt June 2003 10 OSPF Benchmarking Terminology and Concepts 11 draft-ietf-bmwg-ospfconv-term-05.txt 13 1. Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its Areas, and its Working Groups. Note that other 20 groups may also distribute working documents as Internet Drafts. 22 Internet Drafts are draft documents valid for a maximum of six 23 months. Internet Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet 25 Drafts as reference material or to cite them other than as a "working 26 draft" or "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http//www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http//www.ietf.org/shadow.html. 34 2. Abstract 36 This draft explains the terminology and concepts used in [BENCHMARK] 37 and future OSPF benchmarking drafts, within the context of those 38 drafts. While some of these terms may be defined elsewhere, and we 39 will refer the reader to those definitions in some cases, we also 40 include discussions concerning these terms as they relate 41 specifically to the tasks involved in benchmarking the OSPF protocol. 43 3. Motivation 45 This draft is a companion to [BENCHMARK], which describes basic Open 46 Shortest Path First [OSPF] testing methods. This draft explains 47 terminology and concepts used in OSPF Testing Framework Drafts, such 48 as [BENCHMARK]. 50 4. Common Definitions 52 Definitions in this section are well known industry and benchmarking 53 terms which may be defined elsewhere. 55 o White Box (Internal) Measurements 57 - Definition 59 White Box measurements are measurements taken on the Dev- 60 ice Under Test (DUT) itself. 62 - Discussion 64 These measurement rely on output and event recording, 65 along with the clocking and timestamping available on the 66 DUT itself. Taking measurements on the DUT may impact the 67 actual outcome of the test, since it can increase proces- 68 sor loading, memory utilization, and timing factors. Some 69 devices may not have the required output readily available 70 for taking internal measurements, as well. 72 Note: White box measurements can be influenced by the 73 vendor's implementation of the various timers and process- 74 ing models. Whenever possible, internal measurements 75 should be compared to external measurements to verify and 76 validate them. 78 o Black Box (External) Measurements 80 - Definition 82 Black Box measurements infer the performance of the DUT 83 through observation of its communications with other dev- 84 ices. 86 - Discussion 88 One example of a black box measurement is when a down- 89 stream device receives complete routing information from 90 the DUT, it can be inferred that the DUT has transmitted 91 all the routing information available. External measure- 92 ments suffer in that they include not just the protocol 93 action times, but also propagation delays, queuing delays, 94 and other such factors. 96 For the purposes of [BENCHMARK], external techniques are 97 more readily applicable. 99 o Multi-device Measurements 101 5. Terms Defined Elsewhere 103 Terms in this section are defined elsewhere, and included only to 104 include a discussion of those terms in reference to [BENCHMARK]. 106 o Point-to-Point links 108 - Definition 110 See [OSPF], Section 1.2. 112 - Discussion 114 A point-to-point link can take lesser time to converge 115 than a broadcast link of the same speed because it does 116 not have the overhead of DR election. Point-to-point links 117 can be either numbered or unnumbered. However in the con- 118 text of [BENCHMARK] and [OSPF], the two can be regarded 119 the same. 121 o Broadcast Link 123 - Definition 125 See [OSPF], Section 1.2. 127 - Discussion 129 The adjacency formation time on a broadcast link can be 130 more than that on a point-to-point link of the same speed, 131 because DR election has to take place. All routers on a 132 broadcast network form adjacency with the DR and BDR. 134 Async flooding also takes place thru the DR. In context of 135 convergence, it may take more time for an LSU to be 136 flooded from one DR-other router to another DR-other 137 router, because the LSA has to be first processed at the 138 DR. 140 o Shortest Path First Execution Time 142 - Definition 144 The time taken by a router to complete the SPF process, as 145 described in [OSPF]. 147 - Discussion 149 This does not include the time taken by the router to give 150 routes to the forwarding engine. 152 Some implementations may force two intervals, the SPF hold 153 time and the SPF delay, between successive SPF calcula- 154 tions. If an SPF hold time exists, it should be subtracted 155 from the total SPF execution time. If an SPF delay exists, 156 it should be noted in the test results. 158 o Measurement Units 160 The SPF time is generally measured in milliseconds. 162 o Hello Interval 164 - Definition 166 See [OSPF], Section 7.1. 168 - Discussion 170 The hello interval should be the same for all routers on a 171 network. 173 Decreasing the hello interval can allow the router dead 174 interval (below) to be reduced, thus reducing convergence 175 times in those situations where the router dead interval 176 timing out causes an OSPF process to notice an adjacency 177 failure. Further discussion on small hello intervals is 178 given in [CONGESTION] and [MARKING]. 180 o Router Dead interval 182 - Definition 184 See [OSPF], Section 7.1. 186 - Discussion 188 This is advertised in the router's Hello Packets in the 189 RouterDeadInterval field. The router dead interval should 190 be some multiple of the HelloInterval (say 4 times the 191 hello interval), and must be the same for all routers 192 attached to a common network. 194 6. Concepts 196 6.1. The Meaning of Single Router Control Plane Convergence 198 A network is termed to be converged when all of the devices within 199 the network have a loop free path to each possible destination. Since 200 we are not testing network convergence, but performance for a partic- 201 ular device within a network, however, this definition needs to be 202 narrowed somewhat to fit within a single device view. 204 In this case, convergence will mean the point in time when the DUT 205 has performed all actions needed to react to the change in topology 206 represented by the test condition; for instance, an OSPF device must 207 flood any new information it has received, rebuild its shortest path 208 first (SPF) tree, and install any new paths or destinations in the 209 local routing information base (RIB, or routing table). 211 Note that the word convergence has two distinct meanings; the process 212 of a group of individuals meeting the same place, and the process of 213 a single individual meeting in the same place as an existing group. 214 This work focuses on the second meaning of the word, so we consider 215 the time required for a single device to adapt to a network change to 216 be Single Router Convergence. 218 This concept does not include the time required for the control plane 219 of the device to transfer the information required to forward packets 220 to the data plane, nor the amount of time between the data plane 221 receiving that information and being able to actually forward 222 traffic. 224 6.2. Measuring Convergence 226 Obviously, there are several elements to convergence, even under the 227 definition given above for a single device, including (but not lim- 228 ited to): 230 o The time it takes for the DUT to pass the information about a 231 network event on to its neighbors. 233 o The time it takes for the DUT to process information about a 234 network event and calculate a new Shortest Path Tree (SPT). 236 o The time it takes for the DUT to make changes in its local 237 rib reflecting the new shortest path tree. 239 6.3. Types of Network Events 241 A network event is an event which causes a change in the network 242 topology. 244 o Link or Neighbor Device Up 246 The time needed for an OSPF implementation to recoginize a 247 new link coming up on the device, build any necessarily adja- 248 cencies, synchronize its database, and perform all other 249 needed actions to converge. 251 o Initialization 253 The time needed for an OSPF implementation to be initialized, 254 recognize any links across which OSPF must run, build any 255 needed adjacencies, synchronize its database, and perform 256 other actions needed to converge. 258 o Adjacency Down 260 The time needed for an OSPF implementation to recognize a 261 link down/adjacency loss based on hello timers alone, propo- 262 gate any information as necessary to its remaining adjacen- 263 cies, and perform other actions needed to converge. 265 o Link Down 267 The time needed for an OSPF implementation to recognize a 268 link down based on layer 2 provided information, propogate 269 any information as needed to its remaining adjacencies, and 270 perform other actions needed to converge. 272 7. Acknowedgements 274 The authors would like to thank Howard Berkowitz (hcb@clark.net), 275 Kevin Dubray, (kdubray@juniper.net), Scott Poretsky 276 (sporetsky@avici.com), and Randy Bush (randy@psg.com) for their dis- 277 cussion, ideas, and support. 279 8. Normative References 281 [BENCHMARK] 282 Manral, V., "Benchmarking Basic OSPF Single Router Control Plane 283 Convergence", draft-bmwg-ospfconv-intraarea-05, March 2003 285 [OSPF]Moy, J., "OSPF Version 2", RFC 2328, April 1998. 287 9. Informative References 289 [CONGESTION] 290 Ash, J., "Proposed Mechanisms for Congestion Control/Failure 291 Recovery in OSPF & ISIS Networks", October, 2001 293 [MARKING] 294 Choudhury, G., et al, "Explicit Marking and Prioritized Treatment 295 of Specific IGP Packets for Faster IGP Convergence and Improved 296 Network Scalability and Stability", draft-ietf-ospf-scalability, 297 April 2002 299 10. Authors' Addresses 301 Vishwas Manral, 302 Netplane Systems, 303 189 Prashasan Nagar, 304 Road number 72, 305 Jubilee Hills, 306 Hyderabad. 308 vmanral@netplane.com 310 Russ White 311 Cisco Systems, Inc. 312 7025 Kit Creek Rd. 313 Research Triangle Park, NC 27709 315 riw@cisco.com 317 Aman Shaikh 318 University of California 319 School of Engineering 320 1156 High Street 321 Santa Cruz, CA 95064 323 aman@soe.ucsc.edu