idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-meth-13.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 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 697. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 708. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 715. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 723. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 135 has weird spacing: '...In this topo...' == Line 292 has weird spacing: '...n Delay seco...' == Line 300 has weird spacing: '...ce Time secon...' == Line 301 has weird spacing: '...ce Time secon...' == Line 302 has weird spacing: '...ce Time seco...' -- 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 (January 2008) is 5946 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-bmwg-igp-dataplane-conv-app-13 == Outdated reference: A later version (-23) exists of draft-ietf-bmwg-igp-dataplane-conv-term-13 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 7 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: January 2008 4 Intended Status: Informational 5 Scott Poretsky 6 Reef Point Systems 8 Brent Imhoff 9 Juniper Networks 11 July 2007 13 Benchmarking Methodology for 14 IGP Data Plane Route Convergence 16 18 Intellectual Property Rights (IPR) statement: 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Status of this Memo 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as 29 Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 ABSTRACT 46 This document describes the methodology for benchmarking Interior 47 Gateway Protocol (IGP) Route Convergence. The methodology is to 48 be used for benchmarking IGP convergence time through externally 49 observable (black box) data plane measurements. The methodology 50 can be applied to any link-state IGP, such as ISIS and OSPF. 52 IGP Data Plane Route Convergence 54 Table of Contents 55 1. Introduction ...............................................2 56 2. Existing definitions .......................................2 57 3. Test Setup..................................................3 58 3.1 Test Topologies............................................3 59 3.2 Test Considerations........................................4 60 3.3 Reporting Format...........................................6 61 4. Test Cases..................................................7 62 4.1 Convergence Due to Link Failure............................7 63 4.1.1 Convergence Due to Local Interface Failure...............7 64 4.1.2 Convergence Due to Neighbor Interface Failure............7 65 4.1.3 Convergence Due to Remote Interface Failure..............8 66 4.2 Convergence Due to Layer 2 Session Failure.................9 67 4.3 Convergence Due to IGP Adjacency Failure...................10 68 4.4 Convergence Due to Route Withdrawal........................10 69 4.5 Convergence Due to Cost Change.............................11 70 4.6 Convergence Due to ECMP Member Interface Failure...........11 71 4.7 Convergence Due to Parallel Link Interface Failure.........12 72 5. IANA Considerations.........................................13 73 6. Security Considerations.....................................13 74 7. Acknowledgements............................................13 75 8. Normative References........................................13 76 9. Author's Address............................................14 78 1. Introduction 79 This document describes the methodology for benchmarking IGP Route 80 Convergence. The applicability of this testing is described in 81 [Po07a] and the new terminology that it introduces is defined in 82 [Po07t]. Service Providers use IGP Convergence time as a key metric 83 of 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 [Po07a]. The 88 black-box test designs benchmark the data plane and account for 89 all of the factors contributing to convergence time, as discussed 90 in [Po07a]. The methodology (and terminology) for benchmarking route 91 convergence can be applied to any link-state IGP such as ISIS [Ca90] 92 and OSPF [Mo98]. These methodologies apply to IPv4 and IPv6 traffic 93 as well as IPv4 and IPv6 IGPs. 95 2. Existing definitions 97 This document uses much of the terminology defined in [Po07t]. The 98 term "Throughput" is defined in RFC 2544 [Br99]. 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in BCP 14, RFC 2119 103 [Br97]. RFC 2119 defines the use of these key words to help make the 104 intent of standards track documents as clear as possible. While this 105 document uses these keywords, this document is not a standards track 106 document. 108 IGP Data Plane Route Convergence 110 3. Test Setup 111 3.1 Test Topologies 112 Figure 1 shows the test topology to measure IGP Route Convergence due 113 to local Convergence Events such as SONET Link Failure, Layer 2 114 Session Failure, IGP Adjacency Failure, Route Withdrawal, and route 115 cost change. These test cases discussed in section 4 provide route 116 convergence times that account for the Event Detection time, SPF 117 Processing time, and FIB Update time. These times are measured 118 by observing packet loss in the data plane at the Tester. 120 --------- Ingress Interface --------- 121 | |<--------------------------------| | 122 | | | | 123 | | Preferred Egress Interface | | 124 | DUT |-------------------------------->| Tester| 125 | | | | 126 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| | 127 | | Next-Best Egress Interface | | 128 --------- --------- 130 Figure 1. IGP Route Convergence Test Topology for Local Changes 132 Figure 2 shows the test topology to measure IGP Route Convergence 133 time due to remote changes in the network topology. These times are 134 measured by observing packet loss in the data plane at the Tester. 135 In this topology the three routers are considered a System Under 136 Test (SUT). NOTE: All routers in the SUT must be the same model and 137 identically configured. 139 ----- --------- 140 | | Preferred | | 141 ----- |R2 |---------------------->| | 142 | |-->| | Egress Interface | | 143 | | ----- | | 144 |R1 | |Tester | 145 | | ----- | | 146 | |-->| | Next-Best | | 147 ----- |R3 |~~~~~~~~~~~~~~~~~~~~~~>| | 148 ^ | | Egress Interface | | 149 | ----- --------- 150 | | 151 |-------------------------------------- 152 Ingress Interface 154 Figure 2. IGP Route Convergence Test Topology 155 for Remote Changes 157 Figure 3 shows the test topology to measure IGP Route Convergence 158 time with members of an Equal Cost Multipath (ECMP) Set. These 159 times are measured by observing packet loss in the data plane at 160 the Tester. In this topology, the DUT is configured with each 161 Egress interface 162 IGP Data Plane Route Convergence 164 as a member of an ECMP set and the Tester emulates multiple 165 next-hop routers (emulates one router for each member). 167 --------- Ingress Interface --------- 168 | |<--------------------------------| | 169 | | | | 170 | | ECMP Set Interface 1 | | 171 | DUT |-------------------------------->| Tester| 172 | | . | | 173 | | . | | 174 | | . | | 175 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| | 176 | | ECMP Set Interface N | | 177 --------- --------- 179 Figure 3. IGP Route Convergence Test Topology 180 for ECMP Convergence 182 Figure 4 shows the test topology to measure IGP Route Convergence 183 time with members of a Parallel Link. These times are measured by 184 observing packet loss in the data plane at the Tester. In this 185 topology, the DUT is configured with each Egress interface as a 186 member of a Parallel Link and the Tester emulates the single 187 next-hop router. 189 --------- Ingress Interface --------- 190 | |<--------------------------------| | 191 | | | | 192 | | Parallel Link Interface 1 | | 193 | DUT |-------------------------------->| Tester| 194 | | . | | 195 | | . | | 196 | | . | | 197 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| | 198 | | Parallel Link Interface N | | 199 --------- --------- 201 Figure 4. IGP Route Convergence Test Topology 202 for Parallel Link Convergence 204 3.2 Test Considerations 205 3.2.1 IGP Selection 206 The test cases described in section 4 can be used for ISIS or 207 OSPF. The Route Convergence test methodology for both is 208 identical. The IGP adjacencies are established on the Preferred 209 Egress Interface and Next-Best Egress Interface. 211 3.2.2 Routing Protocol Configuration 212 The obtained results for IGP Route Convergence may vary if 213 other routing protocols are enabled and routes learned via those 214 protocols are installed. IGP convergence times MUST be benchmarked 215 without routes installed from other protocols. 217 IGP Data Plane Route Convergence 219 3.2.3 IGP Route Scaling 220 The number of IGP routes will impact the measured IGP Route 221 Convergence. To obtain results similar to those that would be 222 observed in an operational network, it is recommended that the 223 number of installed routes closely approximates that the network. 224 The number of areas (for OSPF) and levels (for ISIS) can impact 225 the benchmark results. 227 3.2.4 Timers 228 There are some timers that will impact the measured IGP Convergence 229 time. Benchmarking metrics may be measured at any fixed values for 230 these timers. It is RECOMMENDED that the following timers be 231 configured to the minimum values listed: 233 Timer Recommended Value 234 ----- ----------------- 235 Link Failure Indication Delay <10milliseconds 236 IGP Hello Timer 1 second 237 IGP Dead-Interval 3 seconds 238 LSA Generation Delay 0 239 LSA Flood Packet Pacing 0 240 LSA Retransmission Packet Pacing 0 241 SPF Delay 0 243 3.2.5 Convergence Time Metrics 244 The recommended value for the Packet Sampling Interval [Po07t] is 245 100 milliseconds. Rate-Derived Convergence Time [Po07t] is the 246 preferred benchmark for IGP Route Convergence. This benchmark 247 must always be reported when the Packet Sampling Interval [Po07t] 248 <= 100 milliseconds. If the test equipment does not permit 249 the Packet Sampling Interval to be set as low as 100 msec, 250 then both the Rate-Derived Convergence Time and Loss-Derived 251 Convergence Time [Po07t] must be reported. The Packet Sampling 252 Interval value MUST be reported as the smallest measurable 253 convergence time. 255 3.2.6 Interface Types 256 All test cases in this methodology document may be executed with 257 any interface type. All interfaces MUST be the same media and 258 Throughput [Br91][Br99] for each test case. This is because each 259 interface type has a unique mechanism for detecting link failures 260 and the speed at which that mechanism operates will influence 261 the measure results. Media and protocols MUST be configured for 262 minimum failure detection delay to minimize the contribution to 263 the measured Convergence time. For example, configure SONET with 264 the minimum carrier-loss-delay. 266 IGP Data Plane Route Convergence 268 3.2.7 Offered Load 269 The offered Load MUST be the Throughput of the device as defined 270 in [Br91] and benchmarked in [Br99] at a fixed packet size. 271 Packet size is measured in bytes and includes the IP header and 272 payload. The packet size is selectable and MUST be recorded. 273 The Forwarding Rate [Ma98] MUST be measured at the Preferred Egress 274 Interface and the Next-Best Egress Interface. The duration of 275 offered load MUST be greater than the convergence time. The 276 destination addresses for the offered load MUST be distributed 277 such that all routes are matched. This enables Full Convergence 278 [Po07t] to be observed. 280 3.3 Reporting Format 281 For each test case, it is recommended that the following reporting 282 format is completed: 284 Parameter Units 285 --------- ----- 286 IGP (ISIS or OSPF) 287 Interface Type (GigE, POS, ATM, etc.) 288 Packet Size offered to DUT bytes 289 IGP Routes advertised to DUT number of IGP routes 290 Packet Sampling Interval on Tester seconds or milliseconds 291 IGP Timer Values configured on DUT 292 SONET Failure Indication Delay seconds or milliseconds 293 IGP Hello Timer seconds or milliseconds 294 IGP Dead-Interval seconds or milliseconds 295 LSA Generation Delay seconds or milliseconds 296 LSA Flood Packet Pacing seconds or milliseconds 297 LSA Retransmission Packet Pacing seconds or milliseconds 298 SPF Delay seconds or milliseconds 299 Benchmarks 300 Rate-Derived Convergence Time seconds or milliseconds 301 Loss-Derived Convergence Time seconds or milliseconds 302 Restoration Convergence Time seconds or milliseconds 303 IGP Data Plane Route Convergence 305 4. Test Cases 306 4.1 Convergence Due to Link Failure 307 4.1.1 Convergence Due to Local Interface Failure 308 Objective 309 To obtain the IGP Route Convergence due to a local link failure event 310 at the DUT's Local Interface. 312 Procedure 313 1. Advertise matching IGP routes from Tester to DUT on 314 Preferred Egress Interface [Po07t] and Next-Best Egress Interface 315 [Po07t] using the topology shown in Figure 1. Set the cost of 316 the routes so that the Preferred Egress Interface is the 317 preferred next-hop. 318 2. Send offered load at measured Throughput with fixed packet 319 size to destinations matching all IGP routes from Tester to 320 DUT on Ingress Interface [Po07t]. 321 3. Verify traffic routed over Preferred Egress Interface. 322 4. Remove Preferred Egress link on DUT's Local Interface [Po07t] by 323 performing an administrative shutdown of the interface. 324 5. Measure Rate-Derived Convergence Time [Po07t] as DUT detects the 325 link down event and converges all IGP routes and traffic over 326 the Next-Best Egress Interface. 327 6. Stop offered load. Wait 30 seconds for queues to drain. 328 Restart Offered Load. 329 7. Restore Preferred Egress link on DUT's Local Interface by 330 administratively enabling the interface. 331 8. Measure Restoration Convergence Time [Po07t] as DUT detects the 332 link up event and converges all IGP routes and traffic back 333 to the Preferred Egress Interface. 335 Results 336 The measured IGP Convergence time is influenced by the Local 337 link failure indication, SPF delay, SPF Hold time, SPF Execution 338 Time, Tree Build Time, and Hardware Update Time [Po07a]. 340 4.1.2 Convergence Due to Neighbor Interface Failure 341 Objective 342 To obtain the IGP Route Convergence due to a local link 343 failure event at the Tester's Neighbor Interface. 345 Procedure 346 1. Advertise matching IGP routes from Tester to DUT on 347 Preferred Egress Interface [Po07t] and Next-Best Egress Interface 348 [Po07t] using the topology shown in Figure 1. Set the cost of 349 the routes so that the Preferred Egress Interface is the 350 preferred next-hop. 351 2. Send offered load at measured Throughput with fixed packet 352 size to destinations matching all IGP routes from Tester to 353 DUT on Ingress Interface [Po07t]. 355 IGP Data Plane Route Convergence 357 3. Verify traffic routed over Preferred Egress Interface. 358 4. Remove link on Tester's Neighbor Interface [Po07t] connected to 359 DUT's Preferred Egress Interface. 360 5. Measure Rate-Derived Convergence Time [Po07t] as DUT detects the 361 link down event and converges all IGP routes and traffic over 362 the Next-Best Egress Interface. 363 6. Stop offered load. Wait 30 seconds for queues to drain. 364 Restart Offered Load. 365 7. Restore link on Tester's Neighbor Interface connected to 366 DUT's Preferred Egress Interface. 367 8. Measure Restoration Convergence Time [Po07t] as DUT detects the 368 link up event and converges all IGP routes and traffic back 369 to the Preferred Egress Interface. 371 Results 372 The measured IGP Convergence time is influenced by the Local 373 link failure indication, SPF delay, SPF Hold time, SPF Execution 374 Time, Tree Build Time, and Hardware Update Time [Po07a]. 376 4.1.3 Convergence Due to Remote Interface Failure 377 Objective 378 To obtain the IGP Route Convergence due to a Remote Interface 379 Failure event. 381 Procedure 382 1. Advertise matching IGP routes from Tester to SUT on 383 Preferred Egress Interface [Po07t] and Next-Best Egress Interface 384 [Po07t] using the topology shown in Figure 2. Set the cost of 385 the routes so that the Preferred Egress Interface is the 386 preferred next-hop. 387 2. Send offered load at measured Throughput with fixed packet 388 size to destinations matching all IGP routes from Tester to 389 DUT on Ingress Interface [Po07t]. 390 3. Verify traffic is routed over Preferred Egress Interface. 391 4. Remove link on Tester's Neighbor Interface [Po07t] connected to 392 SUT's Preferred Egress Interface. 393 5. Measure Rate-Derived Convergence Time [Po07t] as SUT detects 394 the link down event and converges all IGP routes and traffic 395 over the Next-Best Egress Interface. 396 6. Stop offered load. Wait 30 seconds for queues to drain. 397 Restart Offered Load. 398 7. Restore link on Tester's Neighbor Interface connected to 399 DUT's Preferred Egress Interface. 400 8. Measure Restoration Convergence Time [Po07t] as DUT detects the 401 link up event and converges all IGP routes and traffic back 402 to the Preferred Egress Interface. 404 IGP Data Plane Route Convergence 406 Results 407 The measured IGP Convergence time is influenced by the 408 link failure indication, LSA/LSP Flood Packet Pacing, 409 LSA/LSP Retransmission Packet Pacing, LSA/LSP Generation 410 time, SPF delay, SPF Hold time, SPF Execution Time, Tree 411 Build Time, and Hardware Update Time [Po07a]. The additional 412 convergence time contributed by LSP Propagation can be 413 obtained by subtracting the Rate-Derived Convergence Time 414 measured in 4.1.2 (Convergence Due to Neighbor Interface 415 Failure) from the Rate-Derived Convergence Time measured in 416 this test case. 418 4.2 Convergence Due to Layer 2 Session Failure 419 Objective 420 To obtain the IGP Route Convergence due to a Local Layer 2 421 Session failure event. 423 Procedure 424 1. Advertise matching IGP routes from Tester to DUT on 425 Preferred Egress Interface [Po07t] and Next-Best Egress Interface 426 [Po07t] using the topology shown in Figure 1. Set the cost of 427 the routes so that the IGP routes along the Preferred Egress 428 Interface is the preferred next-hop. 429 2. Send offered load at measured Throughput with fixed packet 430 size to destinations matching all IGP routes from Tester to 431 DUT on Ingress Interface [Po07t]. 432 3. Verify traffic routed over Preferred Egress Interface. 433 4. Remove Layer 2 session from Tester's Neighbor Interface [Po07t] 434 connected to Preferred Egress Interface. 435 5. Measure Rate-Derived Convergence Time [Po07t] as DUT detects the 436 Layer 2 session down event and converges all IGP routes and 437 traffic over the Next-Best Egress Interface. 438 6. Stop offered load. Wait 30 seconds for queues to drain. 439 Restart Offered Load. 440 7. Restore Layer 2 session on DUT's Preferred Egress Interface. 441 8. Measure Restoration Convergence Time [Po07t] as DUT detects the 442 session up event and converges all IGP routes and traffic 443 over the Preferred Egress Interface. 445 Results 446 The measured IGP Convergence time is influenced by the Layer 2 447 failure indication, SPF delay, SPF Hold time, SPF Execution 448 Time, Tree Build Time, and Hardware Update Time [Po07a]. 450 IGP Data Plane Route Convergence 452 4.3 Convergence Due to IGP Adjacency Failure 454 Objective 455 To obtain the IGP Route Convergence due to a Local IGP Adjacency 456 failure event. 458 Procedure 459 1. Advertise matching IGP routes from Tester to DUT on 460 Preferred Egress Interface [Po07t] and Next-Best Egress Interface 461 [Po07t] using the topology shown in Figure 1. Set the cost of 462 the routes so that the Preferred Egress Interface is the 463 preferred next-hop. 464 2. Send offered load at measured Throughput with fixed packet 465 size to destinations matching all IGP routes from Tester to 466 DUT on Ingress Interface [Po07t]. 467 3. Verify traffic routed over Preferred Egress Interface. 468 4. Remove IGP adjacency from Tester's Neighbor Interface [Po07t] 469 connected to Preferred Egress Interface. 470 5. Measure Rate-Derived Convergence Time [Po07t] as DUT detects the 471 IGP session failure event and converges all IGP routes and 472 traffic over the Next-Best Egress Interface. 473 6. Stop offered load. Wait 30 seconds for queues to drain. 474 Restart Offered Load. 475 7. Restore IGP session on DUT's Preferred Egress Interface. 476 8. Measure Restoration Convergence Time [Po07t] as DUT detects the 477 session up event and converges all IGP routes and traffic 478 over the Preferred Egress Interface. 480 Results 481 The measured IGP Convergence time is influenced by the IGP Hello 482 Interval, IGP Dead Interval, SPF delay, SPF Hold time, SPF 483 Execution Time, Tree Build Time, and Hardware Update Time [Po07a]. 485 4.4 Convergence Due to Route Withdrawal 487 Objective 488 To obtain the IGP Route Convergence due to Route Withdrawal. 490 Procedure 491 1. Advertise matching IGP routes from Tester to DUT on 492 Preferred Egress Interface [Po07t] and Next-Best Egress Interface 493 [Po07t] using the topology shown in Figure 1. Set the cost of 494 the routes so that the Preferred Egress Interface is the 495 preferred next-hop. 496 2. Send offered load at measured Throughput with fixed packet 497 size to destinations matching all IGP routes from Tester to 498 DUT on Ingress Interface [Po07t]. 499 3. Verify traffic routed over Preferred Egress Interface. 500 4. Tester withdraws all IGP routes from DUT's Local Interface 501 on Preferred Egress Interface. 503 IGP Data Plane Route Convergence 505 5. Measure Rate-Derived Convergence Time [Po07t] as DUT withdraws 506 routes and converges all IGP routes and traffic over the 507 Next-Best Egress Interface. 508 6. Stop offered load. Wait 30 seconds for queues to drain. 509 Restart Offered Load. 510 7. Re-advertise IGP routes to DUT's Preferred Egress Interface. 511 8. Measure Restoration Convergence Time [Po07t] as DUT converges all 512 IGP routes and traffic over the Preferred Egress Interface. 514 Results 515 The measured IGP Convergence time is the SPF Processing and FIB 516 Update time as influenced by the SPF delay, SPF Hold time, SPF 517 Execution Time, Tree Build Time, and Hardware Update Time [Po07a]. 519 4.5 Convergence Due to Cost Change 520 Objective 521 To obtain the IGP Route Convergence due to route cost change. 523 Procedure 524 1. Advertise matching IGP routes from Tester to DUT on 525 Preferred Egress Interface [Po07t] and Next-Best Egress Interface 526 [Po07t] using the topology shown in Figure 1. Set the cost of 527 the routes so that the Preferred Egress Interface is the 528 preferred next-hop. 529 2. Send offered load at measured Throughput with fixed packet 530 size to destinations matching all IGP routes from Tester to 531 DUT on Ingress Interface [Po07t]. 532 3. Verify traffic routed over Preferred Egress Interface. 533 4. Tester increases cost for all IGP routes at DUT's Preferred 534 Egress Interface so that the Next-Best Egress Interface 535 has lower cost and becomes preferred path. 536 5. Measure Rate-Derived Convergence Time [Po07t] as DUT detects the 537 cost change event and converges all IGP routes and traffic 538 over the Next-Best Egress Interface. 539 6. Stop offered load. Wait 30 seconds for queues to drain. 540 Restart Offered Load. 541 7. Re-advertise IGP routes to DUT's Preferred Egress Interface 542 with original lower cost metric. 543 8. Measure Restoration Convergence Time [Po07t] as DUT converges all 544 IGP routes and traffic over the Preferred Egress Interface. 546 Results 547 There should be no externally observable IGP Route Convergence 548 and no measured packet loss for this case. 550 4.6 Convergence Due to ECMP Member Interface Failure 551 Objective 552 To obtain the IGP Route Convergence due to a local link failure event 553 of an ECMP Member. 555 IGP Data Plane Route Convergence 557 Procedure 558 1. Configure ECMP Set as shown in Figure 3. 559 2. Advertise matching IGP routes from Tester to DUT on 560 each ECMP member. 561 3. Send offered load at measured Throughput with fixed packet 562 size to destinations matching all IGP routes from Tester to 563 DUT on Ingress Interface [Po07t]. 564 4. Verify traffic routed over all members of ECMP Set. 565 5. Remove link on Tester's Neighbor Interface [Po07t] connected to 566 one of the DUT's ECMP member interfaces. 567 6. Measure Rate-Derived Convergence Time [Po07t] as DUT detects the 568 link down event and converges all IGP routes and traffic 569 over the other ECMP members. 570 7. Stop offered load. Wait 30 seconds for queues to drain. 571 Restart Offered Load. 572 8. Restore link on Tester's Neighbor Interface connected to 573 DUT's ECMP member interface. 574 9. Measure Restoration Convergence Time [Po07t] as DUT detects the 575 link up event and converges IGP routes and some distribution 576 of traffic over the restored ECMP member. 578 Results 579 The measured IGP Convergence time is influenced by Local link 580 failure indication, Tree Build Time, and Hardware Update Time 581 [Po07a]. 583 4.7 Convergence Due to Parallel Link Interface Failure 584 Objective 585 To obtain the IGP Route Convergence due to a local link failure 586 event for a Member of a Parallel Link. The links can be used 587 for data Load Balancing 589 Procedure 590 1. Configure Parallel Link as shown in Figure 4. 591 2. Advertise matching IGP routes from Tester to DUT on 592 each Parallel Link member. 593 3. Send offered load at measured Throughput with fixed packet 594 size to destinations matching all IGP routes from Tester to 595 DUT on Ingress Interface [Po07t]. 596 4. Verify traffic routed over all members of Parallel Link. 597 5. Remove link on Tester's Neighbor Interface [Po07t] connected to 598 one of the DUT's Parallel Link member interfaces. 599 6. Measure Rate-Derived Convergence Time [Po07t] as DUT detects the 600 link down event and converges all IGP routes and traffic over 601 the other Parallel Link members. 602 7. Stop offered load. Wait 30 seconds for queues to drain. 603 Restart Offered Load. 604 8. Restore link on Tester's Neighbor Interface connected to 605 DUT's Parallel Link member interface. 607 IGP Data Plane Route Convergence 609 9. Measure Restoration Convergence Time [Po07t] as DUT detects the 610 link up event and converges IGP routes and some distribution 611 of traffic over the restored Parallel Link member. 613 Results 614 The measured IGP Convergence time is influenced by the Local 615 link failure indication, Tree Build Time, and Hardware Update 616 Time [Po07a]. 618 5. IANA Considerations 620 This document requires no IANA considerations. 622 6. Security Considerations 623 Documents of this type do not directly affect the security of 624 the Internet or corporate networks as long as benchmarking 625 is not performed on devices or systems connected to operating 626 networks. 628 7. Acknowledgements 629 Thanks to Sue Hares, Al Morton, Kevin Dubray, and participants of 630 the BMWG for their contributions to this work. 632 8. References 633 8.1 Normative References 635 [Br91] Bradner, S., "Benchmarking Terminology for Network 636 Interconnection Devices", RFC 1242, IETF, March 1991. 638 [Br97] Bradner, S., "Key words for use in RFCs to Indicate 639 Requirement Levels", RFC 2119, March 1997 641 [Br99] Bradner, S. and McQuaid, J., "Benchmarking Methodology for 642 Network Interconnect Devices", RFC 2544, IETF, March 1999. 644 [Ca90] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual 645 Environments", RFC 1195, IETF, December 1990. 647 [Ma98] Mandeville, R., "Benchmarking Terminology for LAN 648 Switching Devices", RFC 2285, February 1998. 650 [Mo98] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 652 [Po07a] Poretsky, S., "Considerations for Benchmarking IGP 653 Convergence", draft-ietf-bmwg-igp-dataplane-conv-app-13, 654 work in progress, July 2007. 656 [Po07t] Poretsky, S., Imhoff, B., "Benchmarking Terminology for IGP 657 Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-13, 658 work in progress, July 2007. 660 8.2 Informative References 661 None 662 IGP Data Plane Route Convergence 664 9. Author's Address 666 Scott Poretsky 667 Reef Point Systems 668 8 New England Executive Park 669 Burlington, MA 01803 670 USA 671 Phone: + 1 508 439 9008 672 EMail: sporetsky@reefpoint.com 674 Brent Imhoff 675 Juniper Networks 676 1194 North Mathilda Ave 677 Sunnyvale, CA 94089 678 USA 679 Phone: + 1 314 378 2571 680 EMail: bimhoff@planetspork.com 682 Full Copyright Statement 684 Copyright (C) The IETF Trust (2007). 686 This document is subject to the rights, licenses and restrictions 687 contained in BCP 78, and except as set forth therein, the authors 688 retain all their rights. 690 This document and the information contained herein are provided 691 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 692 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 693 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 694 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 695 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 696 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 697 FOR A PARTICULAR PURPOSE. 699 Intellectual Property 701 The IETF takes no position regarding the validity or scope of any 702 Intellectual Property Rights or other rights that might be claimed to 703 pertain to the implementation or use of the technology described in 704 this document or the extent to which any license under such rights 705 might or might not be available; nor does it represent that it has 706 made any independent effort to identify any such rights. Information 707 on the procedures with respect to rights in RFC documents can be 708 found in BCP 78 and BCP 79. 710 Copies of IPR disclosures made to the IETF Secretariat and any 711 assurances of licenses to be made available, or the result of an 712 attempt made to obtain a general license or permission for the use of 713 such proprietary rights by implementers or users of this 714 specification can be obtained from the IETF on-line IPR repository at 715 http://www.ietf.org/ipr. 717 IGP Data Plane Route Convergence 719 The IETF invites any interested party to bring to its attention any 720 copyrights, patents or patent applications, or other proprietary 721 rights that may cover technology that may be required to implement 722 this standard. Please address the information to the IETF at ietf- 723 ipr@ietf.org. 725 Acknowledgement 726 Funding for the RFC Editor function is currently provided by the 727 Internet Society.