idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-meth-06.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 667. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 678. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 685. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 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 11 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 219 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [Br97], [5,6], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 246: '... Interval value MUST be the smallest ...' RFC 2119 keyword, line 251: '... All interfaces MUST be the same medi...' RFC 2119 keyword, line 252: '... Throughout [5,6] for each test case. Media and protocols MUST...' RFC 2119 keyword, line 261: '...The offered Load MUST be the Throughpu...' RFC 2119 keyword, line 263: '...s selectable and MUST be recorded. Th...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 255 has weird spacing: '...ET with minim...' == Line 282 has weird spacing: '...n Delay sec...' == Line 287 has weird spacing: '... Pacing secon...' -- 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 (December 2005) is 6678 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 613 looks like a reference -- Missing reference section? '2' on line 617 looks like a reference -- Missing reference section? '3' on line 621 looks like a reference -- Missing reference section? '4' on line 624 looks like a reference -- Missing reference section? 'Br97' on line 103 looks like a reference -- Missing reference section? '5' on line 626 looks like a reference -- Missing reference section? '6' on line 629 looks like a reference -- Missing reference section? '7' on line 632 looks like a reference Summary: 15 errors (**), 0 flaws (~~), 6 warnings (==), 14 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: December 2005 4 Scott Poretsky 5 Quarry Technologies 7 Brent Imhoff 8 LightCore 10 June 2005 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 This document is an Internet-Draft and is in full conformance with 26 all provisions of Section 10 of RFC2026. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups June also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and June be updated, replaced, or obsoleted by other 35 documents at any time. It is inappropriate to use Internet-Drafts 36 as reference material or to cite them other than as "work in 37 progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 ABSTRACT 46 This draft describes the methodology for benchmarking IGP Route 47 Convergence as described in Applicability document [1] and 48 Terminology document [2]. The methodology and terminology are 49 to be used for benchmarking route convergence and can be applied 50 to any link-state IGP such as ISIS [3] and OSPF [4]. The terms 51 used in the procedures provided within this document are 52 defined in [2]. 54 IGP Data Plane Route Convergence 56 Table of Contents 57 1. Introduction ...............................................2 58 2. Existing definitions .......................................2 59 3. Test Setup..................................................3 60 3.1 Test Topologies............................................3 61 3.2 Test Considerations........................................4 62 3.3 Reporting Format...........................................6 63 4. Test Cases..................................................7 64 4.1 Convergence Due to Link Failure............................7 65 4.1.1 Convergence Due to Local Interface Failure...............7 66 4.1.2 Convergence Due to Neighbor Interface Failure............7 67 4.1.3 Convergence Due to Remote Interface Failure..............8 68 4.2 Convergence Due to Layer 2 Session Failure.................9 69 4.3 Convergence Due to IGP Adjacency Failure...................10 70 4.4 Convergence Due to Route Withdrawal........................10 71 4.5 Convergence Due to Cost Change.............................11 72 4.6 Convergence Due to ECMP Member Interface Failure...........12 73 4.7 Convergence Due to Parallel Link Interface Failure.........12 74 5. Security Considerations.....................................13 75 6. Normative References........................................13 76 7. Author's Address............................................13 78 1. Introduction 79 This draft describes the methodology for benchmarking IGP Route 80 Convergence. The applicability of this testing is described in 81 [1] and the new terminology that it introduces is defined in [2]. 82 Service Providers use IGP Convergence time as a key metric of 83 router design and architecture. Customers of Service Providers 84 observe convergence time by packet loss, so IGP Route Convergence 85 is considered a Direct Measure of Quality (DMOQ). The test cases 86 in this document are black-box tests that emulate the network 87 events that cause route convergence, as described in [1]. The 88 black-box test designs benchmark the data plane accounting for 89 all of the factors contributing to convergence time, as discussed 90 in [1]. The methodology (and terminology) for benchmarking route 91 convergence can be applied to any link-state IGP such as ISIS [3] 92 and OSPF [4]. These methodologies apply to IPv4 and IPv6 traffic 93 as well as IPv4 and IPv6 IGPs. 95 2. Existing definitions 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "JUNE", and "OPTIONAL" in this 98 document are to be interpreted as described in BCP 14, RFC 2119 99 [Br97]. RFC 2119 defines the use of these key words to help make the 100 intent of standards track documents as clear as possible. While this 101 document uses these keywords, this document is not a standards track 102 document. 104 IGP Data Plane Route Convergence 106 3. Test Setup 107 3.1 Test Topologies 108 Figure 1 shows the test topology to measure IGP Route Convergence due 109 to local Convergence Events such as SONET Link Failure, Layer 2 Session 110 Failure, IGP Adjacency Failure, Route Withdrawal, and route cost 111 change. These test cases discussed in section 4 provide route 112 convergence times that account for the Event Detection time, SPF 113 Processing time, and FIB Update time. These times are measured 114 by observing packet loss in the data plane. 116 --------- Ingress Interface --------- 117 | |<--------------------------------| | 118 | | | | 119 | | Preferred Egress Interface | | 120 | DUT |-------------------------------->| Tester| 121 | | | | 122 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| | 123 | | Next-Best Egress Interface | | 124 --------- --------- 126 Figure 1. IGP Route Convergence Test Topology for Local Changes 128 Figure 2 shows the test topology to measure IGP Route Convergence 129 time due to remote changes in the network topology. These times are 130 measured by observing packet loss in the data plane. In this 131 topology the three routers are considered a System Under Test (SUT). 132 NOTE: All routers in the SUT must be the same model and identically 133 configured. 135 ----- --------- 136 | | Preferred | | 137 ----- |R2 |---------------------->| | 138 | |-->| | Egress Interface | | 139 | | ----- | | 140 |R1 | |Tester | 141 | | ----- | | 142 | |-->| | Next-Best | | 143 ----- |R3 |~~~~~~~~~~~~~~~~~~~~~~>| | 144 ^ | | Egress Interface | | 145 | ----- --------- 146 | | 147 |-------------------------------------- 148 Ingress Interface 150 Figure 2. IGP Route Convergence Test Topology 151 for Remote Changes 153 Figure 3 shows the test topology to measure IGP Route Convergence 154 time with members of an Equal Cost Multipath (ECMP) Set. These times are 155 measured by observing packet loss in the data plane. In this topology, 156 the DUT 157 IGP Data Plane Route Convergence 159 is configured with each Egress interface as a member of an ECMP set 160 and the Tester emulates multiple next-hop routers (emulates one 161 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 June 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 is 216 measured. For results similar to those that would be observed in 217 an operational network it is recommended that the number of 218 installed routes closely approximate that for routers in the 219 network. The number of areas (for OSPF) and levels (for ISIS) can 220 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 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 the smallest measurable convergence 247 time. 249 3.2.6 Interface Types 250 All test cases in this methodology document June be executed with 251 any interface type. All interfaces MUST be the same media and 252 Throughout [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) [7]. 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. The packet 263 size is selectable and MUST be recorded. The Throughput MUST be 264 measured at the Preferred Egress Interface and the Next-Best 265 Egress Interface. The duration of offered load MUST be greater 266 than the convergence time. The destination addresses for the 267 offered load MUST be distributed such that all routes are matched. 268 This enables Full Convergence [2] to be observed. 270 3.3 Reporting Format 271 For each test case, it is recommended that the following reporting 272 format be completed: 274 Parameter Units 275 --------- ----- 276 IGP (ISIS or OSPF) 277 Interface Type (GigE, POS, ATM, etc.) 278 Packet Size offered to DUT bytes 279 IGP Routes advertised to DUT number of IGP routes 280 Packet Sampling Interval on Tester seconds or milliseconds 281 IGP Timer Values configured on DUT 282 SONET Failure Indication Delay seconds or milliseconds 283 IGP Hello Timer seconds or milliseconds 284 IGP Dead-Interval seconds or milliseconds 285 LSA Generation Delay seconds or milliseconds 286 LSA Flood Packet Pacing seconds or milliseconds 287 LSA Retransmission Packet Pacing seconds or milliseconds 288 SPF Delay seconds or milliseconds 289 Benchmarks 290 Rate-Derived Convergence Time seconds or milliseconds 291 Loss-Derived Convergence Time seconds or milliseconds 292 Restoration Convergence Time seconds or milliseconds 293 IGP Data Plane Route Convergence 295 4. Test Cases 296 4.1 Convergence Due to Link Failure 297 4.1.1 Convergence Due to Local Interface Failure 298 Objective 299 To obtain the IGP Route Convergence due to a local link 300 failure event at the DUT's Local Interface. 302 Procedure 303 1. Advertise matching IGP routes from Tester to DUT on 304 Preferred Egress Interface [2] and Next-Best Egress Interface 305 [2] using the topology shown in Figure 1. Set the cost of the 306 routes so that the Preferred Egress Interface is the preferred 307 next-hop. 308 2. Send offered load at measured Throughput with fixed packet size 309 to destinations matching all IGP routes from Tester to DUT on 310 Ingress Interface [2]. 311 3. Verify traffic routed over Preferred Egress Interface. 312 4. Remove link on DUT's Local Interface [2] by performing an 313 administrative shutdown of the interface. 314 5. Measure Rate-Derived Convergence Time [2] as DUT detects the 315 link down event and converges all IGP routes and traffic over 316 the Next-Best Egress Interface. 317 6. Stop offered load. Wait 30 seconds for queues to drain. 318 Restart Offered Load. 319 7. Restore link on DUT's Local Interface by administratively 320 enabling the interface. 322 8. Measure Restoration Convergence Time [2] as DUT detects the link 323 up event and converges all IGP routes and traffic back to the 324 Preferred Egress Interface. 326 Results 327 The measured IGP Convergence time is influenced by the Local 328 link failure indication, SPF delay, SPF Holdtime, SPF Execution 329 Time, Tree Build Time, and Hardware Update Time. 331 4.1.2 Convergence Due to Neighbor Interface Failure 332 Objective 333 To obtain the IGP Route Convergence due to a local link 334 failure event at the Tester's Neighbor Interface. 336 Procedure 337 1. Advertise matching IGP routes from Tester to DUT on 338 Preferred Egress Interface [2] and Next-Best Egress Interface 339 [2] using the topology shown in Figure 1. Set the cost of 340 the routes so that the Preferred Egress Interface is the 341 preferred next-hop. 342 2. Send offered load at measured Throughput with fixed packet size 343 to destinations matching all IGP routes from Tester to DUT on 344 Ingress Interface [2]. 346 IGP Data Plane Route Convergence 348 3. Verify traffic routed over Preferred Egress Interface. 349 4. Remove link on Tester's Neighbor Interface [2] connected to 350 DUT' s Preferred Egress Interface. 351 5. Measure Rate-Derived Convergence Time [2] as DUT detects the 352 link down event and converges all IGP routes and traffic over 353 the Next-Best Egress Interface. 354 6. Stop offered load. Wait 30 seconds for queues to drain. 355 Restart Offered Load. 356 7. Restore link on Tester's Neighbor Interface connected to 357 DUT's Preferred Egress Interface. 358 8. Measure Restoration Convergence Time [2] as DUT detects the 359 link up event and converges all IGP routes and traffic back to 360 the Preferred Egress Interface. 362 Results 363 The measured IGP Convergence time is influenced by the Local 364 link failure indication, SPF delay, SPF Holdtime, SPF Execution 365 Time, Tree Build Time, and Hardware Update Time. 367 4.1.3 Convergence Due to Remote Interface Failure 368 Objective 369 To obtain the IGP Route Convergence due to a Remote Interface 370 Failure event. 372 Procedure 373 1. Advertise matching IGP routes from Tester to SUT on 374 Preferred Egress Interface [2] and Next-Best Egress Interface 375 [2] using the topology shown in Figure 2. Set the cost of the 376 routes so that the Preferred Egress Interface is the preferred 377 next-hop. 378 2. Send offered load at measured Throughput with fixed packet size 379 to destinations matching all IGP routes from Tester to DUT on 380 Ingress Interface [2]. 381 3. Verify traffic is routed over Preferred Egress Interface. 382 4. Remove link on Tester's Neighbor Interface [2] connected to 383 SUT' s Preferred Egress Interface. 384 5. Measure Rate-Derived Convergence Time [2] as SUT detects 385 the link down event and converges all IGP routes and traffic 386 over the Next-Best Egress Interface. 387 6. Stop offered load. Wait 30 seconds for queues to drain. 388 Restart Offered Load. 389 7. Restore link on Tester's Neighbor Interface connected to 390 DUT's Preferred Egress Interface. 391 8. Measure Restoration Convergence Time [2] as DUT detects the 392 link up event and converges all IGP routes and traffic back to 393 the Preferred Egress Interface. 395 IGP Data Plane Route Convergence 397 Results 398 The measured IGP Convergence time is influenced by the 399 link failure failure indication, LSA/LSP Flood Packet Pacing, 400 LSA/LSP Retransmission Packet Pacing, LSA/LSP Generation 401 time, SPF delay, SPF Holdtime, SPF Execution Time, Tree 402 Build Time, and Hardware Update Time. The additional 403 convergence time contributed by LSP Propagation can be 404 obtained by subtracting the Rate-Derived Convergence Time 405 measured in 4.1.2 (Convergence Due to Neighbor Interface 406 Failure) from the Rate-Derived Convergence Time measured in 407 this test case. 409 4.2 Convergence Due to Layer 2 Session Failure 410 Objective 411 To obtain the IGP Route Convergence due to a Local Layer 2 Session 412 failure event. 414 Procedure 415 1. Advertise matching IGP routes from Tester to DUT on 416 Preferred Egress Interface [2] and Next-Best Egress Interface 417 [2] using the topology shown in Figure 1. Set the cost of 418 the routes so that the IGP routes along the Preferred Egress 419 Interface is the preferred next-hop. 420 2. Send offered load at measured Throughput with fixed packet size 421 to destinations matching all IGP routes from Tester to DUT on 422 Ingress Interface [2]. 423 3. Verify traffic routed over Preferred Egress Interface. 424 4. Remove Layer 2 session from Tester's Neighbor Interface [2] 425 connected to Preferred Egress Interface. 426 5. Measure Rate-Derived Convergence Time [2] as DUT detects the 427 Layer 2 session down event and converges all IGP routes and 428 traffic over the Next-Best Egress Interface. 429 6. Restore Layer 2 session on DUT's Preferred Egress Interface. 430 7. Measure Restoration Convergence Time [2] as DUT detects the 431 session up event and converges all IGP routes and traffic over 432 the Preferred Egress Interface. 434 Results 435 The measured IGP Convergence time is influenced by the Layer 2 436 failure indication, SPF delay, SPF Holdtime, SPF Execution 437 Time, Tree Build Time, and Hardware Update Time. 439 IGP Data Plane Route Convergence 441 4.3 Convergence Due to IGP Adjacency Failure 443 Objective 444 To obtain the IGP Route Convergence due to a Local IGP Adjacency 445 failure event. 447 Procedure 448 1. Advertise matching IGP routes from Tester to DUT on 449 Preferred Egress Interface [2] and Next-Best Egress Interface 450 [2] using the topology shown in Figure 1. Set the cost of 451 the routes so that the Preferred Egress Interface is the 452 preferred next-hop. 453 2. Send offered load at measured Throughput with fixed packet size 454 to destinations matching all IGP routes from Tester to DUT on 455 Ingress Interface [2]. 456 3. Verify traffic routed over Preferred Egress Interface. 457 4. Remove IGP adjacency from Tester's Neighbor Interface [2] 458 connected to Preferred Egress Interface. 459 5. Measure Rate-Derived Convergence Time [2] as DUT detects the 460 IGP session failure event and converges all IGP routes and 461 traffic over the Next-Best Egress Interface. 462 6. Stop offered load. Wait 30 seconds for queues to drain. 463 Restart Offered Load. 464 7. Restore IGP session on DUT's Preferred Egress Interface. 465 8. Measure Restoration Convergence Time [2] as DUT detects the 466 session up event and converges all IGP routes and traffic over 467 the Preferred Egress Interface. 469 Results 470 The measured IGP Convergence time is influenced by the IGP 471 Hello Interval, IGP Dead Interval, SPF delay, SPF Holdtime, 472 SPF Execution Time, Tree Build Time, and Hardware Update 473 Time. 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 size 487 to destinations matching all IGP routes from Tester to DUT on 488 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 detects the 496 Layer 2 session down event and converges all IGP routes and 497 traffic over the 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, 507 SPF Execution Time, Tree Build Time, and Hardware Update Time. 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 size 521 to destinations matching all IGP routes from Tester to DUT 522 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 measured packet loss for this case. 540 IGP Data Plane Route Convergence 542 4.6 Convergence Due to ECMP Member Interface Failure 543 Objective 544 To obtain the IGP Route Convergence due to a local link 545 failure event of an ECMP Member. 547 Procedure 548 1. Configure ECMP Set as shown in Figure 3. 549 2. Advertise matching IGP routes from Tester to DUT on 550 each ECMP member. 551 3. Send offered load at measured Throughput with fixed packet size 552 to destinations matching all IGP routes from Tester to DUT on 553 Ingress Interface [2]. 554 4. Verify traffic routed over all members of ECMP Set. 555 5. Remove link on Tester's Neighbor Interface [2] connected to 556 one of the DUT's ECMP member interfaces. 557 6. Measure Rate-Derived Convergence Time [2] as DUT detects the 558 link down event and converges all IGP routes and traffic 559 over the other ECMP members. 560 7. Stop offered load. Wait 30 seconds for queues to drain. 561 Restart Offered Load. 562 8. Restore link on Tester's Neighbor Interface connected to 563 DUT's ECMP member interface. 564 9. Measure Restoration Convergence Time [2] as DUT detects the 565 link up event and converges IGP routes and some distribution 566 of traffic over the restored ECMP member. 568 Results 569 The measured IGP Convergence time is influenced by the Local 570 link failure indication, Tree Build Time, and Hardware Update Time. 572 4.7 Convergence Due to Parallel Link Interface Failure 573 Objective 574 To obtain the IGP Route Convergence due to a local link failure 575 event for a Member of a Parallel Link. The links can be used for 576 data Load Balancing 578 Procedure 579 1. Configure Parallel Link as shown in Figure 4. 580 2. Advertise matching IGP routes from Tester to DUT on 581 each Parallel Link member. 582 3. Send offered load at measured Throughput with fixed packet size 583 to destinations matching all IGP routes from Tester to DUT on 584 Ingress Interface [2]. 585 4. Verify traffic routed over all members of Parallel Link. 586 5. Remove link on Tester's Neighbor Interface [2] connected to 587 one of the DUT's Parallel Link member interfaces. 588 6. Measure Rate-Derived Convergence Time [2] as DUT detects the 589 link down event and converges all IGP routes and traffic over 590 the other Parallel Link members. 591 7. Stop offered load. Wait 30 seconds for queues to drain. 592 Restart Offered Load. 594 IGP Data Plane Route Convergence 596 8. Restore link on Tester's Neighbor Interface connected to 597 DUT's Parallel Link member interface. 598 9. Measure Restoration Convergence Time [2] as DUT detects the 599 link up event and converges IGP routes and some distribution 600 of traffic over the restored Parallel Link member. 602 Results 603 The measured IGP Convergence time is influenced by the Local 604 link failure indication, Tree Build Time, and Hardware Update Time. 606 5. Security Considerations 607 Documents of this type do not directly affect the security of 608 the Internet or corporate networks as long as benchmarking 609 is not performed on devices or systems connected to operating 610 networks. 612 6. Normative References 613 [1] Poretsky, S., "Benchmarking Applicability for IGP 614 Convergence", draft-ietf-bmwg-igp-dataplane-conv-app-06, work 615 in progress, June 2005. 617 [2] Poretsky, S., Imhoff, B., "Benchmarking Terminology for IGP 618 Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-06, work 619 in progress, June 2005 621 [3] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual 622 Environments", RFC 1195, IETF, December 1990. 624 [4] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 626 [5] Bradner, S., "Benchmarking Terminology for Network Interconnection 627 Devices", RFC 1242, IETF, July 1991. 629 [6] Bradner, S. and McQuaid, J., "Benchmarking Methodology for 630 Network Interconnect Devices", RFC 2544, IETF, March 1999. 632 [7] Katz, D. and Ward, D., "Bidirectional Forwarding Detection", 633 draft-ietf-bfd-base-02.txt, work in progress, IETF, 634 March 2005. 636 7. Author's Address 638 Scott Poretsky 639 Quarry Technologies 640 8 New England Executive Park 641 Burlington, MA 01803 642 USA 644 Phone: + 1 781 395 5090 645 EMail: sporetsky@quarrytech.com 646 IGP Data Plane Route Convergence 648 Brent Imhoff 649 LightCore 650 USA 651 EMail: bimhoff@planetspork.com 653 Full Copyright Statement 655 Copyright (C) The Internet Society (2005). 657 This document is subject to the rights, licenses and restrictions 658 contained in BCP 78, and except as set forth therein, the authors 659 retain all their rights. 661 This document and the information contained herein are provided on an 662 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 663 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 664 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 665 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 666 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 667 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 669 Intellectual Property 671 The IETF takes no position regarding the validity or scope of any 672 Intellectual Property Rights or other rights that might be claimed to 673 pertain to the implementation or use of the technology described in 674 this document or the extent to which any license under such rights 675 might or might not be available; nor does it represent that it has 676 made any independent effort to identify any such rights. Information 677 on the procedures with respect to rights in RFC documents can be 678 found in BCP 78 and BCP 79. 680 Copies of IPR disclosures made to the IETF Secretariat and any 681 assurances of licenses to be made available, or the result of an 682 attempt made to obtain a general license or permission for the use of 683 such proprietary rights by implementers or users of this 684 specification can be obtained from the IETF on-line IPR repository at 685 http://www.ietf.org/ipr. 687 The IETF invites any interested party to bring to its attention any 688 copyrights, patents or patent applications, or other proprietary 689 rights that June cover technology that June be required to implement 690 this standard. Please address the information to the IETF at ietf- 691 ipr@ietf.org. 693 Acknowledgement 695 Funding for the RFC Editor function is currently provided by the 696 Internet Society.