idnits 2.17.1 draft-ietf-bmwg-ospfconv-intraarea-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 682. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 703), 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 15 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 16 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 7254 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 599, but not defined == Missing Reference: 'TERM' is mentioned on line 527, but not defined == Missing Reference: 'RFC2328' is mentioned on line 227, but not defined == Unused Reference: 'MILLISEC' is defined on line 630, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-bmwg-ospfconv-applicability (ref. 'CONSIDERATIONS') Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 4 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-intraarea-10.txt June 2004 9 Benchmarking Basic OSPF Single Router Control Plane Convergence 10 draft-ietf-bmwg-ospfconv-intraarea-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 provides suggestions for measuring OSPF single router 42 control plane convergence. Its initial emphasis is on the control 43 plane of single OSPF routers. We do not address forwarding plane 44 performance. 46 NOTE: Within this document, the word convergence relates to single 47 router control plane convergence only. 49 Table of Contents 51 1. Introduction........................................................1 52 2. Specification of Requirements.......................................2 53 3. Overview & Scope....................................................2 54 4. Reference Topologies................................................3 55 5. Basic Performance Tests.............................................4 56 5.1 Time Required to Process and LSA................................4 57 5.2 Flooding Time...................................................5 58 5.3 Shortest Path First Computation Time............................5 59 6. Basic Intra-Area OSPF Tests.........................................7 60 6.1 Forming Adjacencies on Point-to-Point Links (Initialization)....8 61 6.2 Forming Adjacencies on Point-to-Point Links.....................8 62 6.3 Forming Adjacencies with Information Already in the Database....9 63 6.4 Designated Router Election Time on a Broadcast Network.........10 64 6.5 Initial Convergence Time on a Broadcast Network, Test 1........11 65 6.6 Initial Convergence Time on a Broadcast Network, Test 2........11 66 6.7 Link Down with Layer Two Detection.............................12 67 6.8 Link Down with Layer Three Detection...........................12 68 7. IANA Considerations................................................13 69 8. Security Considerations............................................13 70 9. Acknowledgements...................................................13 71 10. Normative References..............................................13 72 11. Informative References............................................14 73 12. Author's Addresses................................................14 74 13. Full Copyright Statement..........................................15 75 14. Intellectual Property.............................................15 77 1. Introduction 79 There is a growing interest in routing protocol convergence testing, 80 with many people looking at various tests to determine how long it 81 takes for a network to converge after various conditions occur. The 82 major problem with this sort of testing is that the framework of the 83 tests has a major impact on the results; for instance, determining 84 when a network is converged, what parts of the router's operation are 85 considered within the testing, and other such things will have a 86 major impact on what apparent performance routing protocols provide. 88 This document attempts to provide a framework within which Open 89 Shortest Path First [OSPF] performance testing can be placed, and 90 provide some tests with which some aspects of OSPF performance can be 91 measured. The motivation of the draft is to provide a set of tests 92 that can provide the user comparable data from various vendors with 93 which to evaluate the OSPF protocol performance on the devices. 95 2. Specification of Requirements 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. RFC2119 100 keywords in this document are used to assure methodological control, 101 which is very important in the specification of benchmarks. This 102 document does not specify a network related protocol. 104 3. Overview & Scope 106 While this document describes a specific set of tests aimed at 107 characterizing the single router control plane convergence 108 performance of OSPF processes in routers or other boxes that 109 incorporate OSPF functionality, a key objective is to propose 110 methodologies that will produce directly comparable convergence 111 related measurements. 113 Things which are outside the scope of this document include: 115 o The interactions of convergence and forwarding; testing is res- 116 tricted to events occurring within the control plane. Forwarding 117 performance is the primary focus in [INTERCONNECT] and it is 118 expected to be dealt with in work that ensues from [FIB-TERM]. 120 o Inter-area route generation, AS-external route generation, and 121 simultaneous traffic on the control and data paths within the 122 DUT. While the tests outlined in this document measure SPF time, 123 flooding times, and other aspects of all OSPF convergence per- 124 formance, it does not provide tests for measuring external or 125 summary route generation, route translation, or other OSPF 126 inter-area and external routing performance. These are expected 127 to be dealt with in a later draft. 129 Tests should be run more than once, since a single test run can- 130 not be relied on to produce statistically sound results. The 131 number of test runs and any variations between the tests should 132 be recorded in the test results (see [TERM] for more information 133 on what items should be recorded in the test results). 135 4. Reference Topologies 137 Several reference topologies will be used throughout the tests 138 described in the remainder of this document. Rather than repeating 139 these topologies, we've gathered them all in one section. 141 o Reference Topology 1 (Emulated Topology) 143 ( ) 144 DUT----Generator----( emulated topology ) 145 ( ) 147 A simple back-to-back configuration. It's assumed that the link 148 between the generator and the DUT is a point-to-point link, 149 while the connections within the generator represent some emu- 150 lated topology. 152 o Reference Topology 2 (Generator and Collector) 154 ( ) 155 Collector-----DUT-----Generator--( emulated topology ) 156 \ / ( ) 157 \------------/ 159 All routers are connected through point-to-point links. The cost 160 of all links is assumed to be the same unless otherwise noted. 162 o Reference Topology 3 (Broadcast Network) 164 DUT R1 R2 165 | | | 166 -+------+------+-----..... 168 Any number of routers could be included on the common broadcast 169 network. 171 o Reference Topology 4 (Parallel Links) 173 /--(link 1)-----\ ( ) 174 DUT Generator--( emulated topology ) 175 \--(link 2)-----/ ( ) 177 In all cases the tests and topologies are designed to allow perfor- 178 mance measurements to be taken all on a single device, whether the 179 DUT or some other device in the network. This eliminates the need for 180 synchronized clocks within the test networks. 182 5. Basic Process Performance Tests 184 These tests will measure aspects of the OSPF implementation as a pro- 185 cess on the device under test, including: 187 o Time required to process an LSA 189 o Flooding time 191 o Shortest Path First computation 193 5.1. Time required to process an LSA 195 o Using reference topology 1 (Emulated Topology), begin with all 196 links up and a full adjacency established between the DUT and 197 the generator. 199 Note: The generator does not have direct knowledge of the state 200 of the adjacency on the DUT. The fact the adjacency may be in 201 Full on the generator does not mean that the DUT is ready. It 202 may still (and is likely to) be requesting LSAs from the genera- 203 tor. This process, involving processing of requested LSAs, will 204 affect the results of the test. The generator should either wait 205 until it sees the DUT's router-LSA listing the adjacency with 206 the generator or introduce a configurable delay before starting 207 the test. 209 o Send an LSA that is already there in the DUT (a duplicate LSA), 210 note the time difference between when the LSA is sent to when 211 the ack is received. This measures the time to propagate the LSA 212 and the ack, as well as processing time of the duplicate LSA. 213 This is dupLSAprocTime. 215 o Send a new LSA from the generator to the DUT, followed immedi- 216 ately by a duplicate LSA (LSA that already resides in the data- 217 base of DUT, but not the same as the one just sent). 219 o The DUT will acknowledge this second LSA immediately; note the 220 time of this acknowledgement. This is newLSAprocTime. 222 The amount of time required for an OSPF implementation to pro- 223 cess the new LSA can be computed by subtracting dupLSAprocTime 224 from newLSAprocTime. 226 Note: The duplicate LSA cannot be the same as the one just sent 227 because of the MinLSInterval restriction.[RFC2328] This test is 228 taken from [BLACKBOX]. 230 Note: This time may or may not include the time required to per- 231 form flooding-related operations, depending on when the imple- 232 mentation sends the ack--before it floods the LSA further or 233 after, or anywhere in between. In other words, this measurement 234 may not mean the same thing in all implementations. 236 5.2. Flooding Time 238 o Using reference topology 2 (Generator and Collector), enable 239 OSPF on all links and allow the devices to build full adjacen- 240 cies. Configure the collector so it will block all flooding 241 towards the DUT, although it continues receiving advertisements 242 from the DUT. 244 o Inject a new set of LSAs from the generator towards the collec- 245 tor and the DUT. 247 o On the collector, note the time the flooding is complete across 248 the link to the generator. Also note the time the flooding is 249 complete across the link from the DUT. 251 The time between the last LSA is received on the collector from the 252 generator and the time the last LSA is received on the collector from 253 the DUT should be measured during this test. This time is important 254 in link state protocols, since the loop free nature of the network is 255 reliant on the speed at which revised topology information is 256 flooded. 258 Depending on the number of LSAs flooded, the sizes of the LSAs, the 259 number of LSUs, and the rate of flooding, these numbers could vary by 260 some amount. The settings and variances of these numbers should be 261 reported with the test results. 263 5.3. Shortest Path First Computation Time 265 o Use reference topology 1 (Emulated Topology), beginning with the 266 DUT and the generator fully adjacent. 268 o The default SPF timer on the DUT should be set to 0, so that any 269 new LSA that arrives, immediately results in the SPF calculation 270 [BLACKBOX]. 272 o The generator should inject a set of LSAs towards the DUT; the 273 DUT should be allowed to converge and install all best paths in 274 the local routing table, etc.. 276 o Send an LSA that is already there in the DUT (a duplicate LSA), 277 note the time difference between when the LSA is sent to when 278 the ack is received. This measures the time to propagate the LSA 279 and the ack, as well as processing time of the duplicate LSA. 280 This is dupLSAprocTime. 282 o Change the link cost between the generator and the emulated net- 283 work it is advertising, and transmit the new LSA to the DUT. 285 o Immediately inject another LSA which is a duplicate of some 286 other LSA the generator has previously injected (preferably a 287 stub network someplace within the emulated network). 289 Note: The generator should make sure that outbound LSA packing 290 is not performed for the duplicate LSAs and they are always sent 291 in a separate Link-state Update packet. Otherwise, if the LSA 292 carrying the topology change and the duplicate LSA are in the 293 same packet, the SPF will be started the duplicate LSA is acked. 295 o Measure the time between transmitting the second (duplicate) LSA 296 and the acknowledgement for that LSA; this is the totalSPFtime. 297 The total time required to run SPF can be computed by subtract- 298 ing dupLSAprocTime from totalSPFtime. 300 The accuracy of this test is crucially dependant on the amount of 301 time between the transmission of the first and second LSAs. If there 302 is too much time between them, the test is meaningless because the 303 SPF run will complete before the second (duplicate) LSA is received. 304 If there is too little time between the LSAs being generated, then 305 they will both be handled before the SPF run is scheduled and 306 started, and thus the measurement would only be for the handling of 307 the duplicate LSA. 309 This test is also specified in [BLACKBOX]. 311 Note: This test may not be accurate on systems which implement OSPF 312 as a multithreaded process, where the flooding takes place in a 313 separate process (or on a different processor) than shortest path 314 first computations. 316 It is also possible to measure the SPF time using white box tests 317 (using output supplied by the OSPF software implementer). For 318 instance: 320 o Using reference topology 1 (Emulated Topology), establish a full 321 adjacency between the generator and the DUT. 323 o Inject a set of LSAs from the generator towards the DUT. Allow 324 the DUT to stabilize and install all best paths in the routing 325 table, etc. 327 o Change the link cost between the DUT and the generator (or the 328 link between the generator and the emulated network it is 329 advertising), such that a full SPF is required to run, although 330 only one piece of information is changed. 332 o Measure the amount of time required for the DUT to compute new 333 shortest path tree as a result of the topology changes injected 334 by the generator. These measurements should be taken using 335 available show and debug information on the DUT. 337 Several caveats MUST be mentioned when using a white box method of 338 measuring SPF time; for instance, such white box tests are only 339 applicable when testing various versions or variations within a sin- 340 gle implementation of the OSPF protocol. Further, the same set of 341 commands MUST be used in each iteration of such a test, to ensure 342 consistent results. 344 There is some interesting relationship between the SPF times reported 345 by white box (internal) testing, and black box (external) testing; 346 these two types of tests may be used as a "sanity check" on the other 347 type of tests, by comparing the results of the two tests. 349 See [CONSIDERATIONS] for further discussion. 351 6. Basic Intra-Area OSPF tests 353 These tests measure the performance of an OSPF implementation for 354 basic intra-area tasks, including: 356 o Forming Adjacencies on Point-to-Point Link (Initialization) 358 o Forming Adjacencies on Point-to-Point Links 360 o Link Up with Information Already in the Database 362 o Initial convergence Time on a Designated Router Electing (Broad- 363 cast) Network 365 o Link Down with Layer 2 Detection 366 o Link Down with Layer 3 Detection 368 o Designated Router Election Time on A Broadcast Network 370 6.1. Forming Adjacencies on Point-to-Point Link (Initialization) 372 This test measures the time required to form an OSPF adjacency from 373 the time a layer two (data link) connection is formed between two 374 devices running OSPF. 376 o Use reference topology 1 (Emulated Topology), beginning with the 377 link between the generator and DUT disabled on the DUT. OSPF 378 should be configured and operating on both devices. 380 o Inject a set of LSAs from the generator towards the DUT. 382 o Bring the link up at the DUT, noting the time that the link car- 383 rier is established on the generator. 385 o Note the time the acknowledgement for the last LSA transmitted 386 from the DUT is received on the generator. 388 The time between the carrier establishment and the acknowledgement 389 for the last LSA transmitted by the generator should be taken as the 390 total amount of time required for the OSPF process on the DUT to 391 react to a link up event with the set of LSAs injected, including the 392 time required for the operating system to notify the OSPF process 393 about the link up, etc.. The acknowledgement for the last LSA 394 transmitted is used instead of the last acknowledgement received in 395 order to prevent timing skews due to retransmitted acknowledgements 396 or LSAs. 398 6.2. Forming Adjacencies on Point-to-Point Links 400 This test measures the time required to form an adjacency from the 401 time the first communication occurs between two devices running OSPF. 403 o Using reference topology 1 (Emulated Topology), configure the 404 DUT and the generator so traffic can be passed along the link 405 between them. 407 o Configure the generator so OSPF is running on the point-to-point 408 link towards the DUT, and inject a set of LSAs. 410 o Configure the DUT so OSPF is initialized, but not running on the 411 point-to-point link between the DUT and the generator. 413 o Enable OSPF on the interface between the DUT and the generator 414 on the DUT. 416 o Note the time of the first hello received from the DUT on the 417 generator. 419 o Note the time of the acknowledgement from the DUT for the last 420 LSA transmitted on the generator. 422 The time between the first hello received and the acknowledgement for 423 the last LSA transmitted by the generator should be taken as the 424 total amount of time required for the OSPF process on the DUT to 425 build a FULL neighbor adjacency with the set of LSAs injected. The 426 acknowledgement for the last LSA transmitted is used instead of the 427 last acknowledgement received in order to prevent timing skews due to 428 retransmitted acknowledgements or LSAs. 430 6.3. Forming adjacencies with Information Already in the Database 432 o Using reference topology 2 (Generator and Collector), configure 433 all three devices to run OSPF. 435 o Configure the DUT so the link between the DUT and the generator 436 is disabled . 438 o Inject a set of LSAs into the network from the generator; the 439 DUT should receive these LSAs through normal flooding from the 440 collector. 442 o Enable the link between the DUT and the generator. 444 o Note the time of the first hello received from the DUT on the 445 generator. 447 o Note the time of the last DBD received on the generator. 449 o Note the time of the acknowledgement from the DUT for the last 450 LSA transmitted on the generator. 452 The time between the hello received from the DUT by the generator and 453 the acknowledgement for the last LSA transmitted by the generator 454 should be taken as the total amount of time required for the OSPF 455 process on the DUT to build a FULL neighbor adjacency with the set of 456 LSAs injected. In this test, the DUT is already aware of the entire 457 network topology, so the time required should only include the pro- 458 cessing of DBDs exchanged when in EXCHANGE state, the time to build a 459 new router LSA containing the new connection information, and the 460 time required to flood and acknowledge this new router LSA. 462 The acknowledgement for the last LSA transmitted is used instead of 463 the last acknowledgement received in order to prevent timing skews 464 due to retransmitted acknowledgements or LSAs. 466 6.4. Designated Router Election Time on A Broadcast Network 468 o Using reference topology 3 (Broadcast Network), configure R1 to 469 be the designated router on the link, and the DUT to be the 470 backup designated router. 472 o Enable OSPF on the common broadcast link on all the routers in 473 the test bed. 475 o Disable the broadcast link on R1. 477 o Note the time of the last hello received from R1 on R2. 479 o Note the time of the first network LSA generated by the DUT as 480 received on R2. 482 The time between the last hello received on R2 and the first network 483 LSA generated by the DUT should be taken as the amount of time 484 required for the DUT to complete a designated router election compu- 485 tation. Note this test includes the dead interval timer at the DUT, 486 so this time may be factored out, or the hello and dead intervals 487 reduced to make these timers impact the overall test times less. All 488 changed timers, the number of routers connected to the link, and 489 other variable factors should be noted in the test results. 491 Note: If R1 sends a "goodbye hello," typically a hello with its 492 neighbor list empty, in the process of shutting down its interface, 493 using the time this hello is received instead of the time of the last 494 hello received would provide a more accurate measurement. 496 6.5. Initial Convergence Time on a Broadcast Network, Test 1 498 o Using reference topology 3 (Broadcast Network), begin with the 499 DUT connected to the network with OSPF enabled. OSPF should be 500 enabled on R1, but the broadcast link should be disabled. 502 o Enable the broadcast link between R1 and the DUT. Note the time 503 of the first hello received by R1. 505 o Note the time the first network LSA is flooded by the DUT at R1. 507 o The differential between the first hello and the first network 508 LSA is the time required by the DUT to converge on this new 509 topology. 511 This test assumes that the DUT will be the designated router on the 512 broadcast link. A similar test could be designed to test the conver- 513 gence time when the DUT is not the designated router as well. 515 This test may be performed with varying numbers of devices attached 516 to the broadcast network, and varying sets of LSAs being advertised 517 to the DUT from the routers attached to the broadcast network. Varia- 518 tions in the LSA sets and other factors should be noted in the test 519 results. 521 The time required to elect a designated router, as measured in Desig- 522 nated Router Election Time on A Broadcast Network, above, may be sub- 523 tracted from the results of this test to provide just the convergence 524 time across a broadcast network. 526 Note all the other tests in the document include route calculation 527 time in the convergence time, as described in [TERM], this test may 528 not include route calculation time in the resulting measured conver- 529 gence time, because initial route calculation may occur after the 530 first network LSA is flooded. 532 6.6. Initial Convergence Time on a Broadcast Network, Test 2 534 o Using reference topology 3 (Broadcast Network), begin with the 535 DUT connected to the network with OSPF enabled. OSPF should be 536 enabled on R1, but the broadcast link should be disabled. 538 o Enable the broadcast link between R1 and the DUT. Note the time 539 of the first hello transmitted by the DUT with a designated 540 router listed. 542 o Note the time the first network LSA is flooded by the DUT at R1. 544 o The differential between the first hello with a designated 545 router lists and the first network LSA is the time required by 546 the DUT to converge on this new topology. 548 6.7. Link Down with Layer 2 Detection 550 o Using reference topology 4 (Parallel Links), begin with OSPF in 551 the full state between the generator and the DUT. Both links 552 should be point-to-point links with the ability to notify the 553 operating system immediately upon link failure. 555 o Disable link 1; this should be done in such a way that the 556 keepalive timers at the data link layer will have no impact on 557 the DUT recognizing the link failure (the operating system in 558 the DUT should recognize this link failure immediately). Discon- 559 necting the cable on the generator end would be one possibility, 560 or shutting the link down. 562 o Note the time of the link failure on the generator. 564 o At the generator, note the time of the receipt of the new router 565 LSA from the DUT notifying the generator of the link 2 failure. 567 The difference in the time between the initial link failure and 568 the receipt of the LSA on the generator across link 2 should be 569 taken as the time required for an OSPF implementation to recog- 570 nize and process a link failure, including the time required to 571 generate and flood an LSA describing the link down event to an 572 adjacent neighbor. 574 6.8. Link Down with Layer 3 Detection 576 o Using reference topology 4 (Parallel Links), begin with OSPF in 577 the full state between the generator and the DUT. 579 o Disable OSPF processing on link 1 from the generator. This 580 should be done in such a way so it does not affect link status; 581 the DUT MUST note the failure of the adjacency through the dead 582 interval. 584 o At the generator, note the time of the receipt of the new router 585 LSA from the DUT notifying the generator of the link 2 failure. 587 The difference in the time between the initial link failure and the 588 receipt of the LSA on the generator across link 2 should be taken as 589 the time required for an OSPF implementation to recognize and process 590 an adjacency failure. 592 7. IANA Considerations 594 This document requires no IANA considerations. 596 8. Security Considerations 598 This document does not modify the underlying security considerations 599 in [OSPF]. 601 9. Acknowledgements 603 Thanks to Howard Berkowitz, (hcb@clark.net), for his encouragement 604 and support. Thanks also to Alex Zinin (zinin@psg.net), Gurpreet 605 Singh (Gurpreet.Singh@SpirentCom.COM), and Yasuhiro Ohara 606 (yasu@sfc.wide.ad.jp) for their comments as well. 608 10. Normative References 610 [OPSF]Moy, J., "OSPF Version 2", RFC 2328, April 1998. 612 [TERM]Manral, V., "OSPF Convergence Testing Terminology and Con- 613 cepts", draft-ietf-bmwg-ospfconv-term-10, June 2004 615 [CONSIDERATIONS] 616 Manral, V., "Considerations When Using Basic OSPF Convergence 617 Benchmarks", draft-ietf-bmwg-ospfconv-applicability-07, June 618 2004 620 [RFC2119] 621 Bradner, S., "Key words for use in RFCs to Indicate Requirement 622 Levels", BCP 14, RFC 2119, March 1997 624 11. Informative References 626 [INTERCONNECT] 627 Bradner, S., McQuaid, J., "Benchmarking Methodology for Network 628 Interconnect Devices", RFC2544, March 1999. 630 [MILLISEC] 631 Alaettinoglu C., et al., "Towards Milli-Second IGP Convergence" 632 draft-alaettinoglu-isis-convergence 634 [FIB-TERM] 635 Trotter, G., "Terminology for Forwarding Information Base (FIB) 636 based Router Performance", RFC3222, October 2001. 638 [BLACKBOX] 639 Shaikh, Aman, Greenberg, Albert, "Experience in Black-Box OSPF 640 measurement" 642 12. Authors' Addresses 644 Vishwas Manral 645 Netplane Systems 646 189 Prashasan Nagar 647 Road number 72 648 Jubilee Hills 649 Hyderabad, India 651 vmanral@netplane.com 653 Russ White 654 Cisco Systems, Inc. 655 7025 Kit Creek Rd. 656 Research Triangle Park, NC 27709 658 riw@cisco.com 660 Aman Shaikh 661 AT&T Labs (Research) 662 180, Park Av 663 Florham Park, NJ 07932 665 ashaikh@research.att.com 667 Intellectual Property Statement 669 The IETF takes no position regarding the validity or scope of any Intel- 670 lectual Property Rights or other rights that might be claimed to pertain 671 to the implementation or use of the technology described in this docu- 672 ment or the extent to which any license under such rights might or might 673 not be available; nor does it represent that it has made any independent 674 effort to identify any such rights. Information on the procedures with 675 respect to rights in RFC documents can be found in BCP 78 and BCP 79. 677 Copies of IPR disclosures made to the IETF Secretariat and any 678 assurances of licenses to be made available, or the result of an attempt 679 made to obtain a general license or permission for the use of such 680 proprietary rights by implementers or users of this specification can be 681 obtained from the IETF on-line IPR repository at 682 http://www.ietf.org/ipr. 684 The IETF invites any interested party to bring to its attention any 685 copyrights, patents or patent applications, or other proprietary rights 686 that may cover technology that may be required to implement this stan- 687 dard. Please address the information to the IETF at ietf-ipr@ietf.org. 689 Disclaimer of Warranty 691 This document and the information contained herein are provided on an 692 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 693 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 694 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 695 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMA- 696 TION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 697 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 699 Copyright Statement 701 Copyright (C) The Internet Society (2004). This document is subject to 702 the rights, licenses and restrictions contained in BCP 78, and except as 703 set forth therein, the authors retain all their rights.