idnits 2.17.1 draft-ietf-bmwg-ospfconv-term-10.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 17. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 367. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 388), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** 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. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- 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? == 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 copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 2004) is 7252 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 298, 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: 12 errors (**), 0 flaws (~~), 6 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-ietf-bmwg-ospfconv-term-10.txt June 2004 9 OSPF Benchmarking Terminology and Concepts 10 draft-ietf-bmwg-ospfconv-term-10.txt 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance with 17 RFC 3668. 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 (2004). 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]. 52 [RFC2119] keywords in this document are used to assure methodological 53 control, which is very important in the specification of benchmarks. 54 This document does not specify a network related protocol. 56 2. Introduction 58 This draft is a companion to [BENCHMARK], which describes basic Open 59 Shortest Path First [OSPF] testing methods. This draft explains 60 terminology and concepts used in OSPF Testing Framework Drafts, such 61 as [BENCHMARK]. 63 3. Common Definitions 65 Definitions in this section are well known industry and benchmarking 66 terms which may be defined elsewhere. 68 o White Box (Internal) Measurements 70 - Definition 72 White Box measurements are measurements reported and col- 73 lected on the Device Under Test (DUT) itself. 75 - Discussion 77 These measurement rely on output and event recording, along 78 with the clocking and time stamping available on the DUT 79 itself. Taking measurements on the DUT may impact the 80 actual outcome of the test, since it can increase processor 81 loading, memory utilization, and timing factors. Some dev- 82 ices may not have the required output readily available for 83 taking internal measurements, as well. 85 Note: White box measurements can be influenced by the 86 vendor's implementation of the various timers and process- 87 ing models. Whenever possible, internal measurements should 88 be compared to external measurements to verify and validate 89 them. 91 Because of the potential for variations in collection and 92 presentation methods across different DUTs, white box meas- 93 urements MUST NOT be used as a basis of comparison in 94 benchmarks. This has been a guiding principal of Bench- 95 marking Methodology Working Group. 97 o Black Box (External) Measurements 99 - Definition 101 Black Box measurements infer the performance of the DUT 102 through observation of its communications with other dev- 103 ices. 105 - Discussion 107 One example of a black box measurement is when a downstream 108 device receives complete routing information from the DUT, 109 it can be inferred that the DUT has transmitted all the 110 routing information available. External measurements of 111 internal operations may suffer in that they include not 112 just the protocol action times, but also propagation 113 delays, queuing delays, and other such factors. 115 For the purposes of [BENCHMARK], external techniques are 116 more readily applicable. 118 o Multi-device Measurements 120 - Measurements assessing communications (usually in combina- 121 tion with internal operations) between two or more DUTs. 122 Multi-device measurements may be internal or external. 124 4. Terms Defined Elsewhere 126 Terms in this section are defined elsewhere, and included only to 127 include a discussion of those terms in reference to [BENCHMARK]. 129 o Point-to-Point links 131 - Definition 133 See [OSPF], Section 1.2. 135 - Discussion 137 A point-to-point link can take lesser time to converge than 138 a broadcast link of the same speed because it does not have 139 the overhead of DR election. Point-to-point links can be 140 either numbered or unnumbered. However in the context of 141 [BENCHMARK] and [OSPF], the two can be regarded 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 Asynchronous flooding also takes place thru the DR. In con- 157 text of convergence, it may take more time for an LSA 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 - 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 [OSPF-SCALING]. 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 Router- 209 DeadInterval field. The router dead interval should be some mul- 210 tiple of the HelloInterval (say 4 times the hello interval), and 211 must be the same for all routers attached to a common network. 213 5. Concepts 215 5.1. The Meaning of Single Router Control Plane Convergence 217 A network is termed to be converged when all of the devices within 218 the network have a loop free path to each possible destination. Since 219 we are not testing network convergence, but performance for a partic- 220 ular device within a network, however, this definition needs to be 221 narrowed somewhat to fit within a single device view. 223 In this case, convergence will mean the point in time when the DUT 224 has performed all actions needed to react to the change in topology 225 represented by the test condition; for instance, an OSPF device must 226 flood any new information it has received, rebuild its shortest path 227 first (SPF) tree, and install any new paths or destinations in the 228 local routing information base (RIB, or routing table). 230 Note that the word convergence has two distinct meanings; the process 231 of a group of individuals meeting the same place, and the process of 232 a single individual meeting in the same place as an existing group. 233 This work focuses on the second meaning of the word, so we consider 234 the time required for a single device to adapt to a network change to 235 be Single Router Convergence. 237 This concept does not include the time required for the control plane 238 of the device to transfer the information required to forward packets 239 to the data plane, nor the amount of time between the data plane 240 receiving that information and being able to actually forward 241 traffic. 243 5.2. Measuring Convergence 245 Obviously, there are several elements to convergence, even under the 246 definition given above for a single device, including (but not lim- 247 ited to): 249 o The time it takes for the DUT to pass the information about a 250 network event on to its neighbors. 252 o The time it takes for the DUT to process information about a 253 network event and calculate a new Shortest Path Tree (SPT). 255 o The time it takes for the DUT to make changes in its local rib 256 reflecting the new shortest path tree. 258 5.3. Types of Network Events 260 A network event is an event which causes a change in the network 261 topology. 263 o Link or Neighbor Device Up 265 The time needed for an OSPF implementation to recognize a new 266 link coming up on the device, build any necessarily adjacencies, 267 synchronize its database, and perform all other needed actions 268 to converge. 270 o Initialization 272 The time needed for an OSPF implementation to be initialized, 273 recognize any links across which OSPF must run, build any needed 274 adjacencies, synchronize its database, and perform other actions 275 needed to converge. 277 o Adjacency Down 279 The time needed for an OSPF implementation to recognize a link 280 down/adjacency loss based on hello timers alone, propagate any 281 information as necessary to its remaining adjacencies, and per- 282 form other actions needed to converge. 284 o Link Down 286 The time needed for an OSPF implementation to recognize a link 287 down based on layer 2 provided information, propagate any infor- 288 mation as needed to its remaining adjacencies, and perform other 289 actions needed to converge. 291 6. IANA Considerations 293 This document requires no IANA considerations. 295 7. Security Considerations 297 This document does not modify the underlying security considerations 298 in [OSPF]. 300 8. Acknowledgements 302 The authors would like to thank Howard Berkowitz (hcb@clark.net), 303 Kevin Dubray, (kdubray@juniper.net), Scott Poretsky 304 (sporetsky@avici.com), and Randy Bush (randy@psg.com) for their dis- 305 cussion, ideas, and support. 307 9. Normative References 309 [BENCHMARK] 310 Manral, V., "Benchmarking Basic OSPF Single Router Control Plane 311 Convergence", draft-bmwg-ospfconv-intraarea-10, May 2004. 313 [OSPF]Moy, J., "OSPF Version 2", RFC 2328, April 1998. 315 [RFC2119] 316 Bradner, S., "Key words for use in RFCs to Indicate Requirement 317 Levels", BCP 14, RFC 2119, March 1997 319 10. Informative References 321 [OSPF-SCALING] 322 Choudhury, Gagan L., Editor, "Prioritized Treatment of Specific 323 OSPF Packets and Congestion Avoidance", draft-ietf-ospf- 324 scalability-06.txt, August 2003. 326 11. Authors' Addresses 328 Vishwas Manral, 329 Netplane Systems, 330 189 Prashasan Nagar, 331 Road number 72, 332 Jubilee Hills, 333 Hyderabad. 335 vmanral@netplane.com 337 Russ White 338 Cisco Systems, Inc. 339 7025 Kit Creek Rd. 340 Research Triangle Park, NC 27709 342 riw@cisco.com 344 Aman Shaikh 345 University of California 346 School of Engineering 347 1156 High Street 348 Santa Cruz, CA 95064 350 aman@soe.ucsc.edu 352 Intellectual Property Statement 354 The IETF takes no position regarding the validity or scope of any Intel- 355 lectual Property Rights or other rights that might be claimed to pertain 356 to the implementation or use of the technology described in this docu- 357 ment or the extent to which any license under such rights might or might 358 not be available; nor does it represent that it has made any independent 359 effort to identify any such rights. Information on the procedures with 360 respect to rights in RFC documents can be found in BCP 78 and BCP 79. 362 Copies of IPR disclosures made to the IETF Secretariat and any 363 assurances of licenses to be made available, or the result of an attempt 364 made to obtain a general license or permission for the use of such 365 proprietary rights by implementers or users of this specification can be 366 obtained from the IETF on-line IPR repository at 367 http://www.ietf.org/ipr. 369 The IETF invites any interested party to bring to its attention any 370 copyrights, patents or patent applications, or other proprietary rights 371 that may cover technology that may be required to implement this stan- 372 dard. Please address the information to the IETF at ietf-ipr@ietf.org. 374 Disclaimer of Warranty 376 This document and the information contained herein are provided on an 377 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 378 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 379 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 380 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMA- 381 TION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 382 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 384 Full Copyright Statement 386 Copyright (C) The Internet Society (2004). This document is subject to 387 the rights, licenses and restrictions contained in BCP 78, and except as 388 set forth therein, the authors retain all their rights.