idnits 2.17.1 draft-ietf-bmwg-ospfconv-term-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 369. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 378. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 391. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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-09', but the file name used is 'draft-ietf-bmwg-ospfconv-term-09' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 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 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == 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 (June 2004) is 7248 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: 'OSPF' is mentioned on line 296, 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: 11 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Vishwas Manral 2 Internet Draft Netplane Systems 3 Russ White 4 Cisco Systems 5 Aman Shaikh 6 Expiration Date: December 2004 University of California 7 File Name: draft-bmwg-ospfconv-term-09.txt June 2004 9 OSPF Benchmarking Terminology and Concepts 10 draft-bmwg-ospfconv-term-09.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its Areas, and its Working Groups. Note that other 19 groups may also distribute working documents as Internet Drafts. 21 Internet Drafts are draft documents valid for a maximum of six 22 months. Internet Drafts may be updated, replaced, or obsoleted by 23 other documents at any time. It is not appropriate to use Internet 24 Drafts as reference material or to cite them other than as a "working 25 draft" or "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http//www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http//www.ietf.org/shadow.html. 33 This document may not be modified, and derivative works of it may not 34 be created, except to publish it as an RFC and to translate it into 35 languages other than English. 37 Abstract 39 This draft explains the terminology and concepts used in OSPF 40 benchmarking. While some of these terms may be defined elsewhere, and 41 we will refer the reader to those definitions in some cases, we also 42 include discussions concerning these terms as they relate 43 specifically to the tasks involved in benchmarking the OSPF protocol. 45 1. Specification of Requirements 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC 2119 [RFC2119]. 50 [RFC2119] keywords in this document are used to assure methodological 51 control, which is very important in the specification of benchmarks. 52 This document does not specify a network related protocol. 54 2. Introduction 56 This draft is a companion to [BENCHMARK], which describes basic Open 57 Shortest Path First [OSPF] testing methods. This draft explains 58 terminology and concepts used in OSPF Testing Framework Drafts, such 59 as [BENCHMARK]. 61 3. Common Definitions 63 Definitions in this section are well known industry and benchmarking 64 terms which may be defined elsewhere. 66 o White Box (Internal) Measurements 68 - Definition 70 White Box measurements are measurements reported and col- 71 lected on the Device Under Test (DUT) itself. 73 - Discussion 75 These measurement rely on output and event recording, along 76 with the clocking and time stamping available on the DUT 77 itself. Taking measurements on the DUT may impact the 78 actual outcome of the test, since it can increase processor 79 loading, memory utilization, and timing factors. Some dev- 80 ices may not have the required output readily available for 81 taking internal measurements, as well. 83 Note: White box measurements can be influenced by the 84 vendor's implementation of the various timers and process- 85 ing models. Whenever possible, internal measurements should 86 be compared to external measurements to verify and validate 87 them. 89 Because of the potential for variations in collection and 90 presentation methods across different DUTs, white box meas- 91 urements MUST NOT be used as a basis of comparison in 92 benchmarks. This has been a guiding principal of Bench- 93 marking Methodology Working Group. 95 o Black Box (External) Measurements 97 - Definition 99 Black Box measurements infer the performance of the DUT 100 through observation of its communications with other dev- 101 ices. 103 - Discussion 105 One example of a black box measurement is when a downstream 106 device receives complete routing information from the DUT, 107 it can be inferred that the DUT has transmitted all the 108 routing information available. External measurements of 109 internal operations may suffer in that they include not 110 just the protocol action times, but also propagation 111 delays, queuing delays, and other such factors. 113 For the purposes of [BENCHMARK], external techniques are 114 more readily applicable. 116 o Multi-device Measurements 118 - Measurements assessing communications (usually in combina- 119 tion with internal operations) between two or more DUTs. 120 Multi-device measurements may be internal or external. 122 4. Terms Defined Elsewhere 124 Terms in this section are defined elsewhere, and included only to 125 include a discussion of those terms in reference to [BENCHMARK]. 127 o Point-to-Point links 129 - Definition 131 See [OSPF], Section 1.2. 133 - Discussion 135 A point-to-point link can take lesser time to converge than 136 a broadcast link of the same speed because it does not have 137 the overhead of DR election. Point-to-point links can be 138 either numbered or unnumbered. However in the context of 139 [BENCHMARK] and [OSPF], the two can be regarded the same. 141 o Broadcast Link 143 - Definition 145 See [OSPF], Section 1.2. 147 - Discussion 149 The adjacency formation time on a broadcast link can be 150 more than that on a point-to-point link of the same speed, 151 because DR election has to take place. All routers on a 152 broadcast network form adjacency with the DR and BDR. 154 Asynchronous flooding also takes place thru the DR. In con- 155 text of convergence, it may take more time for an LSA to be 156 flooded from one DR-other router to another DR-other 157 router, because the LSA has to be first processed at the 158 DR. 160 o Shortest Path First Execution Time 161 - Definition 163 The time taken by a router to complete the SPF process, as 164 described in [OSPF]. 166 - Discussion 168 This does not include the time taken by the router to give 169 routes to the forwarding engine. 171 Some implementations may force two intervals, the SPF hold 172 time and the SPF delay, between successive SPF calcula- 173 tions. If an SPF hold time exists, it should be subtracted 174 from the total SPF execution time. If an SPF delay exists, 175 it should be noted in the test results. 177 - Measurement Units 179 The SPF time is generally measured in milliseconds. 181 o Hello Interval 183 - Definition 185 See [OSPF], Section 7.1. 187 - Discussion 189 The hello interval should be the same for all routers on a 190 network. 192 Decreasing the hello interval can allow the router dead 193 interval (below) to be reduced, thus reducing convergence 194 times in those situations where the router dead interval 195 timing out causes an OSPF process to notice an adjacency 196 failure. Further discussion on small hello intervals is 197 given in [OSPF-SCALING]. 199 o Router Dead interval 201 - Definition 202 See [OSPF], Section 7.1. 204 - Discussion 206 This is advertised in the router's Hello Packets in the Router- 207 DeadInterval field. The router dead interval should be some mul- 208 tiple of the HelloInterval (say 4 times the hello interval), and 209 must be the same for all routers attached to a common network. 211 5. Concepts 213 5.1. The Meaning of Single Router Control Plane Convergence 215 A network is termed to be converged when all of the devices within 216 the network have a loop free path to each possible destination. Since 217 we are not testing network convergence, but performance for a partic- 218 ular device within a network, however, this definition needs to be 219 narrowed somewhat to fit within a single device view. 221 In this case, convergence will mean the point in time when the DUT 222 has performed all actions needed to react to the change in topology 223 represented by the test condition; for instance, an OSPF device must 224 flood any new information it has received, rebuild its shortest path 225 first (SPF) tree, and install any new paths or destinations in the 226 local routing information base (RIB, or routing table). 228 Note that the word convergence has two distinct meanings; the process 229 of a group of individuals meeting the same place, and the process of 230 a single individual meeting in the same place as an existing group. 231 This work focuses on the second meaning of the word, so we consider 232 the time required for a single device to adapt to a network change to 233 be Single Router Convergence. 235 This concept does not include the time required for the control plane 236 of the device to transfer the information required to forward packets 237 to the data plane, nor the amount of time between the data plane 238 receiving that information and being able to actually forward 239 traffic. 241 5.2. Measuring Convergence 243 Obviously, there are several elements to convergence, even under the 244 definition given above for a single device, including (but not lim- 245 ited to): 247 o The time it takes for the DUT to pass the information about a 248 network event on to its neighbors. 250 o The time it takes for the DUT to process information about a 251 network event and calculate a new Shortest Path Tree (SPT). 253 o The time it takes for the DUT to make changes in its local rib 254 reflecting the new shortest path tree. 256 5.3. Types of Network Events 258 A network event is an event which causes a change in the network 259 topology. 261 o Link or Neighbor Device Up 263 The time needed for an OSPF implementation to recognize a new 264 link coming up on the device, build any necessarily adjacencies, 265 synchronize its database, and perform all other needed actions 266 to converge. 268 o Initialization 270 The time needed for an OSPF implementation to be initialized, 271 recognize any links across which OSPF must run, build any needed 272 adjacencies, synchronize its database, and perform other actions 273 needed to converge. 275 o Adjacency Down 277 The time needed for an OSPF implementation to recognize a link 278 down/adjacency loss based on hello timers alone, propagate any 279 information as necessary to its remaining adjacencies, and per- 280 form other actions needed to converge. 282 o Link Down 284 The time needed for an OSPF implementation to recognize a link 285 down based on layer 2 provided information, propagate any infor- 286 mation as needed to its remaining adjacencies, and perform other 287 actions needed to converge. 289 6. IANA Considerations 291 This document requires no IANA considerations. 293 7. Security Considerations 295 This document does not modify the underlying security considerations 296 in [OSPF]. 298 8. Acknowledgements 300 The authors would like to thank Howard Berkowitz (hcb@clark.net), 301 Kevin Dubray, (kdubray@juniper.net), Scott Poretsky 302 (sporetsky@avici.com), and Randy Bush (randy@psg.com) for their dis- 303 cussion, ideas, and support. 305 9. Normative References 307 [BENCHMARK] 308 Manral, V., "Benchmarking Basic OSPF Single Router Control Plane 309 Convergence", draft-bmwg-ospfconv-intraarea-09, May 2004. 311 [OSPF]Moy, J., "OSPF Version 2", RFC 2328, April 1998. 313 [RFC2119] 314 Bradner, S., "Key words for use in RFCs to Indicate Requirement 315 Levels", BCP 14, RFC 2119, March 1997 317 10. Informative References 319 [OSPF-SCALING] 320 Choudhury, Gagan L., Editor, "Prioritized Treatment of Specific 321 OSPF Packets and Congestion Avoidance", draft-ietf-ospf- 322 scalability-06.txt, August 2003. 324 11. Authors' Addresses 326 Vishwas Manral, 327 Netplane Systems, 328 189 Prashasan Nagar, 329 Road number 72, 330 Jubilee Hills, 331 Hyderabad. 333 vmanral@netplane.com 335 Russ White 336 Cisco Systems, Inc. 337 7025 Kit Creek Rd. 338 Research Triangle Park, NC 27709 340 riw@cisco.com 342 Aman Shaikh 343 University of California 344 School of Engineering 345 1156 High Street 346 Santa Cruz, CA 95064 348 aman@soe.ucsc.edu 350 12. Full Copyright Statement 352 Copyright (C) The Internet Society (2004). This document is subject 353 to the rights, licenses and restrictions contained in BCP 78, and 354 except as set forth therein, the authors retain all their rights. 356 This document and the information contained herein are provided on an 357 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 358 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 359 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 360 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- 361 MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 362 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 364 13. Intellectual Property 366 By submitting this Internet-Draft, I certify that any applicable 367 patent or other IPR claims of which I am aware have been disclosed, 368 and any of which I become aware will be disclosed, in accordance with 369 RFC 3668. 371 The IETF takes no position regarding the validity or scope of any 372 Intellectual Property Rights or other rights that might be claimed to 373 pertain to the implementation or use of the technology described in 374 this document or the extent to which any license under such rights 375 might or might not be available; nor does it represent that it has 376 made any independent effort to identify any such rights. Information 377 on the procedures with respect to rights in RFC documents can be 378 found in BCP 78 and BCP 79. 380 Copies of IPR disclosures made to the IETF Secretariat and any 381 assurances of licenses to be made available, or the result of an 382 attempt made to obtain a general license or permission for the use of 383 such proprietary rights by implementers or users of this specifica- 384 tion can be obtained from the IETF on-line IPR repository at 385 http://www.ietf.org/ipr. 387 The IETF invites any interested party to bring to its attention any 388 copyrights, patents or patent applications, or other proprietary 389 rights that may cover technology that may be required to implement 390 this standard. Please address the information to the IETF at ietf- 391 ipr@ietf.org.