idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-meth-01.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 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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 is 1 instance of too long lines in the document, the longest one being 68 characters in excess of 72. ** There are 352 instances of lines with control characters in the document. 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 (April 2004) is 7309 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 630 looks like a reference -- Missing reference section? '2' on line 634 looks like a reference -- Missing reference section? '3' on line 637 looks like a reference -- Missing reference section? '4' on line 640 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: April 2004 4 Scott Poretsky 5 Quarry Technologies 7 Brent Imhoff 8 Wiltel Communications 10 October 2003 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 Table of Contents 40 1. Introduction ...............................................2 41 2. Existing definitions .......................................2 42 3. Test Setup..................................................2 43 3.1 Test Topologies............................................2 44 3.2 Test Considerations........................................4 45 3.2.1 IGP Selection............................................4 46 3.2.2 BGP Configuration........................................4 47 3.2.3 IGP Route Scaling........................................5 48 3.2.4 Timers...................................................5 49 3.2.5 Convergence Time Metrics.................................5 50 3.2.6 Packet Sampling Interval.................................6 51 3.2.7 Interface Type...........................................6 52 3.3 Reporting Format...........................................6 53 IGP Data Plane Route Convergence 55 4. Test Cases..................................................7 56 4.1 Convergence Due to Link Failure............................7 57 4.1.1 Convergence Due to Local Interface Failure...............7 58 4.1.2 Convergence Due to Neighbor Interface Failure............8 59 4.1.3 Convergence Due to Remote Interface Failure..............8 60 4.2 Convergence Due to PPP Session Failure.....................9 61 4.3 Convergence Due to IGP Adjacency Failure...................10 62 4.4 Convergence Due to Route Withdrawal........................10 63 4.5 Convergence Due to Cost Change.............................11 64 4.6 Convergence Due to ECMP Member Interface Failure...........11 65 4.7 Convergence Due to Parallel Link Interface Failure.........12 66 5. Security Considerations.....................................13 67 6. References..................................................13 68 7. Author's Address............................................13 69 8. Full Copyright Statement....................................13 71 1. Introduction 72 This draft describes the methodology for benchmarking IGP Route 73 Convergence. The applicability of this testing is described in 74 [1] and the new terminology that it introduces is defined in [2]. 75 Service Providers use IGP Convergence time as a key metric of 76 router design and architecture. Customers of Service Providers 77 observe convergence time by packet loss, so IGP Route Convergence 78 is considered a Direct Measure of Quality (DMOQ). The test cases 79 in this document are black-box tests that emulate the network 80 events that cause route convergence, as described in [1]. The 81 black-box test designs benchmark the data plane accounting for 82 all of the factors contributing to route convergence time, as 83 discussed in [1]. The methodology (and terminology) for 84 benchmarking route convergence can be applied to any link-state 85 IGP such as ISIS [3] and OSPF [4]. 87 2. Existing definitions 89 For the sake of clarity and continuity this RFC adopts the template 90 for definitions set out in Section 2 of RFC 1242. Definitions are 91 indexed and grouped together in sections for ease of reference. 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 95 this document are to be interpreted as described in RFC 2119. 97 3. Test Setup 98 3.1 Test Topologies 100 Figure 1 shows the test topology to measure IGP Route Convergence due 101 to local Convergence Events such as SONET Link Failure, PPP Session 102 Failure, IGP Adjacency Failure, Route Withdrawal, and route cost 103 change. These test cases discussed in section 4 provide route 104 convergence times that account for the Event Detection time, SPF 105 IGP Data Plane Route Convergence 107 Processing time, and FIB Update time. These times are measured 108 by observing packet loss in the data plane. 110 --------- Ingress Interface --------- 111 | |<------------------------------| | 112 | | | | 113 | | Preferred Egress Interface | | 114 | DUT |------------------------------>|Tester | 115 | | | | 116 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| | 117 | | Next-Best Egress Interface | | 118 --------- --------- 120 Figure 1. IGP Route Convergence Test Topology for Local Changes 122 Figure 2 shows the test topology to measure IGP Route Convergence 123 time due to remote changes in the network topology. These times are 124 measured by observing packet loss in the data plane. In this 125 topology the three routers are considered a System Under Test (SUT). 127 ----- ----------- 128 | | Preferred | | 129 ----- |R2 |---------------------->| | 130 | |-->| | Egress Interface | | 131 | | ----- | | 132 |R1 | | Tester | 133 | | ----- | | 134 | |-->| | Next-Best | | 135 ----- |R3 |~~~~~~~~~~~~~~~~~~~~~~>| | 136 ^ | | Egress Interface | | 137 | ----- ----------- 138 | | 139 |-------------------------------------- 140 Ingress Interface 142 Figure 2. IGP Route Convergence Test Topology 143 for Remote Changes 145 Figure 3 shows the test topology to measure IGP Route Convergence 146 time with members of an ECMP Set. These times are measured by 147 observing packet loss in the data plane. In this topology, the DUT 148 is configured with each Egress interface as a member of an ECMP set 149 and the Tester emulates multiple next-hop routers (emulates one 150 router for each member). 152 IGP Data Plane Route Convergence 154 --------- Ingress Interface --------- 155 | |<--------------------------------| | 156 | | | | 157 | | ECMP Set Interface 1 | | 158 | DUT |-------------------------------->| Tester| 159 | | . | | 160 | | . | | 161 | | . | | 162 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| | 163 | | ECMP Set Interface N | | 164 --------- --------- 166 Figure 3. IGP Route Convergence Test Topology 167 for ECMP Convergence 169 Figure 4 shows the test topology to measure IGP Route Convergence 170 time with members of a Parallel Link. These times are measured by 171 observing packet loss in the data plane. In this topology, the DUT 172 is configured with each Egress interface as a member of a Parallel 173 Link and the Tester emulates the single next-hop router. 175 --------- Ingress Interface --------- 176 | |<--------------------------------| | 177 | | | | 178 | | Parallel Link Interface 1 | | 179 | DUT |-------------------------------->| Tester| 180 | | . | | 181 | | . | | 182 | | . | | 183 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| | 184 | | Parallel Link Interface N | | 185 --------- --------- 187 Figure 4. IGP Route Convergence Test Topology 188 for Parallel Link Convergence 190 3.2 Test Considerations 192 3.2.1 IGP Selection 193 The test cases described in section 4 can be used for ISIS or 194 OSPF. The Route Convergence test methodology for both is 195 identical. The IGP adjacencies are established on the Preferred 196 Egress Interface and Next-Best Egress Interface. 198 3.2.2 BGP Configuration 199 The obtained results for IGP Route Convergence may vary if 200 BGP routes are installed. It is recommended that the IGP 201 Convergence times be benchmarked without BGP routes installed. 203 IGP Data Plane Route Convergence 205 3.2.3 IGP Route Scaling 206 The number of IGP routes will impact the measured IGP Route 207 Convergence because convergence for the entire IGP route table is 208 measured. For results similar to those that would be observed in 209 an operational network it is recommended that the number of 210 installed routes closely approximate that for routers in the 211 network. 213 3.2.4 Timers 214 There are some timers that will impact the measured IGP Convergence 215 time. The following timers should be configured to the minimum value 216 prior to beginning execution of the test cases: 218 Timer Recommended Value 219 ----- ----------------- 220 SONET Failure Indication Delay <10milliseconds 221 IGP Hello Timer 1 second 222 IGP Dead-Interval 3 seconds 223 LSA Generation Delay 0 224 LSA Flood Packet Pacing 0 225 LSA Retransmission Packet Pacing 0 226 SPF Delay 0 228 3.2.5 Convergence Time Metrics 229 Figure 5 shows a graph model of Convergence Time as measured 230 from the data plane. Refer to [2] for definitions of the terms 231 used. Rate-Derived Convergence Time and Loss-Derived Convergence 232 Time are the two metrics for convergence time. An offered Load of 233 maximum forwarding rate at a fixed packet size is recommended for 234 accurate measurement. The test duration must be greater than the 235 convergence time. 237 Ideally, Convergence Event Transition and Convergence Recovery 238 Transition are instantaneous so that the 239 Rate-Derived Convergence Time = Loss-Derived Convergence Time. 241 When the Convergence Event Transition and Convergence Recovery 242 Transition are not instantaneous so that there is a slope, as 243 shown in Figure 5, the accuracy of the Rate-Derived Convergence 244 Time and Loss-Derived Convergence Time are dependent upon the 245 Packet Sampling Interval. 247 Under this condition and the Packet Sampling Interval <= 100 248 millisecond, the Rate-Derived Convergence Time > Loss-Derived 249 Convergence Time and Rate-Derived Convergence Time is the preferred 250 metric. Under this condition and the Packet Sampling Interval > 100 251 millisecond the Rate-Derived Convergence Time < Loss-Derived 252 Convergence Time and Loss-Derived Convergence Time is the better 253 metric. For all test cases, the Rate-Derived Convergence Time 254 and Loss-Derived Convergence Time must be recorded. 256 IGP Data Plane Route Convergence 258 Recovery Convergence Event Time = 0sec 259 Maximum ^ ^ ^ 260 Forwarding Rate--> ----\ Packet /--------------- 261 \ Loss /<----Convergence 262 Convergence------->\ / Event Transition 263 Recovery Transition \ / 264 \_____/<------100% Packet Loss 266 X-axis = Time 267 Y-axis = Forwarding Rate 269 Figure 5. Convergence Graph 271 3.2.6 Packet Sampling Interval 272 Selection of the Packet Sampling Interval on the Test Equipment 273 impacts the measured Rate-Derived Convergence Time. Packet 274 Sampling Interval time is that is too large exaggerates the 275 slope of the Convergence Event Transition and Convergence 276 Recovery Transition producing a larger than the actual Rate-Derived 277 Convergence Time. This impact is greater as routers achieve 278 millisecond convergence times. The recommended value for the 279 Packet Sampling Interval is 100 millisecond. It is possible to 280 have commercially available test equipment with a minimum 281 configurable Packet Sampling Interval of 1 second. 283 3.2.7 Interface Types 284 All test cases in this methodology document may be executed with 285 any interface type. SONET is recommended and specifically 286 mentioned in the procedures because it can be configured to have 287 no or negligible affect on the measured convergence time. 288 Ethernet (10Mb, 100Mb, 1Gb, and 10Gb) is not preferred since 289 broadcast media are unable to detect loss of host and rely upon 290 IGP Hellos to detect session loss. 292 3.3 Reporting Format 293 For each test case, it is recommended that the following reporting 294 format be completed: 296 IGP Data Plane Route Convergence 298 Parameter Units 299 --------- ----- 300 IGP (ISIS or OSPF) 301 Interface Type (GigE, POS, ATM, etc.) 302 Packet Size bytes 303 IGP Routes number of IGP routes 304 Packet Sampling Interval seconds or milliseconds 305 IGP Timer Values 306 SONET Failure Indication Delay seconds or milliseconds 307 IGP Hello Timer seconds or milliseconds 308 IGP Dead-Interval seconds or milliseconds 309 LSA Generation Delay seconds or milliseconds 310 LSA Flood Packet Pacing seconds or milliseconds 311 LSA Retransmission Packet Pacing seconds or milliseconds 312 SPF Delay seconds or milliseconds 313 Results 314 Rate-Derived Convergence Time seconds or milliseconds 315 Loss-Derived Convergence Time seconds or milliseconds 316 Restoration Convergence Time seconds or milliseconds 318 4. Test Cases 319 4.1 Convergence Due to Link Failure 320 4.1.1 Convergence Due to Local Interface Failure 321 Objective 322 To obtain the IGP Route Convergence due to a local link 323 failure event at the DUT's Local Interface. 325 Procedure 326 1. Advertise matching IGP routes from Tester to DUT on 327 Preferred Egress Interface [2] and Next-Best Egress Interface 328 [2] using the topology shown in Figure 1. Set the cost of the 329 routes so that the Preferred Egress Interface is the preferred 330 next-hop. 331 2. Send traffic at maximum forwarding rate to destinations 332 matching all IGP routes from Tester to DUT on Ingress Interface 333 [2]. 334 3. Verify traffic routed over Preferred Egress Interface. 335 4. Remove SONET on DUT's Local Interface [2] by performing an 336 administrative shutdown of the interface. 337 5. Measure Rate-Derived Convergence Time [2] and Loss-Derived 338 Convergence Time [2] as DUT detects the link down event and 339 converges all IGP routes and traffic over the Next-Best Egress 340 Interface. 341 6. Restore SONET on DUT's Local Interface by administratively 342 enabling the interface. 343 7. Measure Restoration Convergence Time [2] as DUT detects the link 344 up event and converges all IGP routes and traffic back to the 345 Preferred Egress Interface. 347 Results 348 The measured IGP Convergence time is influenced by the Local 349 SONET indication, SPF delay, SPF Holdtime, SPF Execution 350 Time, Tree Build Time, and Hardware Update Time. 352 IGP Data Plane Route Convergence 353 4.1.2 Convergence Due to Neighbor Interface Failure 354 Objective 355 To obtain the IGP Route Convergence due to a local link 356 failure event at the Tester's Neighbor Interface. 358 Procedure 359 1. Advertise matching IGP routes from Tester to DUT on 360 Preferred Egress Interface [2] and Next-Best Egress Interface 361 [2] using the topology shown in Figure 1. Set the cost of 362 the routes so that the Preferred Egress Interface is the 363 preferred next-hop. 364 2. Send traffic at maximum forwarding rate to destinations 365 matching all IGP routes from Tester to DUT on Ingress 366 Interface [2]. 367 3. Verify traffic routed over Preferred Egress Interface. 368 4. Remove SONET on Tester's Neighbor Interface [2] connected to 369 DUT' s Preferred Egress Interface. 370 5. Measure Rate-Derived Convergence Time [2] and Loss-Derived 371 Convergence Time [2] as DUT detects the link down event and 372 converges all IGP routes and traffic over the Next-Best 373 Egress Interface. 374 6. Restore SONET on Tester's Neighbor Interface connected to 375 DUT's Preferred Egress Interface. 376 7. Measure Restoration Convergence Time [2] as DUT detects the 377 link up event and converges all IGP routes and traffic back to 378 the Preferred Egress Interface. 380 Results 381 The measured IGP Convergence time is influenced by the Local 382 SONET indication, SPF delay, SPF Holdtime, SPF Execution 383 Time, Tree Build Time, and Hardware Update Time. 385 4.1.3 Convergence Due to Remote Interface Failure 387 Objective 388 To obtain the IGP Route Convergence due to a Remote 389 Interface failure event. 391 Procedure 392 1. Advertise matching IGP routes from Tester to SUT on 393 Preferred Egress Interface [2] and Next-Best Egress Interface 394 [2] using the topology shown in Figure 2. Set the cost of the 395 routes so that the Preferred Egress Interface is the preferred 396 next-hop. NOTE: All routers in the SUT must be the same model 397 and identically configured. 398 2. Send traffic at maximum forwarding rate to destinations 399 matching all IGP routes from Tester to DUT on Ingress Interface 400 [2]. 401 3. Verify traffic is routed over Preferred Egress Interface. 402 4. Remove SONET on Tester's Neighbor Interface [2] connected to 403 SUT' s Preferred Egress Interface. 405 IGP Data Plane Route Convergence 407 5. Measure Rate-Derived Convergence Time [2] and Loss-Derived 408 Convergence Time [2] as SUT detects the link down event and 409 converges all IGP routes and traffic over the Next-Best 410 Egress Interface. 411 6. Restore SONET on Tester's Neighbor Interface connected to 412 SUT's Preferred Egress Interface. 413 7. Measure Restoration Convergence Time [2] as SUT detects the 414 link up event and converges all IGP routes and traffic over 415 the Preferred Egress Interface. 417 Results 418 The measured IGP Convergence time is influenced by the 419 SONET failure indication, LSA/LSP Flood Packet Pacing, 420 LSA/LSP Retransmission Packet Pacing, LSA/LSP Generation 421 time, SPF delay, SPF Holdtime, SPF Execution Time, Tree 422 Build Time, and Hardware Update Time. The additional 423 convergence time contributed by LSP Propagation can be 424 obtained by subtracting the Rate-Derived Convergence Time 425 measured in 4.1.2 (Convergence Due to Neighbor Interface 426 Failure) from the Rate-Derived Convergence Time measured in 427 this test case. 429 4.2 Convergence Due to PPP Session Failure 430 Objective 431 To obtain the IGP Route Convergence due to a Local PPP Session 432 failure event. 434 Procedure 435 1. Advertise matching IGP routes from Tester to DUT on 436 Preferred Egress Interface [2] and Next-Best Egress Interface 437 [2] using the topology shown in Figure 1. Set the cost of 438 the routes so that the IGP routes along the Preferred Egress 439 Interface is the preferred next-hop. 440 2. Send traffic at maximum forwarding rate to destinations 441 matching all IGP routes from Tester to DUT on Ingress 442 Interface [2]. 443 3. Verify traffic routed over Preferred Egress Interface. 444 4. Remove PPP session from Tester's Neighbor Interface [2] 445 connected to Preferred Egress Interface. 446 5. Measure Rate-Derived Convergence Time [2] and Loss-Derived 447 Convergence Time [2] as DUT detects the PPP session down event 448 and converges all IGP routes and traffic over the Next-Best 449 Egress Interface. 450 6. Restore PPP session on DUT's Preferred Egress Interface. 451 7. Measure Restoration Convergence Time [2] as DUT detects the 452 session up event and converges all IGP routes and traffic over 453 the Preferred Egress Interface. 455 Results 456 The measured IGP Convergence time is influenced by the PPP 457 failure indication, SPF delay, SPF Holdtime, SPF Execution 458 Time, Tree Build Time, and Hardware Update Time. 460 IGP Data Plane Route Convergence 462 4.3 Convergence Due to IGP Adjacency Failure 464 Objective 465 To obtain the IGP Route Convergence due to a Local IGP Adjacency 466 failure event. 468 Procedure 469 1. Advertise matching IGP routes from Tester to DUT on 470 Preferred Egress Interface [2] and Next-Best Egress Interface 471 [2] using the topology shown in Figure 1. Set the cost of 472 the routes so that the Preferred Egress Interface is the 473 preferred next-hop. 474 2. Send traffic at maximum forwarding rate to destinations 475 matching all IGP routes from Tester to DUT on Ingress 476 Interface [2]. 477 3. Verify traffic routed over Preferred Egress Interface. 478 4. Remove IGP adjacency from Tester's Neighbor Interface [2] 479 connected to Preferred Egress Interface. 480 5. Measure Rate-Derived Convergence Time [2] and Loss-Derived 481 Convergence Time [2] as DUT detects the IGP session failure 482 event and converges all IGP routes and traffic over the 483 Next-Best Egress Interface. 484 6. Restore IGP session on DUT's Preferred Egress Interface. 485 7. Measure Restoration Convergence Time [2] as DUT detects the 486 session up event and converges all IGP routes and traffic over 487 the Preferred Egress Interface. 489 Results 490 The measured IGP Convergence time is influenced by the IGP 491 Hello Interval, IGP Dead Interval, SPF delay, SPF Holdtime, 492 SPF Execution Time, Tree Build Time, and Hardware Update 493 Time. 495 4.4 Convergence Due to Route Withdrawal 497 Objective 498 To obtain the IGP Route Convergence due to Route Withdrawal. 500 Procedure 501 1. Advertise matching IGP routes from Tester to DUT on 502 Preferred Egress Interface [2] and Next-Best Egress Interface 503 [2] using the topology shown in Figure 1. Set the cost of 504 the routes so that the Preferred Egress Interface is the 505 preferred next-hop. 506 2. Send traffic at maximum forwarding rate to destinations 507 matching all IGP routes from Tester to DUT on Ingress 508 Interface [2]. 509 3. Verify traffic routed over Preferred Egress Interface. 510 4. Tester withdraws all IGP routes from DUT's Local Interface 511 on Preferred Egress Interface. 513 IGP Data Plane Route Convergence 515 5. Measure Rate-Derived Convergence Time [2] and Loss-Derived 516 Convergence Time [2] as DUT processes the route withdrawal 517 event and converges all IGP routes and traffic over the 518 Next-Best Egress Interface. 519 6. Re-advertise IGP routes to DUT's Preferred Egress Interface. 520 7. Measure Restoration Convergence Time [2] as DUT converges all 521 IGP routes and traffic over the Preferred Egress Interface. 523 Results 524 The measured IGP Convergence time is the SPF Processing and FIB 525 Update time as influenced by the SPF delay, SPF Holdtime, 526 SPF Execution Time, Tree Build Time, and Hardware Update Time. 528 4.5 Convergence Due to Cost Change 530 Objective 531 To obtain the IGP Route Convergence due to route cost change. 533 Procedure 534 1. Advertise matching IGP routes from Tester to DUT on 535 Preferred Egress Interface [2] and Next-Best Egress Interface 536 [2] using the topology shown in Figure 1. Set the cost of 537 the routes so that the Preferred Egress Interface is the 538 preferred next-hop. 539 2. Send traffic at maximum forwarding rate to destinations 540 matching all IGP routes from Tester to DUT on Ingress 541 Interface [2]. 542 3. Verify traffic routed over Preferred Egress Interface. 543 4. Tester increases cost for all IGP routes at DUT's Preferred 544 Egress Interface so that the Next-Best Egress Inerface 545 has lower cost and becomes preferred path. 546 5. Measure Rate-Derived Convergence Time [2] and Loss-Derived 547 Convergence Time [2] as DUT detects the cost change event 548 and converges all IGP routes and traffic over the Next-Best 549 Egress Interface. 550 6. Re-advertise IGP routes to DUT's Preferred Egress Interface 551 with original lower cost metric. 552 7. Measure Restoration Convergence Time [2] as DUT converges all 553 IGP routes and traffic over the Preferred Egress Interface. 555 Results 556 There should be no measured packet loss for this case. 558 4.6 Convergence Due to ECMP Member Interface Failure 560 Objective 561 To obtain the IGP Route Convergence due to a local link 562 failure event of an ECMP Member. 564 IGP Data Plane Route Convergence 566 Procedure 567 1. Configure ECMP Set as shown in Figure 3. 568 2. Advertise matching IGP routes from Tester to DUT on 569 each ECMP member. 570 3. Send traffic at maximum forwarding rate to destinations 571 matching all IGP routes from Tester to DUT on Ingress 572 Interface [2]. 573 4. Verify traffic routed over all members of ECMP Set. 574 5. Remove SONET on Tester's Neighbor Interface [2] connected to 575 one of the DUT's ECMP member interfaces. 576 6. Measure Rate-Derived Convergence Time [2] and Loss-Derived 577 Convergence Time [2] as DUT detects the link down event and 578 converges all IGP routes and traffic over the other ECMP 579 members. 580 7. Restore SONET on Tester's Neighbor Interface connected to 581 DUT's ECMP member interface. 582 8. Measure Restoration Convergence Time [2] as DUT detects the 583 link up event and converges IGP routes and some distribution 584 of traffic over the restored ECMP member. 586 Results 587 The measured IGP Convergence time is influenced by the Local 588 SONET indication, Tree Build Time, and Hardware Update Time. 590 4.7 Convergence Due to Parallel Link Interface Failure 591 Objective 592 To obtain the IGP Route Convergence due to a local link 593 failure event for a Member of a Parallel Link. 595 Procedure 596 1. Configure Parallel Link as shown in Figure 4. 597 2. Advertise matching IGP routes from Tester to DUT on 598 each Parallel Link member. 599 3. Send traffic at maximum forwarding rate to destinations 600 matching all IGP routes from Tester to DUT on Ingress 601 Interface [2]. 602 4. Verify traffic routed over all members of Parallel Link. 603 5. Remove SONET on Tester's Neighbor Interface [2] connected to 604 one of the DUT's Parallel Link member interfaces. 605 6. Measure Rate-Derived Convergence Time [2] and Loss-Derived 606 Convergence Time [2] as DUT detects the link down event and 607 converges all IGP routes and traffic over the other 608 Parallel Link members. 609 7. Restore SONET on Tester's Neighbor Interface connected to 610 DUT's Parallel Link member interface. 611 8. Measure Restoration Convergence Time [2] as DUT detects the 612 link up event and converges IGP routes and some distribution 613 of traffic over the restored Parallel Link member. 615 Results 616 The measured IGP Convergence time is influenced by the Local 617 SONET indication, Tree Build Time, and Hardware Update Time. 619 IGP Data Plane Route Convergence 621 5. 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 6. References 630 [1] Poretsky, S., "Benchmarking Applicability for IGP 631 Convergence", draft-ietf-bmwg-igp-dataplane-conv-app-01, work 632 in progress, October 2003. 634 [2] Poretsky, S., Imhoff, B., "Benchmarking Terminology for IGP Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-01, work 635 in progress, October 2003. 637 [3] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual 638 Environments", RFC 1195, December 1990. 640 [4] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 642 7. Author's Address 644 Scott Poretsky 645 Quarry Technologies 646 8 New England Executive Park 647 Burlington, MA 01803 648 USA 650 Phone: + 1 781 395 5090 651 EMail: sporetsky@quarrytech.com 653 Brent Imhoff 654 WilTel Communications 655 3180 Rider Trail South 656 Bridgeton, MO 63045 657 USA 659 Phone: +1 314 595 6853 660 EMail: brent.imhoff@wcg.com 662 8. Full Copyright Statement 664 Copyright (C) The Internet Society (1998). All Rights 665 Reserved. 667 This document and translations of it may be copied and 668 furnished to others, and derivative works that comment on or 669 otherwise explain it or assist in its implementation may be 670 IGP Data Plane Route Convergence 672 prepared, copied, published and distributed, in whole or in 673 part, without restriction of any kind, provided that the above 674 copyright notice and this paragraph are included on all such 675 copies and derivative works. However, this document itself may 676 not be modified in any way, such as by removing the copyright 677 notice or references to the Internet Society or other Internet 678 organizations, except as needed for the purpose of developing 679 Internet standards in which case the procedures for copyrights 680 defined in the Internet Standards process must be followed, or 681 as required to translate it into languages other than English. 683 The limited permissions granted above are perpetual and will 684 not be revoked by the Internet Society or its successors or 685 assigns. This document and the information contained herein is 686 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 687 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 688 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 689 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 690 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 691 FOR A PARTICULAR PURPOSE.