idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-meth-05.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 21. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 651. ** 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. 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 5. Security Considerations' ) ** 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 document seems to lack an Authors' Addresses Section. ** There are 6 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** There are 341 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [3], [4], [Br97], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 262 has weird spacing: '...ET with minim...' -- 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 (October 2005) is 6761 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? '1' on line 606 looks like a reference -- Missing reference section? '2' on line 610 looks like a reference -- Missing reference section? '3' on line 614 looks like a reference -- Missing reference section? '4' on line 617 looks like a reference -- Missing reference section? 'Br97' on line 103 looks like a reference Summary: 15 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group 2 INTERNET-DRAFT 3 Expires in: October 2005 4 Scott Poretsky 5 Quarry Technologies 7 Brent Imhoff 8 LightCore 10 February 2005 12 Benchmarking Methodology for 13 IGP Data Plane Route Convergence 15 17 Intellectual Property Rights (IPR) statement: 18 By submitting this Internet-Draft, I certify that any applicable 19 patent or other IPR claims of which I am aware have been disclosed, or 20 will be disclosed, and any of which I become aware will be disclosed, 21 in accordance with RFC 3668. 23 Status of this Memo 25 This document is an Internet-Draft and is in full conformance with 26 all provisions of Section 10 of RFC2026. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other 35 documents at any time. It is inappropriate to use Internet-Drafts 36 as reference material or to cite them other than as "work in 37 progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 ABSTRACT 46 This draft describes the methodology for benchmarking IGP Route 47 Convergence as described in Applicability document [1] and 48 Terminology document [2]. The methodology and terminology are 49 to be used for benchmarking route convergence and can be applied 50 to any link-state IGP such as ISIS [3] and OSPF [4]. The terms 51 used in the procedures provided within this document are 52 defined in [2]. 54 IGP Data Plane Route Convergence 56 Table of Contents 57 1. Introduction ...............................................2 58 2. Existing definitions .......................................2 59 3. Test Setup..................................................3 60 3.1 Test Topologies............................................3 61 3.2 Test Considerations........................................4 62 3.3 Reporting Format...........................................6 63 4. Test Cases..................................................6 64 4.1 Convergence Due to Link Failure............................6 65 4.1.1 Convergence Due to Local Interface Failure...............6 66 4.1.2 Convergence Due to Neighbor Interface Failure............7 67 4.1.3 Convergence Due to Remote Interface Failure..............7 68 4.2 Convergence Due to Layer 2 Session Failure.................8 69 4.3 Convergence Due to IGP Adjacency Failure...................9 70 4.4 Convergence Due to Route Withdrawal........................9 71 4.5 Convergence Due to Cost Change.............................10 72 4.6 Convergence Due to ECMP Member Interface Failure...........10 73 4.7 Convergence Due to Parallel Link Interface Failure.........11 74 5. Security Considerations.....................................12 75 6. Normative References........................................12 76 7. Author's Address............................................12 78 1. Introduction 79 This draft describes the methodology for benchmarking IGP Route 80 Convergence. The applicability of this testing is described in 81 [1] and the new terminology that it introduces is defined in [2]. 82 Service Providers use IGP Convergence time as a key metric of 83 router design and architecture. Customers of Service Providers 84 observe convergence time by packet loss, so IGP Route Convergence 85 is considered a Direct Measure of Quality (DMOQ). The test cases 86 in this document are black-box tests that emulate the network 87 events that cause route convergence, as described in [1]. The 88 black-box test designs benchmark the data plane accounting for 89 all of the factors contributing to convergence time, as discussed 90 in [1]. The methodology (and terminology) for benchmarking route 91 convergence can be applied to any link-state IGP such as ISIS [3] 92 and OSPF [4]. These methodologies apply to IPv4 and IPv6 traffic 93 as well as IPv4 and IPv6 IGPs. 95 2. Existing definitions 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in BCP 14, RFC 2119 99 [Br97]. RFC 2119 defines the use of these key words to help make the 100 intent of standards track documents as clear as possible. While this 101 document uses these keywords, this document is not a standards track 102 document. 104 IGP Data Plane Route Convergence 106 3. Test Setup 107 3.1 Test Topologies 108 Figure 1 shows the test topology to measure IGP Route Convergence due 109 to local Convergence Events such as SONET Link Failure, Layer 2 Session 110 Failure, IGP Adjacency Failure, Route Withdrawal, and route cost 111 change. These test cases discussed in section 4 provide route 112 convergence times that account for the Event Detection time, SPF 113 Processing time, and FIB Update time. These times are measured 114 by observing packet loss in the data plane. 116 --------- Ingress Interface --------- 117 | |<------------------------------| | 118 | | | | 119 | | Preferred Egress Interface | | 120 | DUT |------------------------------>|Tester | 121 | | | | 122 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| | 123 | | Next-Best Egress Interface | | 124 --------- --------- 126 Figure 1. IGP Route Convergence Test Topology for Local Changes 128 Figure 2 shows the test topology to measure IGP Route Convergence 129 time due to remote changes in the network topology. These times are 130 measured by observing packet loss in the data plane. In this 131 topology the three routers are considered a System Under Test (SUT). 132 NOTE: All routers in the SUT must be the same model and identically configured. 134 ----- ----------- 135 | | Preferred | | 136 ----- |R2 |---------------------->| | 137 | |-->| | Egress Interface | | 138 | | ----- | | 139 |R1 | | Tester | 140 | | ----- | | 141 | |-->| | Next-Best | | 142 ----- |R3 |~~~~~~~~~~~~~~~~~~~~~~>| | 143 ^ | | Egress Interface | | 144 | ----- ----------- 145 | | 146 |-------------------------------------- 147 Ingress Interface 149 Figure 2. IGP Route Convergence Test Topology 150 for Remote Changes 152 Figure 3 shows the test topology to measure IGP Route Convergence 153 time with members of an Equal Cost Multipath (ECMP) Set. These times are 154 measured by observing packet loss in the data plane. In this topology, 155 the DUT 156 IGP Data Plane Route Convergence 158 is configured with each Egress interface as a member of an ECMP set 159 and the Tester emulates multiple next-hop routers (emulates one 160 router for each member). 162 --------- Ingress Interface --------- 163 | |<--------------------------------| | 164 | | | | 165 | | ECMP Set Interface 1 | | 166 | DUT |-------------------------------->| Tester| 167 | | . | | 168 | | . | | 169 | | . | | 170 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| | 171 | | ECMP Set Interface N | | 172 --------- --------- 174 Figure 3. IGP Route Convergence Test Topology 175 for ECMP Convergence 177 Figure 4 shows the test topology to measure IGP Route Convergence 178 time with members of a Parallel Link. These times are measured by 179 observing packet loss in the data plane. In this topology, the DUT 180 is configured with each Egress interface as a member of a Parallel 181 Link and the Tester emulates the single next-hop router. 183 --------- Ingress Interface --------- 184 | |<--------------------------------| | 185 | | | | 186 | | Parallel Link Interface 1 | | 187 | DUT |-------------------------------->| Tester| 188 | | . | | 189 | | . | | 190 | | . | | 191 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| | 192 | | Parallel Link Interface N | | 193 --------- --------- 195 Figure 4. IGP Route Convergence Test Topology 196 for Parallel Link Convergence 198 3.2 Test Considerations 199 3.2.1 IGP Selection 200 The test cases described in section 4 can be used for ISIS or 201 OSPF. The Route Convergence test methodology for both is 202 identical. The IGP adjacencies are established on the Preferred 203 Egress Interface and Next-Best Egress Interface. 205 3.2.2 BGP Configuration 206 The obtained results for IGP Route Convergence may vary if 207 BGP routes are installed. It is recommended that the IGP 208 Convergence times be benchmarked without BGP routes installed. 210 IGP Data Plane Route Convergence 212 3.2.3 IGP Route Scaling 213 The number of IGP routes will impact the measured IGP Route 214 Convergence because convergence for the entire IGP route table is 215 measured. For results similar to those that would be observed in 216 an operational network it is recommended that the number of 217 installed routes closely approximate that for routers in the 218 network. The number of areas (for OSPF) and levels (for ISIS) can 219 impact the benchmark results. 221 3.2.4 Timers 222 There are some timers that will impact the measured IGP Convergence 223 time. The following timers should be configured to the minimum value 224 prior to beginning execution of the test cases: 226 Timer Recommended Value 227 ----- ----------------- 228 Failure Indication Delay <10milliseconds 229 IGP Hello Timer 1 second 230 IGP Dead-Interval 3 seconds 231 LSA Generation Delay 0 232 LSA Flood Packet Pacing 0 233 LSA Retransmission Packet Pacing 0 234 SPF Delay 0 236 3.2.5 Convergence Time Metrics 237 The recommended value for the Packet Sampling Interval [2] is 238 100 milliseconds. Rate-Derived Convergence Time [2] is the 239 preferred benchmark for IGP Route Convergence. This benchmark 240 must always be reported when the Packet Sampling Interval [2] 241 <= 100 milliseconds. If the test equipment does not permit 242 the Packet Sampling Interval to be set as low as 100 msec, 243 then both the Rate-Derived Convergence Time and Loss-Derived 244 Convergence Time [2] must be reported. The Packet Sampling 245 Interval value is the smallest measurable convergence time. 247 3.2.6 Offered Load 248 An offered Load of maximum forwarding rate at a fixed packet size 249 is recommended for accurate measurement. Forwarding Rate must be 250 measured at the Preferred Egress Interface and the Next-Best 251 Egress Interface. The duration of offered load must be greater 252 than the convergence time. The destinations for the offered load 253 must be distributed such that all routes are matched. This 254 enables Full Convergence [2] to be observed. 256 3.2.7 Interface Types 257 All test cases in this methodology document may be executed with 258 any interface type. All interfaces MUST BE the same media and 259 link speed for each test case. Media and protocols MUST be 260 configured for minimum failure detection delay to minimize the 261 contribution to the measured Convergence time. For example, 262 configure SONET with minimum carrier-loss-delay. 264 IGP Data Plane Route Convergence 266 3.3 Reporting Format 267 For each test case, it is recommended that the following reporting 268 format be completed: 270 Parameter Units 271 --------- ----- 272 IGP (ISIS or OSPF) 273 Interface Type (GigE, POS, ATM, etc.) 274 Packet Size bytes 275 IGP Routes number of IGP routes 276 Packet Sampling Interval seconds or milliseconds 277 IGP Timer Values 278 SONET Failure Indication Delay seconds or milliseconds 279 IGP Hello Timer seconds or milliseconds 280 IGP Dead-Interval seconds or milliseconds 281 LSA Generation Delay seconds or milliseconds 282 LSA Flood Packet Pacing seconds or milliseconds 283 LSA Retransmission Packet Pacing seconds or milliseconds 284 SPF Delay seconds or milliseconds 285 Benchmarks 286 Rate-Derived Convergence Time seconds or milliseconds 287 Loss-Derived Convergence Time seconds or milliseconds 288 Restoration Convergence Time seconds or milliseconds 290 4. Test Cases 291 4.1 Convergence Due to Link Failure 292 4.1.1 Convergence Due to Local Interface Failure 293 Objective 294 To obtain the IGP Route Convergence due to a local link 295 failure event at the DUT's Local Interface. 297 Procedure 298 1. Advertise matching IGP routes from Tester to DUT on 299 Preferred Egress Interface [2] and Next-Best Egress Interface 300 [2] using the topology shown in Figure 1. Set the cost of the 301 routes so that the Preferred Egress Interface is the preferred 302 next-hop. 303 2. Send traffic at maximum forwarding rate to destinations 304 matching all IGP routes from Tester to DUT on Ingress Interface 305 [2]. 306 3. Verify traffic routed over Preferred Egress Interface. 307 4. Remove SONET on DUT's Local Interface [2] by performing an 308 administrative shutdown of the interface. 309 5. Measure Rate-Derived Convergence Time [2] as DUT detects the 310 link down event and converges all IGP routes and traffic over 311 the Next-Best Egress Interface. 312 6. Stop offered load. Wait 30 seconds for queues to drain. 313 Restart Offered Load. 314 7. Restore SONET on DUT's Local Interface by administratively 315 enabling the interface. 317 IGP Data Plane Route Convergence 319 8. Measure Restoration Convergence Time [2] as DUT detects the link 320 up event and converges all IGP routes and traffic back to the 321 Preferred Egress Interface. 323 Results 324 The measured IGP Convergence time is influenced by the Local 325 SONET indication, SPF delay, SPF Holdtime, SPF Execution 326 Time, Tree Build Time, and Hardware Update Time. 328 4.1.2 Convergence Due to Neighbor Interface Failure 329 Objective 330 To obtain the IGP Route Convergence due to a local link 331 failure event at the Tester's Neighbor Interface. 333 Procedure 334 1. Advertise matching IGP routes from Tester to DUT on 335 Preferred Egress Interface [2] and Next-Best Egress Interface 336 [2] using the topology shown in Figure 1. Set the cost of 337 the routes so that the Preferred Egress Interface is the 338 preferred next-hop. 339 2. Send traffic at maximum forwarding rate to destinations matching 340 all IGP routes from Tester to DUT on Ingress Interface [2]. 341 3. Verify traffic routed over Preferred Egress Interface. 342 4. Remove SONET on Tester's Neighbor Interface [2] connected to 343 DUT' s Preferred Egress Interface. 344 5. Measure Rate-Derived Convergence Time [2] as DUT detects the 345 link down event and converges all IGP routes and traffic over 346 the Next-Best Egress Interface. 347 6. Stop offered load. Wait 30 seconds for queues to drain. 348 Restart Offered Load. 349 7. Restore SONET on Tester's Neighbor Interface connected to 350 DUT's Preferred Egress Interface. 351 8. Measure Restoration Convergence Time [2] as DUT detects the 352 link up event and converges all IGP routes and traffic back to 353 the Preferred Egress Interface. 355 Results 356 The measured IGP Convergence time is influenced by the Local 357 SONET indication, SPF delay, SPF Holdtime, SPF Execution 358 Time, Tree Build Time, and Hardware Update Time. 360 4.1.3 Convergence Due to Remote Interface Failure 361 Objective 362 To obtain the IGP Route Convergence due to a Remote Interface 363 Failure event. 365 Procedure 366 1. Advertise matching IGP routes from Tester to SUT on 367 Preferred Egress Interface [2] and Next-Best Egress Interface 368 [2] using the topology shown in Figure 2. Set the cost of the 369 routes so that the Preferred Egress Interface is the preferred 370 next-hop. 372 IGP Data Plane Route Convergence 374 2. Send traffic at maximum forwarding rate to destinations matching 375 all IGP routes from Tester to DUT on Ingress Interface [2]. 376 3. Verify traffic is routed over Preferred Egress Interface. 377 4. Remove SONET on Tester's Neighbor Interface [2] connected to 378 SUT' s Preferred Egress Interface. 379 5. Measure Rate-Derived Convergence Time [2] as SUT detects 380 the link down event and converges all IGP routes and traffic 381 over the Next-Best Egress Interface. 382 6. Stop offered load. Wait 30 seconds for queues to drain. 383 Restart Offered Load. 384 7. Restore SONET on Tester's Neighbor Interface connected to 385 DUT's Preferred Egress Interface. 386 8. Measure Restoration Convergence Time [2] as DUT detects the 387 link up event and converges all IGP routes and traffic back to 388 the Preferred Egress Interface. 390 Results 391 The measured IGP Convergence time is influenced by the 392 SONET failure indication, LSA/LSP Flood Packet Pacing, 393 LSA/LSP Retransmission Packet Pacing, LSA/LSP Generation 394 time, SPF delay, SPF Holdtime, SPF Execution Time, Tree 395 Build Time, and Hardware Update Time. The additional 396 convergence time contributed by LSP Propagation can be 397 obtained by subtracting the Rate-Derived Convergence Time 398 measured in 4.1.2 (Convergence Due to Neighbor Interface 399 Failure) from the Rate-Derived Convergence Time measured in 400 this test case. 402 4.2 Convergence Due to Layer 2 Session Failure 403 Objective 404 To obtain the IGP Route Convergence due to a Local Layer 2 Session 405 failure event. 407 Procedure 408 1. Advertise matching IGP routes from Tester to DUT on 409 Preferred Egress Interface [2] and Next-Best Egress Interface 410 [2] using the topology shown in Figure 1. Set the cost of 411 the routes so that the IGP routes along the Preferred Egress 412 Interface is the preferred next-hop. 413 2. Send traffic at maximum forwarding rate to destinations 414 matching all IGP routes from Tester to DUT on Ingress 415 Interface [2]. 416 3. Verify traffic routed over Preferred Egress Interface. 417 4. Remove Layer 2 session from Tester's Neighbor Interface [2] 418 connected to Preferred Egress Interface. 419 5. Measure Rate-Derived Convergence Time [2] as DUT detects the 420 Layer 2 session down event and converges all IGP routes and 421 traffic over the Next-Best Egress Interface. 422 6. Restore Layer 2 session on DUT's Preferred Egress Interface. 423 7. Measure Restoration Convergence Time [2] as DUT detects the 424 session up event and converges all IGP routes and traffic over 425 the Preferred Egress Interface. 427 IGP Data Plane Route Convergence 428 Results 429 The measured IGP Convergence time is influenced by the Layer 2 430 failure indication, SPF delay, SPF Holdtime, SPF Execution 431 Time, Tree Build Time, and Hardware Update Time. 433 4.3 Convergence Due to IGP Adjacency Failure 435 Objective 436 To obtain the IGP Route Convergence due to a Local IGP Adjacency 437 failure event. 439 Procedure 440 1. Advertise matching IGP routes from Tester to DUT on 441 Preferred Egress Interface [2] and Next-Best Egress Interface 442 [2] using the topology shown in Figure 1. Set the cost of 443 the routes so that the Preferred Egress Interface is the 444 preferred next-hop. 445 2. Send traffic at maximum forwarding rate to destinations 446 matching all IGP routes from Tester to DUT on Ingress 447 Interface [2]. 448 3. Verify traffic routed over Preferred Egress Interface. 449 4. Remove IGP adjacency from Tester's Neighbor Interface [2] 450 connected to Preferred Egress Interface. 451 5. Measure Rate-Derived Convergence Time [2] as DUT detects the 452 IGP session failure event and converges all IGP routes and 453 traffic over the Next-Best Egress Interface. 454 6. Stop offered load. Wait 30 seconds for queues to drain. 455 Restart Offered Load. 456 7. Restore IGP session on DUT's Preferred Egress Interface. 457 8. Measure Restoration Convergence Time [2] as DUT detects the 458 session up event and converges all IGP routes and traffic over 459 the Preferred Egress Interface. 461 Results 462 The measured IGP Convergence time is influenced by the IGP 463 Hello Interval, IGP Dead Interval, SPF delay, SPF Holdtime, 464 SPF Execution Time, Tree Build Time, and Hardware Update 465 Time. 467 4.4 Convergence Due to Route Withdrawal 469 Objective 470 To obtain the IGP Route Convergence due to Route Withdrawal. 472 Procedure 473 1. Advertise matching IGP routes from Tester to DUT on 474 Preferred Egress Interface [2] and Next-Best Egress Interface 475 [2] using the topology shown in Figure 1. Set the cost of 476 the routes so that the Preferred Egress Interface is the 477 preferred next-hop. 478 2. Send traffic at maximum forwarding rate to destinations 479 matching all IGP routes from Tester to DUT on Ingress 480 Interface [2]. 482 IGP Data Plane Route Convergence 484 3. Verify traffic routed over Preferred Egress Interface. 485 4. Tester withdraws all IGP routes from DUT's Local Interface 486 on Preferred Egress Interface. 487 6. Stop offered load. Wait 30 seconds for queues to drain. 488 Restart Offered Load. 489 7. Re-advertise IGP routes to DUT's Preferred Egress Interface. 490 8. Measure Restoration Convergence Time [2] as DUT converges all 491 IGP routes and traffic over the Preferred Egress Interface. 493 Results 494 The measured IGP Convergence time is the SPF Processing and FIB 495 Update time as influenced by the SPF delay, SPF Holdtime, 496 SPF Execution Time, Tree Build Time, and Hardware Update Time. 498 4.5 Convergence Due to Cost Change 500 Objective 501 To obtain the IGP Route Convergence due to route cost change. 503 Procedure 504 1. Advertise matching IGP routes from Tester to DUT on 505 Preferred Egress Interface [2] and Next-Best Egress Interface 506 [2] using the topology shown in Figure 1. Set the cost of 507 the routes so that the Preferred Egress Interface is the 508 preferred next-hop. 509 2. Send traffic at maximum forwarding rate to destinations 510 matching all IGP routes from Tester to DUT on Ingress 511 Interface [2]. 512 3. Verify traffic routed over Preferred Egress Interface. 513 4. Tester increases cost for all IGP routes at DUT's Preferred 514 Egress Interface so that the Next-Best Egress Interface 515 has lower cost and becomes preferred path. 516 5. Measure Rate-Derived Convergence Time [2] as DUT detects the 517 cost change event and converges all IGP routes and traffic 518 over the Next-Best Egress Interface. 519 6. Stop offered load. Wait 30 seconds for queues to drain. 520 Restart Offered Load. 521 7. Re-advertise IGP routes to DUT's Preferred Egress Interface 522 with original lower cost metric. 523 8. Measure Restoration Convergence Time [2] as DUT converges all 524 IGP routes and traffic over the Preferred Egress Interface. 526 Results 527 There should be no measured packet loss for this case. 529 4.6 Convergence Due to ECMP Member Interface Failure 531 Objective 532 To obtain the IGP Route Convergence due to a local link 533 failure event of an ECMP Member. 535 IGP Data Plane Route Convergence 537 Procedure 538 1. Configure ECMP Set as shown in Figure 3. 539 2. Advertise matching IGP routes from Tester to DUT on 540 each ECMP member. 541 3. Send traffic at maximum forwarding rate to destinations 542 matching all IGP routes from Tester to DUT on Ingress 543 Interface [2]. 544 4. Verify traffic routed over all members of ECMP Set. 545 5. Remove SONET on Tester's Neighbor Interface [2] connected to 546 one of the DUT's ECMP member interfaces. 547 6. Measure Rate-Derived Convergence Time [2] as DUT detects the 548 link down event and converges all IGP routes and traffic 549 over the other ECMP members. 550 7. Stop offered load. Wait 30 seconds for queues to drain. 551 Restart Offered Load. 552 8. Restore SONET on Tester's Neighbor Interface connected to 553 DUT's ECMP member interface. 554 9. Measure Restoration Convergence Time [2] as DUT detects the 555 link up event and converges IGP routes and some distribution 556 of traffic over the restored ECMP member. 558 Results 559 The measured IGP Convergence time is influenced by the Local 560 SONET indication, Tree Build Time, and Hardware Update Time. 562 4.7 Convergence Due to Parallel Link Interface Failure 564 Objective 565 To obtain the IGP Route Convergence due to a local link failure 566 event for a Member of a Parallel Link. The links can be used for 567 data Load Balancing 569 Procedure 570 1. Configure Parallel Link as shown in Figure 4. 571 2. Advertise matching IGP routes from Tester to DUT on 572 each Parallel Link member. 573 3. Send traffic at maximum forwarding rate to destinations 574 matching all IGP routes from Tester to DUT on Ingress 575 Interface [2]. 576 4. Verify traffic routed over all members of Parallel Link. 577 5. Remove SONET on Tester's Neighbor Interface [2] connected to 578 one of the DUT's Parallel Link member interfaces. 579 6. Measure Rate-Derived Convergence Time [2] as DUT detects the 580 link down event and converges all IGP routes and traffic over 581 the other Parallel Link members. 582 7. Stop offered load. Wait 30 seconds for queues to drain. 583 Restart Offered Load. 584 8. Restore SONET on Tester's Neighbor Interface connected to 585 DUT's Parallel Link member interface. 587 IGP Data Plane Route Convergence 589 9. Measure Restoration Convergence Time [2] as DUT detects the 590 link up event and converges IGP routes and some distribution 591 of traffic over the restored Parallel Link member. 593 Results 594 The measured IGP Convergence time is influenced by the Local 595 SONET indication, Tree Build Time, and Hardware Update Time. 597 5. Security Considerations 599 Documents of this type do not directly affect the security of 600 the Internet or corporate networks as long as benchmarking 601 is not performed on devices or systems connected to operating 602 networks. 604 6. Normative References 606 [1] Poretsky, S., "Benchmarking Applicability for IGP 607 Convergence", draft-ietf-bmwg-igp-dataplane-conv-app-05, work 608 in progress, February 2005. 610 [2] Poretsky, S., Imhoff, B., "Benchmarking Terminology for IGP 611 Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-05, work 612 in progress, February 2005 614 [3] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual 615 Environments", RFC 1195, December 1990. 617 [4] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 619 7. Author's Address 621 Scott Poretsky 622 Quarry Technologies 623 8 New England Executive Park 624 Burlington, MA 01803 625 USA 627 Phone: + 1 781 395 5090 628 EMail: sporetsky@quarrytech.com 630 Brent Imhoff 631 LightCore 632 USA 633 EMail: bimhoff@planetspork.com 634 IGP Data Plane Route Convergence 636 Intellectual Property Statement 638 The IETF takes no position regarding the validity or scope of any Intel- 639 lectual Property Rights or other rights that might be claimed to pertain 640 to the implementation or use of the technology described in this docu- 641 ment or the extent to which any license under such rights might or might 642 not be available; nor does it represent that it has made any independent 643 effort to identify any such rights. Information on the procedures with 644 respect to rights in RFC documents can be found in BCP 78 and BCP 79. 646 Copies of IPR disclosures made to the IETF Secretariat and any 647 assurances of licenses to be made available, or the result of an attempt 648 made to obtain a general license or permission for the use of such 649 proprietary rights by implementers or users of this specification can be 650 obtained from the IETF on-line IPR repository at 651 http://www.ietf.org/ipr. 653 The IETF invites any interested party to bring to its attention any 654 copyrights, patents or patent applications, or other proprietary rights 655 that may cover technology that may be required to implement this stan- 656 dard. Please address the information to the IETF at ietf-ipr@ietf.org. 658 Disclaimer of Warranty 660 This document and the information contained herein are provided on an 661 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 662 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 663 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 664 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMA- 665 TION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 666 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 668 Copyright Statement 670 Copyright (C) The Internet Society (2005). This document is subject to 671 the rights, licenses and restrictions contained in BCP 78, and except as 672 set forth therein, the authors retain all their rights.