idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-meth-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 == 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 3 instances of too long lines in the document, the longest one being 11 characters in excess of 72. ** There are 335 instances of lines with control characters in the document. ** 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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (July 2004) is 7218 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 588 looks like a reference -- Missing reference section? '2' on line 592 looks like a reference -- Missing reference section? '3' on line 596 looks like a reference -- Missing reference section? '4' on line 599 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 6 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: July 2004 4 Scott Poretsky 5 Quarry Technologies 7 Brent Imhoff 8 Wiltel Communications 10 January 2004 12 Benchmarking Methodology for 13 IGP Data Plane Route Convergence 15 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other 29 documents at any time. It is inappropriate to use Internet-Drafts 30 as reference material or to cite them other than as "work in 31 progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 ABSTRACT 40 This draft describes the methodology for benchmarking IGP Route 41 Convergence as described in Applicability document [1] and 42 Terminology document [2]. The methodology and terminology are 43 to be used for benchmarking route convergence and can be applied 44 to any link-state IGP such as ISIS [3] and OSPF [4]. The terms 45 used in the procedures provided within this document are 46 defined in [2]. 48 Table of Contents 49 1. Introduction ...............................................2 50 2. Existing definitions .......................................2 51 3. Test Setup..................................................3 52 3.1 Test Topologies............................................3 53 3.2 Test Considerations........................................4 54 3.2.1 IGP Selection............................................4 55 IGP Data Plane Route Convergence 57 3.2.2 BGP Configuration........................................4 58 3.2.3 IGP Route Scaling........................................5 59 3.2.4 Timers...................................................5 60 3.2.5 Convergence Time Metrics.................................5 61 3.2.6 Offered Load.............................................5 62 3.2.7 Interface Types..........................................5 63 3.3 Reporting Format...........................................6 64 4. Test Cases..................................................6 65 4.1 Convergence Due to Link Failure............................6 66 4.1.1 Convergence Due to Local Interface Failure...............6 67 4.1.2 Convergence Due to Neighbor Interface Failure............7 68 4.1.3 Convergence Due to Remote Interface Failure..............7 69 4.2 Convergence Due to PPP Session Failure.....................8 70 4.3 Convergence Due to IGP Adjacency Failure...................9 71 4.4 Convergence Due to Route Withdrawal........................9 72 4.5 Convergence Due to Cost Change.............................10 73 4.6 Convergence Due to ECMP Member Interface Failure...........10 74 4.7 Convergence Due to Parallel Link Interface Failure.........11 75 5. Security Considerations.....................................12 76 6. References..................................................12 77 7. Author's Address............................................12 78 8. Full Copyright Statement....................................13 80 1. Introduction 81 This draft describes the methodology for benchmarking IGP Route 82 Convergence. The applicability of this testing is described in 83 [1] and the new terminology that it introduces is defined in [2]. 84 Service Providers use IGP Convergence time as a key metric of 85 router design and architecture. Customers of Service Providers 86 observe convergence time by packet loss, so IGP Route Convergence 87 is considered a Direct Measure of Quality (DMOQ). The test cases 88 in this document are black-box tests that emulate the network 89 events that cause route convergence, as described in [1]. The 90 black-box test designs benchmark the data plane accounting for 91 all of the factors contributing to convergence time, as discussed 92 in [1]. The methodology (and terminology) for benchmarking route 93 convergence can be applied to any link-state IGP such as ISIS [3] 94 and OSPF [4]. 96 2. Existing definitions 98 For the sake of clarity and continuity this RFC adopts the template 99 for definitions set out in Section 2 of RFC 1242. Definitions are 100 indexed and grouped together in sections for ease of reference. 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 104 this document are to be interpreted as described in RFC 2119. 106 IGP Data Plane Route Convergence 108 3. Test Setup 109 3.1 Test Topologies 111 Figure 1 shows the test topology to measure IGP Route Convergence due 112 to local Convergence Events such as SONET Link Failure, PPP Session 113 Failure, IGP Adjacency Failure, Route Withdrawal, and route cost 114 change. These test cases discussed in section 4 provide route 115 convergence times that account for the Event Detection time, SPF 116 Processing time, and FIB Update time. These times are measured 117 by observing packet loss in the data plane. 119 --------- Ingress Interface --------- 120 | |<------------------------------| | 121 | | | | 122 | | Preferred Egress Interface | | 123 | DUT |------------------------------>|Tester | 124 | | | | 125 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| | 126 | | Next-Best Egress Interface | | 127 --------- --------- 129 Figure 1. IGP Route Convergence Test Topology for Local Changes 131 Figure 2 shows the test topology to measure IGP Route Convergence 132 time due to remote changes in the network topology. These times are 133 measured by observing packet loss in the data plane. In this 134 topology the three routers are considered a System Under Test (SUT). 135 NOTE: All routers in the SUT must be the same model and identically configured. 137 ----- ----------- 138 | | Preferred | | 139 ----- |R2 |---------------------->| | 140 | |-->| | Egress Interface | | 141 | | ----- | | 142 |R1 | | Tester | 143 | | ----- | | 144 | |-->| | Next-Best | | 145 ----- |R3 |~~~~~~~~~~~~~~~~~~~~~~>| | 146 ^ | | Egress Interface | | 147 | ----- ----------- 148 | | 149 |-------------------------------------- 150 Ingress Interface 152 Figure 2. IGP Route Convergence Test Topology 153 for Remote Changes 155 Figure 3 shows the test topology to measure IGP Route Convergence 156 time with members of an ECMP Set. These times are measured by 157 observing packet loss in the data plane. In this topology, the DUT 158 IGP Data Plane Route Convergence 160 is configured with each Egress interface as a member of an ECMP set 161 and the Tester emulates multiple next-hop routers (emulates one 162 router for each member). 164 --------- Ingress Interface --------- 165 | |<--------------------------------| | 166 | | | | 167 | | ECMP Set Interface 1 | | 168 | DUT |-------------------------------->| Tester| 169 | | . | | 170 | | . | | 171 | | . | | 172 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| | 173 | | ECMP Set Interface N | | 174 --------- --------- 176 Figure 3. IGP Route Convergence Test Topology 177 for ECMP Convergence 179 Figure 4 shows the test topology to measure IGP Route Convergence 180 time with members of a Parallel Link. These times are measured by 181 observing packet loss in the data plane. In this topology, the DUT 182 is configured with each Egress interface as a member of a Parallel 183 Link and the Tester emulates the single next-hop router. 185 --------- Ingress Interface --------- 186 | |<--------------------------------| | 187 | | | | 188 | | Parallel Link Interface 1 | | 189 | DUT |-------------------------------->| Tester| 190 | | . | | 191 | | . | | 192 | | . | | 193 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| | 194 | | Parallel Link Interface N | | 195 --------- --------- 197 Figure 4. IGP Route Convergence Test Topology 198 for Parallel Link Convergence 200 3.2 Test Considerations 201 3.2.1 IGP Selection 202 The test cases described in section 4 can be used for ISIS or 203 OSPF. The Route Convergence test methodology for both is 204 identical. The IGP adjacencies are established on the Preferred 205 Egress Interface and Next-Best Egress Interface. 207 3.2.2 BGP Configuration 208 The obtained results for IGP Route Convergence may vary if 209 BGP routes are installed. It is recommended that the IGP 210 Convergence times be benchmarked without BGP routes installed. 212 IGP Data Plane Route Convergence 214 3.2.3 IGP Route Scaling 215 The number of IGP routes will impact the measured IGP Route 216 Convergence because convergence for the entire IGP route table is 217 measured. For results similar to those that would be observed in 218 an operational network it is recommended that the number of 219 installed routes closely approximate that for routers in the 220 network. 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 SONET 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 242 Packet Sampling Interval [2] <= 100 milliseconds. 243 If the test equipment does not permit the Packet Sampling 244 Interval to be set as low as 100 msec, then both the 245 Rate-Derived Convergence Time and Loss-Derived Convergence 246 Time [2] must be reported. 248 3.2.6 Offered Load 249 An offered Load of maximum forwarding rate at a fixed packet size 250 is recommended for accurate measurement. The duration of offered 251 load must be greater than the convergence time. 253 3.2.7 Interface Types 254 All test cases in this methodology document may be executed with 255 any interface type. SONET is recommended and specifically 256 mentioned in the procedures because it can be configured to have 257 no or negligible affect on the measured convergence time. 258 Ethernet (10Mb, 100Mb, 1Gb, and 10Gb) is not preferred since 259 broadcast media are unable to detect loss of host and rely upon 260 IGP Hellos to detect session loss. 262 IGP Data Plane Route Convergence 264 3.3 Reporting Format 265 For each test case, it is recommended that the following reporting 266 format be completed: 268 Parameter Units 269 --------- ----- 270 IGP (ISIS or OSPF) 271 Interface Type (GigE, POS, ATM, etc.) 272 Packet Size bytes 273 IGP Routes number of IGP routes 274 Packet Sampling Interval seconds or milliseconds 275 IGP Timer Values 276 SONET Failure Indication Delay seconds or milliseconds 277 IGP Hello Timer seconds or milliseconds 278 IGP Dead-Interval seconds or milliseconds 279 LSA Generation Delay seconds or milliseconds 280 LSA Flood Packet Pacing seconds or milliseconds 281 LSA Retransmission Packet Pacing seconds or milliseconds 282 SPF Delay seconds or milliseconds 283 Benchmarks 284 Rate-Derived Convergence Time seconds or milliseconds 285 Loss-Derived Convergence Time seconds or milliseconds 286 Restoration Convergence Time seconds or milliseconds 288 4. Test Cases 289 4.1 Convergence Due to Link Failure 290 4.1.1 Convergence Due to Local Interface Failure 291 Objective 292 To obtain the IGP Route Convergence due to a local link 293 failure event at the DUT's Local Interface. 295 Procedure 296 1. Advertise matching IGP routes from Tester to DUT on 297 Preferred Egress Interface [2] and Next-Best Egress Interface 298 [2] using the topology shown in Figure 1. Set the cost of the 299 routes so that the Preferred Egress Interface is the preferred 300 next-hop. 301 2. Send traffic at maximum forwarding rate to destinations 302 matching all IGP routes from Tester to DUT on Ingress Interface 303 [2]. 304 3. Verify traffic routed over Preferred Egress Interface. 305 4. Remove SONET on DUT's Local Interface [2] by performing an 306 administrative shutdown of the interface. 307 5. Measure Rate-Derived Convergence Time [2] as DUT detects the 308 link down event and converges all IGP routes and traffic over 309 the Next-Best Egress Interface. 310 6. Restore SONET on DUT's Local Interface by administratively 311 enabling the interface. 312 7. Measure Restoration Convergence Time [2] as DUT detects the link 313 up event and converges all IGP routes and traffic back to the 314 Preferred Egress Interface. 316 IGP Data Plane Route Convergence 317 Results 318 The measured IGP Convergence time is influenced by the Local 319 SONET indication, SPF delay, SPF Holdtime, SPF Execution 320 Time, Tree Build Time, and Hardware Update Time. 322 4.1.2 Convergence Due to Neighbor Interface Failure 323 Objective 324 To obtain the IGP Route Convergence due to a local link 325 failure event at the Tester's Neighbor Interface. 327 Procedure 328 1. Advertise matching IGP routes from Tester to DUT on 329 Preferred Egress Interface [2] and Next-Best Egress Interface 330 [2] using the topology shown in Figure 1. Set the cost of 331 the routes so that the Preferred Egress Interface is the 332 preferred next-hop. 333 2. Send traffic at maximum forwarding rate to destinations 334 matching all IGP routes from Tester to DUT on Ingress 335 Interface [2]. 336 3. Verify traffic routed over Preferred Egress Interface. 337 4. Remove SONET on Tester's Neighbor Interface [2] connected to 338 DUT' s Preferred Egress Interface. 339 5. Measure Rate-Derived Convergence Time [2] as DUT detects the 340 link down event and converges all IGP routes and traffic over 341 the Next-Best Egress Interface. 342 6. Restore SONET on Tester's Neighbor Interface connected to 343 DUT's Preferred Egress Interface. 344 7. Measure Restoration Convergence Time [2] as DUT detects the 345 link up event and converges all IGP routes and traffic back to 346 the Preferred Egress Interface. 348 Results 349 The measured IGP Convergence time is influenced by the Local 350 SONET indication, SPF delay, SPF Holdtime, SPF Execution 351 Time, Tree Build Time, and Hardware Update Time. 353 4.1.3 Convergence Due to Remote Interface Failure 354 Objective 355 To obtain the IGP Route Convergence due to a Remote 356 Interface failure event. 358 Procedure 359 1. Advertise matching IGP routes from Tester to SUT on 360 Preferred Egress Interface [2] and Next-Best Egress Interface 361 [2] using the topology shown in Figure 2. Set the cost of the 362 routes so that the Preferred Egress Interface is the preferred 363 next-hop. 364 2. Send traffic at maximum forwarding rate to destinations 365 matching all IGP routes from Tester to DUT on Ingress Interface 366 [2]. 367 3. Verify traffic is routed over Preferred Egress Interface. 368 4. Remove SONET on Tester's Neighbor Interface [2] connected to 369 SUT' s Preferred Egress Interface. 371 IGP Data Plane Route Convergence 373 5. Measure Rate-Derived Convergence Time [2] as SUT detects 374 the link down event and converges all IGP routes and traffic 375 over the Next-Best Egress Interface. 376 6. Restore SONET on Tester's Neighbor Interface connected to 377 SUT's Preferred Egress Interface. 378 7. Measure Restoration Convergence Time [2] as SUT detects the 379 link up event and converges all IGP routes and traffic over 380 the Preferred Egress Interface. 382 Results 383 The measured IGP Convergence time is influenced by the 384 SONET failure indication, LSA/LSP Flood Packet Pacing, 385 LSA/LSP Retransmission Packet Pacing, LSA/LSP Generation 386 time, SPF delay, SPF Holdtime, SPF Execution Time, Tree 387 Build Time, and Hardware Update Time. The additional 388 convergence time contributed by LSP Propagation can be 389 obtained by subtracting the Rate-Derived Convergence Time 390 measured in 4.1.2 (Convergence Due to Neighbor Interface 391 Failure) from the Rate-Derived Convergence Time measured in 392 this test case. 394 4.2 Convergence Due to PPP Session Failure 395 Objective 396 To obtain the IGP Route Convergence due to a Local PPP Session 397 failure event. 399 Procedure 400 1. Advertise matching IGP routes from Tester to DUT on 401 Preferred Egress Interface [2] and Next-Best Egress Interface 402 [2] using the topology shown in Figure 1. Set the cost of 403 the routes so that the IGP routes along the Preferred Egress 404 Interface is the preferred next-hop. 405 2. Send traffic at maximum forwarding rate to destinations 406 matching all IGP routes from Tester to DUT on Ingress 407 Interface [2]. 408 3. Verify traffic routed over Preferred Egress Interface. 409 4. Remove PPP session from Tester's Neighbor Interface [2] 410 connected to Preferred Egress Interface. 411 5. Measure Rate-Derived Convergence Time [2] as DUT detects the 412 PPP session down event and converges all IGP routes and 413 traffic over the Next-Best Egress Interface. 414 6. Restore PPP session on DUT's Preferred Egress Interface. 415 7. Measure Restoration Convergence Time [2] as DUT detects the 416 session up event and converges all IGP routes and traffic over 417 the Preferred Egress Interface. 419 Results 420 The measured IGP Convergence time is influenced by the PPP 421 failure indication, SPF delay, SPF Holdtime, SPF Execution 422 Time, Tree Build Time, and Hardware Update Time. 424 IGP Data Plane Route Convergence 426 4.3 Convergence Due to IGP Adjacency Failure 428 Objective 429 To obtain the IGP Route Convergence due to a Local IGP Adjacency 430 failure event. 432 Procedure 433 1. Advertise matching IGP routes from Tester to DUT on 434 Preferred Egress Interface [2] and Next-Best Egress Interface 435 [2] using the topology shown in Figure 1. Set the cost of 436 the routes so that the Preferred Egress Interface is the 437 preferred next-hop. 438 2. Send traffic at maximum forwarding rate to destinations 439 matching all IGP routes from Tester to DUT on Ingress 440 Interface [2]. 441 3. Verify traffic routed over Preferred Egress Interface. 442 4. Remove IGP adjacency from Tester's Neighbor Interface [2] 443 connected to Preferred Egress Interface. 444 5. Measure Rate-Derived Convergence Time [2] as DUT detects the 445 IGP session failure event and converges all IGP routes and 446 traffic over the Next-Best Egress Interface. 447 6. Restore IGP session on DUT's Preferred Egress Interface. 448 7. Measure Restoration Convergence Time [2] as DUT detects the 449 session up event and converges all IGP routes and traffic over 450 the Preferred Egress Interface. 452 Results 453 The measured IGP Convergence time is influenced by the IGP 454 Hello Interval, IGP Dead Interval, SPF delay, SPF Holdtime, 455 SPF Execution Time, Tree Build Time, and Hardware Update 456 Time. 458 4.4 Convergence Due to Route Withdrawal 460 Objective 461 To obtain the IGP Route Convergence due to Route Withdrawal. 463 Procedure 464 1. Advertise matching IGP routes from Tester to DUT on 465 Preferred Egress Interface [2] and Next-Best Egress Interface 466 [2] using the topology shown in Figure 1. Set the cost of 467 the routes so that the Preferred Egress Interface is the 468 preferred next-hop. 469 2. Send traffic at maximum forwarding rate to destinations 470 matching all IGP routes from Tester to DUT on Ingress 471 Interface [2]. 472 3. Verify traffic routed over Preferred Egress Interface. 473 4. Tester withdraws all IGP routes from DUT's Local Interface 474 on Preferred Egress Interface. 476 IGP Data Plane Route Convergence 478 6. Re-advertise IGP routes to DUT's Preferred Egress Interface. 479 7. Measure Restoration Convergence Time [2] as DUT converges all 480 IGP routes and traffic over the Preferred Egress Interface. 482 Results 483 The measured IGP Convergence time is the SPF Processing and FIB 484 Update time as influenced by the SPF delay, SPF Holdtime, 485 SPF Execution Time, Tree Build Time, and Hardware Update Time. 487 4.5 Convergence Due to Cost Change 489 Objective 490 To obtain the IGP Route Convergence due to route cost change. 492 Procedure 493 1. Advertise matching IGP routes from Tester to DUT on 494 Preferred Egress Interface [2] and Next-Best Egress Interface 495 [2] using the topology shown in Figure 1. Set the cost of 496 the routes so that the Preferred Egress Interface is the 497 preferred next-hop. 498 2. Send traffic at maximum forwarding rate to destinations 499 matching all IGP routes from Tester to DUT on Ingress 500 Interface [2]. 501 3. Verify traffic routed over Preferred Egress Interface. 502 4. Tester increases cost for all IGP routes at DUT's Preferred 503 Egress Interface so that the Next-Best Egress Interface 504 has lower cost and becomes preferred path. 505 5. Measure Rate-Derived Convergence Time [2] as DUT detects the 506 cost change event and converges all IGP routes and traffic 507 over the Next-Best Egress Interface. 508 6. Re-advertise IGP routes to DUT's Preferred Egress Interface 509 with original lower cost metric. 510 7. Measure Restoration Convergence Time [2] as DUT converges all 511 IGP routes and traffic over the Preferred Egress Interface. 513 Results 514 There should be no measured packet loss for this case. 516 4.6 Convergence Due to ECMP Member Interface Failure 518 Objective 519 To obtain the IGP Route Convergence due to a local link 520 failure event of an ECMP Member. 522 Procedure 523 1. Configure ECMP Set as shown in Figure 3. 524 2. Advertise matching IGP routes from Tester to DUT on 525 each ECMP member. 527 IGP Data Plane Route Convergence 529 3. Send traffic at maximum forwarding rate to destinations 530 matching all IGP routes from Tester to DUT on Ingress 531 Interface [2]. 532 4. Verify traffic routed over all members of ECMP Set. 533 5. Remove SONET on Tester's Neighbor Interface [2] connected to 534 one of the DUT's ECMP member interfaces. 535 6. Measure Rate-Derived Convergence Time [2] as DUT detects the 536 link down event and converges all IGP routes and traffic 537 over the other ECMP members. 538 7. Restore SONET on Tester's Neighbor Interface connected to 539 DUT's ECMP member interface. 540 8. Measure Restoration Convergence Time [2] as DUT detects the 541 link up event and converges IGP routes and some distribution 542 of traffic over the restored ECMP member. 544 Results 545 The measured IGP Convergence time is influenced by the Local 546 SONET indication, Tree Build Time, and Hardware Update Time. 548 4.7 Convergence Due to Parallel Link Interface Failure 550 Objective 551 To obtain the IGP Route Convergence due to a local link 552 failure event for a Member of a Parallel Link. 554 Procedure 555 1. Configure Parallel Link as shown in Figure 4. 556 2. Advertise matching IGP routes from Tester to DUT on 557 each Parallel Link member. 558 3. Send traffic at maximum forwarding rate to destinations 559 matching all IGP routes from Tester to DUT on Ingress 560 Interface [2]. 561 4. Verify traffic routed over all members of Parallel Link. 562 5. Remove SONET on Tester's Neighbor Interface [2] connected to 563 one of the DUT's Parallel Link member interfaces. 564 6. Measure Rate-Derived Convergence Time [2] as DUT detects the 565 link down event and converges all IGP routes and traffic over 566 the other Parallel Link members. 567 7. Restore SONET on Tester's Neighbor Interface connected to 568 DUT's Parallel Link member interface. 569 8. Measure Restoration Convergence Time [2] as DUT detects the 570 link up event and converges IGP routes and some distribution 571 of traffic over the restored Parallel Link member. 573 Results 574 The measured IGP Convergence time is influenced by the Local 575 SONET indication, Tree Build Time, and Hardware Update Time. 577 IGP Data Plane Route Convergence 579 5. Security Considerations 581 Documents of this type do not directly affect the security of 582 the Internet or corporate networks as long as benchmarking 583 is not performed on devices or systems connected to operating 584 networks. 586 6. References 588 [1] Poretsky, S., "Benchmarking Applicability for IGP 589 Convergence", draft-ietf-bmwg-igp-dataplane-conv-app-02, work 590 in progress, January 2004. 592 [2] Poretsky, S., Imhoff, B., "Benchmarking Terminology for IGP 593 Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-02, work 594 in progress, January 2004 596 [3] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual 597 Environments", RFC 1195, December 1990. 599 [4] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 601 7. Author's Address 603 Scott Poretsky 604 Quarry Technologies 605 8 New England Executive Park 606 Burlington, MA 01803 607 USA 609 Phone: + 1 781 395 5090 610 EMail: sporetsky@quarrytech.com 612 Brent Imhoff 613 WilTel Communications 614 3180 Rider Trail South 615 Bridgeton, MO 63045 616 USA 618 Phone: +1 314 595 6853 619 EMail: brent.imhoff@wcg.com 620 IGP Data Plane Route Convergence 622 8. Full Copyright Statement 623 Copyright (C) The Internet Society (1998). All Rights 624 Reserved. 626 This document and translations of it may be copied and 627 furnished to others, and derivative works that comment on or 628 otherwise explain it or assist in its implementation may be 629 prepared, copied, published and distributed, in whole or in 630 part, without restriction of any kind, provided that the above 631 copyright notice and this paragraph are included on all such 632 copies and derivative works. However, this document itself may 633 not be modified in any way, such as by removing the copyright 634 notice or references to the Internet Society or other Internet 635 organizations, except as needed for the purpose of developing 636 Internet standards in which case the procedures for copyrights 637 defined in the Internet Standards process must be followed, or 638 as required to translate it into languages other than English. 640 The limited permissions granted above are perpetual and will 641 not be revoked by the Internet Society or its successors or 642 assigns. This document and the information contained herein is 643 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 644 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 645 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 646 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 647 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 648 FOR A PARTICULAR PURPOSE.