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