idnits 2.17.1 draft-ietf-bmwg-ospfconv-term-04.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? ** Missing revision: the document name given in the document, 'draft-ietf-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-', but the file name used is 'draft-ietf-bmwg-ospfconv-term-04' == 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 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: ---------------------------------------------------------------------------- == 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 (March 2003) is 7712 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 301 looks like a reference -- Missing reference section? 'OSPF' on line 204 looks like a reference -- Missing reference section? 'CONGESTION' on line 309 looks like a reference -- Missing reference section? 'MARKING' on line 313 looks like a reference Summary: 11 errors (**), 1 flaw (~~), 5 warnings (==), 5 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: September 2003 University of California 8 File Name: draft-ietf- bmwg-ospfconv-term-04.txt March 2003 10 OSPF Benchmarking Terminology and Concepts 11 draft-ietf-bmwg-ospfconv-term-04.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 Internal Measurements 57 - Definition 59 Internal measurements are measurements taken on the Device 60 Under Test (DUT) itself; also known as White Box Measure- 61 ments. 63 - Discussion 65 These measurement rely on output and event recording, 66 along with the clocking and timestamping available on the 67 DUT itself. Taking measurements on the DUT may impact the 68 actual outcome of the test, since it can increase proces- 69 sor loading, memory utilization, and timing factors. Some 70 devices may not have the required output readily available 71 for taking internal measurements, as well. 73 Note: Internal measurements can be influenced by the 74 vendor's implementation of the various timers and process- 75 ing models. Whenever possible, internal measurements 76 should be compared to external measurements to verify and 77 validate them. 79 o External Measurements 81 - Definition 83 External measurements infer the performance of the DUT 84 through observation of its communications with other 85 devices; also known as Black Box Measurements. 87 - Discussion 89 One example of an external measurement is when a down- 90 stream device receives complete routing information from 91 the DUT, it can be inferred that the DUT has transmitted 92 all the routing information available. External measure- 93 ments suffer in that they include not just the protocol 94 action times, but also propagation delays, queuing delays, 95 and other such factors. 97 For the purposes of [BENCHMARK], external techniques are 98 more readily applicable. 100 o Multi-device Measurements 102 - Definition 104 Multi-device measurements require the measurement of 105 events occurring on multiple devices within the testbed. 107 - Discussion 109 For instance, the timestamp on a device generating an 110 event could be used as the marker for the beginning of a 111 test, while the timestamp on the DUT or some other device 112 might be used to determine when the DUT has finished pro- 113 cessing the event. 115 These sorts of measurements are the most problematic, and 116 are to be avoided where possible, since the timestamps of 117 the devices in the test bed must be synchronized within 118 milliseconds for the test results to be meaningful. Given 119 the state of network time protocol implementation, expect- 120 ing the timestamps on several devices to be within mil- 121 liseconds of each other is highly optimistic. 123 5. Terms Defined Elsewhere 125 Terms in this section are defined elsewhere, and included only to 126 include a discussion of those terms in reference to [BENCHMARK]. 128 o Point-to-Point links 130 - Definition 132 See [OSPF], Section 1.2. 134 - Discussion 136 A point-to-point link can take lesser time to converge 137 than a broadcast link of the same speed because it does 138 not have the overhead of DR election. Point-to-point links 139 can be either numbered or unnumbered. However in the con- 140 text of [BENCHMARK] and [OSPF], the two can be regarded 141 the same. 143 o Broadcast Link 145 - Definition 147 See [OSPF], Section 1.2. 149 - Discussion 151 The adjacency formation time on a broadcast link can be 152 more than that on a point-to-point link of the same speed, 153 because DR election has to take place. All routers on a 154 broadcast network form adjacency with the DR and BDR. 156 Async flooding also takes place thru the DR. In context of 157 convergence, it may take more time for an LSU to be 158 flooded from one DR-other router to another DR-other 159 router, because the LSA has to be first processed at the 160 DR. 162 o Shortest Path First Execution Time 163 - Definition 165 The time taken by a router to complete the SPF process, as 166 described in [OSPF]. 168 - Discussion 170 This does not include the time taken by the router to give 171 routes to the forwarding engine. 173 Some implementations may force two intervals, the SPF hold 174 time and the SPF delay, between successive SPF calcula- 175 tions. If an SPF hold time exists, it should be subtracted 176 from the total SPF execution time. If an SPF delay exists, 177 it should be noted in the test results. 179 o Measurement Units 181 The SPF time is generally measured in milliseconds. 183 o Hello Interval 185 - Definition 187 See [OSPF], Section 7.1. 189 - Discussion 191 The hello interval should be the same for all routers on a 192 network. 194 Decreasing the hello interval can allow the router dead 195 interval (below) to be reduced, thus reducing convergence 196 times in those situations where the router dead interval 197 timing out causes an OSPF process to notice an adjacency 198 failure. Further discussion on small hello intervals is 199 given in [CONGESTION] and [MARKING]. 201 o Router Dead interval 203 - Definition 204 See [OSPF], Section 7.1. 206 - Discussion 208 This is advertised in the router's Hello Packets in the 209 RouterDeadInterval field. The router dead interval should 210 be some multiple of the HelloInterval (say 4 times the 211 hello interval), and must be the same for all routers 212 attached to a common network. 214 6. Concepts 216 6.1. The Meaning of Single Router Control Plane Convergence 218 A network is termed to be converged when all of the devices within 219 the network have a loop free path to each possible destination. Since 220 we are not testing network convergence, but performance for a partic- 221 ular device within a network, however, this definition needs to be 222 narrowed somewhat to fit within a single device view. 224 In this case, convergence will mean the point in time when the DUT 225 has performed all actions needed to react to the change in topology 226 represented by the test condition; for instance, an OSPF device must 227 flood any new information it has received, rebuild its shortest path 228 first (SPF) tree, and install any new paths or destinations in the 229 local routing information base (RIB, or routing table). 231 Note that the word convergence has two distinct meanings; the process 232 of a group of individuals meeting the same place, and the process of 233 a single individual meeting in the same place as an existing group. 234 This work focuses on the second meaning of the word, so we consider 235 the time required for a single device to adapt to a network change to 236 be Single Router Convergence. 238 This concept does not include the time required for the control plane 239 of the device to transfer the information required to forward packets 240 to the data plane, nor the amount of time between the data plane 241 receiving that information and being able to actually forward 242 traffic. 244 6.2. Measuring Convergence 246 Obviously, there are several elements to convergence, even under the 247 definition given above for a single device, including (but not lim- 248 ited to): 250 o The time it takes for the DUT to pass the information about a 251 network event on to its neighbors. 253 o The time it takes for the DUT to process information about a 254 network event and calculate a new Shortest Path Tree (SPT). 256 o The time it takes for the DUT to make changes in its local 257 rib reflecting the new shortest path tree. 259 6.3. Types of Network Events 261 A network event is an event which causes a change in the network 262 topology. 264 o Link or Neighbor Device Up 266 The time needed for an OSPF implementation to recoginize a 267 new link coming up on the device, build any necessarily adja- 268 cencies, synchronize its database, and perform all other 269 needed actions to converge. 271 o Initialization 273 The time needed for an OSPF implementation to be initialized, 274 recognize any links across which OSPF must run, build any 275 needed adjacencies, synchronize its database, and perform 276 other actions needed to converge. 278 o Adjacency Down 280 The time needed for an OSPF implementation to recognize a 281 link down/adjacency loss based on hello timers alone, propo- 282 gate any information as necessary to its remaining adjacen- 283 cies, and perform other actions needed to converge. 285 o Link Down 287 The time needed for an OSPF implementation to recognize a 288 link down based on layer 2 provided information, propogate 289 any information as needed to its remaining adjacencies, and 290 perform other actions needed to converge. 292 7. Acknowedgements 294 The authors would like to thank Howard Berkowitz (hcb@clark.net), 295 Kevin Dubray, (kdubray@juniper.net), Scott Poretsky 296 (sporetsky@avici.com), and Randy Bush (randy@psg.com) for their dis- 297 cussion, ideas, and support. 299 8. Normative References 301 [BENCHMARK] 302 Manral, V., "Benchmarking Basic OSPF Single Router Control Plane 303 Convergence", draft-bmwg-ospfconv-intraarea-05, March 2003 305 [OSPF]Moy, J., "OSPF Version 2", RFC 2328, April 1998. 307 9. Informative References 309 [CONGESTION] 310 Ash, J., "Proposed Mechanisms for Congestion Control/Failure 311 Recovery in OSPF & ISIS Networks", October, 2001 313 [MARKING] 314 Choudhury, G., et al, "Explicit Marking and Prioritized Treatment 315 of Specific IGP Packets for Faster IGP Convergence and Improved 316 Network Scalability and Stability", draft-ietf-ospf-scalability, 317 April 2002 319 10. Authors' Addresses 321 Vishwas Manral, 322 Netplane Systems, 323 189 Prashasan Nagar, 324 Road number 72, 325 Jubilee Hills, 326 Hyderabad. 328 vmanral@netplane.com 330 Russ White 331 Cisco Systems, Inc. 332 7025 Kit Creek Rd. 333 Research Triangle Park, NC 27709 335 riw@cisco.com 337 Aman Shaikh 338 University of California 339 School of Engineering 340 1156 High Street 341 Santa Cruz, CA 95064 343 aman@soe.ucsc.edu