idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-meth-03.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 3667, Section 5.1 on line 20. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 637. ** 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. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 1) being 70 lines == 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 28 instances of too long lines in the document, the longest one being 11 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 136 has weird spacing: '...tically confi...' == 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 (January 2005) is 7034 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 593 looks like a reference -- Missing reference section? '2' on line 597 looks like a reference -- Missing reference section? '3' on line 601 looks like a reference -- Missing reference section? '4' on line 604 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group 2 INTERNET-DRAFT 3 Expires in: January 2005 4 Scott Poretsky 5 Quarry Technologies 7 Brent Imhoff 9 July 2004 11 Benchmarking Methodology for 12 IGP Data Plane Route Convergence 14 16 Intellectual Property Rights (IPR) statement: 17 By submitting this Internet-Draft, I certify that any applicable 18 patent or other IPR claims of which I am aware have been disclosed, or 19 will be disclosed, and any of which I become aware will be disclosed, 20 in accordance with RFC 3668. 22 Status of this Memo 24 This document is an Internet-Draft and is in full conformance with 25 all provisions of Section 10 of RFC2026. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other 34 documents at any time. It is inappropriate to use Internet-Drafts 35 as reference material or to cite them other than as "work in 36 progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 ABSTRACT 45 This draft describes the methodology for benchmarking IGP Route 46 Convergence as described in Applicability document [1] and 47 Terminology document [2]. The methodology and terminology are 48 to be used for benchmarking route convergence and can be applied 49 to any link-state IGP such as ISIS [3] and OSPF [4]. The terms 50 used in the procedures provided within this document are 51 defined in [2]. 53 IGP Data Plane Route Convergence 55 Table of Contents 56 1. Introduction ...............................................2 57 2. Existing definitions .......................................2 58 3. Test Setup..................................................3 59 3.1 Test Topologies............................................3 60 3.2 Test Considerations........................................4 61 3.2.1 IGP Selection............................................4 62 3.2.2 BGP Configuration........................................4 63 3.2.3 IGP Route Scaling........................................5 64 3.2.4 Timers...................................................5 65 3.2.5 Convergence Time Metrics.................................5 66 3.2.6 Offered Load.............................................5 67 3.2.7 Interface Types..........................................5 68 3.3 Reporting Format...........................................6 69 4. Test Cases..................................................6 70 4.1 Convergence Due to Link Failure............................6 71 4.1.1 Convergence Due to Local Interface Failure...............6 72 4.1.2 Convergence Due to Neighbor Interface Failure............7 73 4.1.3 Convergence Due to Remote Interface Failure..............7 74 4.2 Convergence Due to PPP Session Failure.....................8 75 4.3 Convergence Due to IGP Adjacency Failure...................9 76 4.4 Convergence Due to Route Withdrawal........................9 77 4.5 Convergence Due to Cost Change.............................10 78 4.6 Convergence Due to ECMP Member Interface Failure...........10 79 4.7 Convergence Due to Parallel Link Interface Failure.........11 80 5. Security Considerations.....................................12 81 6. References..................................................12 82 7. Author's Address............................................12 84 1. Introduction 85 This draft describes the methodology for benchmarking IGP Route 86 Convergence. The applicability of this testing is described in 87 [1] and the new terminology that it introduces is defined in [2]. 88 Service Providers use IGP Convergence time as a key metric of 89 router design and architecture. Customers of Service Providers 90 observe convergence time by packet loss, so IGP Route Convergence 91 is considered a Direct Measure of Quality (DMOQ). The test cases 92 in this document are black-box tests that emulate the network 93 events that cause route convergence, as described in [1]. The 94 black-box test designs benchmark the data plane accounting for 95 all of the factors contributing to convergence time, as discussed 96 in [1]. The methodology (and terminology) for benchmarking route 97 convergence can be applied to any link-state IGP such as ISIS [3] 98 and OSPF [4]. 100 2. Existing definitions 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. 105 Terms related to IGP Convergence are defined in [2]. 107 IGP Data Plane Route Convergence 109 3. Test Setup 110 3.1 Test Topologies 112 Figure 1 shows the test topology to measure IGP Route Convergence due 113 to local Convergence Events such as SONET Link Failure, PPP Session 114 Failure, IGP Adjacency Failure, Route Withdrawal, and route cost 115 change. These test cases discussed in section 4 provide route 116 convergence times that account for the Event Detection time, SPF 117 Processing time, and FIB Update time. These times are measured 118 by observing packet loss in the data plane. 120 --------- Ingress Interface --------- 121 | |<------------------------------| | 122 | | | | 123 | | Preferred Egress Interface | | 124 | DUT |------------------------------>|Tester | 125 | | | | 126 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| | 127 | | Next-Best Egress Interface | | 128 --------- --------- 130 Figure 1. IGP Route Convergence Test Topology for Local Changes 132 Figure 2 shows the test topology to measure IGP Route Convergence 133 time due to remote changes in the network topology. These times are 134 measured by observing packet loss in the data plane. In this 135 topology the three routers are considered a System Under Test (SUT). 136 NOTE: All routers in the SUT must be the same model and identically configured. 138 ----- ----------- 139 | | Preferred | | 140 ----- |R2 |---------------------->| | 141 | |-->| | Egress Interface | | 142 | | ----- | | 143 |R1 | | Tester | 144 | | ----- | | 145 | |-->| | Next-Best | | 146 ----- |R3 |~~~~~~~~~~~~~~~~~~~~~~>| | 147 ^ | | Egress Interface | | 148 | ----- ----------- 149 | | 150 |-------------------------------------- 151 Ingress Interface 153 Figure 2. IGP Route Convergence Test Topology 154 for Remote Changes 156 Figure 3 shows the test topology to measure IGP Route Convergence 157 time with members of an Equal Cost Multipath (ECMP) Set. These times are 158 measured by observing packet loss in the data plane. In this topology, 159 the DUT 160 IGP Data Plane Route Convergence 162 is configured with each Egress interface as a member of an ECMP set 163 and the Tester emulates multiple next-hop routers (emulates one 164 router for each member). 166 --------- Ingress Interface --------- 167 | |<--------------------------------| | 168 | | | | 169 | | ECMP Set Interface 1 | | 170 | DUT |-------------------------------->| Tester| 171 | | . | | 172 | | . | | 173 | | . | | 174 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| | 175 | | ECMP Set Interface N | | 176 --------- --------- 178 Figure 3. IGP Route Convergence Test Topology 179 for ECMP Convergence 181 Figure 4 shows the test topology to measure IGP Route Convergence 182 time with members of a Parallel Link. These times are measured by 183 observing packet loss in the data plane. In this topology, the DUT 184 is configured with each Egress interface as a member of a Parallel 185 Link and the Tester emulates the single next-hop router. 187 --------- Ingress Interface --------- 188 | |<--------------------------------| | 189 | | | | 190 | | Parallel Link Interface 1 | | 191 | DUT |-------------------------------->| Tester| 192 | | . | | 193 | | . | | 194 | | . | | 195 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| | 196 | | Parallel Link Interface N | | 197 --------- --------- 199 Figure 4. IGP Route Convergence Test Topology 200 for Parallel Link Convergence 202 3.2 Test Considerations 203 3.2.1 IGP Selection 204 The test cases described in section 4 can be used for ISIS or 205 OSPF. The Route Convergence test methodology for both is 206 identical. The IGP adjacencies are established on the Preferred 207 Egress Interface and Next-Best Egress Interface. 209 3.2.2 BGP Configuration 210 The obtained results for IGP Route Convergence may vary if 211 BGP routes are installed. It is recommended that the IGP 212 Convergence times be benchmarked without BGP routes installed. 214 IGP Data Plane Route Convergence 216 3.2.3 IGP Route Scaling 217 The number of IGP routes will impact the measured IGP Route 218 Convergence because convergence for the entire IGP route table is 219 measured. For results similar to those that would be observed in 220 an operational network it is recommended that the number of 221 installed routes closely approximate that for routers in the 222 network. The number of areas (for OSPF) and levels (for ISIS) can 223 impact the benchmark results. 225 3.2.4 Timers 226 There are some timers that will impact the measured IGP Convergence 227 time. The following timers should be configured to the minimum value 228 prior to beginning execution of the test cases: 230 Timer Recommended Value 231 ----- ----------------- 232 SONET Failure Indication Delay <10milliseconds 233 IGP Hello Timer 1 second 234 IGP Dead-Interval 3 seconds 235 LSA Generation Delay 0 236 LSA Flood Packet Pacing 0 237 LSA Retransmission Packet Pacing 0 238 SPF Delay 0 240 3.2.5 Convergence Time Metrics 241 The recommended value for the Packet Sampling Interval [2] is 242 100 milliseconds. Rate-Derived Convergence Time [2] is the 243 preferred benchmark for IGP Route Convergence. This benchmark 244 must always be reported when the 245 Packet Sampling Interval [2] <= 100 milliseconds. 246 If the test equipment does not permit the Packet Sampling 247 Interval to be set as low as 100 msec, then both the 248 Rate-Derived Convergence Time and Loss-Derived Convergence 249 Time [2] must be reported. 251 3.2.6 Offered Load 252 An offered Load of maximum forwarding rate at a fixed packet size 253 is recommended for accurate measurement. The duration of offered 254 load must be greater than the convergence time. The destinations 255 for the offered load must be distributed such that all routes are 256 matched. This enables Full Convergence [2] to be observed. 258 3.2.7 Interface Types 259 All test cases in this methodology document may be executed with 260 any interface type. SONET is recommended and specifically 261 mentioned in the procedures because it can be configured to have 262 no or negligible affect on the measured convergence time. 263 Ethernet (10Mb, 100Mb, 1Gb, and 10Gb) is not preferred since 264 broadcast media are unable to detect loss of host and rely upon 265 IGP Hellos to detect session loss. 267 IGP Data Plane Route Convergence 269 3.3 Reporting Format 270 For each test case, it is recommended that the following reporting 271 format be completed: 273 Parameter Units 274 --------- ----- 275 IGP (ISIS or OSPF) 276 Interface Type (GigE, POS, ATM, etc.) 277 Packet Size bytes 278 IGP Routes number of IGP routes 279 Packet Sampling Interval seconds or milliseconds 280 IGP Timer Values 281 SONET Failure Indication Delay seconds or milliseconds 282 IGP Hello Timer seconds or milliseconds 283 IGP Dead-Interval seconds or milliseconds 284 LSA Generation Delay seconds or milliseconds 285 LSA Flood Packet Pacing seconds or milliseconds 286 LSA Retransmission Packet Pacing seconds or milliseconds 287 SPF Delay seconds or milliseconds 288 Benchmarks 289 Rate-Derived Convergence Time seconds or milliseconds 290 Loss-Derived Convergence Time seconds or milliseconds 291 Restoration Convergence Time seconds or milliseconds 293 4. Test Cases 294 4.1 Convergence Due to Link Failure 295 4.1.1 Convergence Due to Local Interface Failure 296 Objective 297 To obtain the IGP Route Convergence due to a local link 298 failure event at the DUT's Local Interface. 300 Procedure 301 1. Advertise matching IGP routes from Tester to DUT on 302 Preferred Egress Interface [2] and Next-Best Egress Interface 303 [2] using the topology shown in Figure 1. Set the cost of the 304 routes so that the Preferred Egress Interface is the preferred 305 next-hop. 306 2. Send traffic at maximum forwarding rate to destinations 307 matching all IGP routes from Tester to DUT on Ingress Interface 308 [2]. 309 3. Verify traffic routed over Preferred Egress Interface. 310 4. Remove SONET on DUT's Local Interface [2] by performing an 311 administrative shutdown of the interface. 312 5. Measure Rate-Derived Convergence Time [2] as DUT detects the 313 link down event and converges all IGP routes and traffic over 314 the Next-Best Egress Interface. 315 6. Restore SONET on DUT's Local Interface by administratively 316 enabling the interface. 317 7. Measure Restoration Convergence Time [2] as DUT detects the link 318 up event and converges all IGP routes and traffic back to the 319 Preferred Egress Interface. 321 IGP Data Plane Route Convergence 322 Results 323 The measured IGP Convergence time is influenced by the Local 324 SONET indication, SPF delay, SPF Holdtime, SPF Execution 325 Time, Tree Build Time, and Hardware Update Time. 327 4.1.2 Convergence Due to Neighbor Interface Failure 328 Objective 329 To obtain the IGP Route Convergence due to a local link 330 failure event at the Tester's Neighbor Interface. 332 Procedure 333 1. Advertise matching IGP routes from Tester to DUT on 334 Preferred Egress Interface [2] and Next-Best Egress Interface 335 [2] using the topology shown in Figure 1. Set the cost of 336 the routes so that the Preferred Egress Interface is the 337 preferred next-hop. 338 2. Send traffic at maximum forwarding rate to destinations 339 matching all IGP routes from Tester to DUT on Ingress 340 Interface [2]. 341 3. Verify traffic routed over Preferred Egress Interface. 342 4. Remove SONET on Tester's Neighbor Interface [2] connected to 343 DUT' s Preferred Egress Interface. 344 5. Measure Rate-Derived Convergence Time [2] as DUT detects the 345 link down event and converges all IGP routes and traffic over 346 the Next-Best Egress Interface. 347 6. Restore SONET on Tester's Neighbor Interface connected to 348 DUT's Preferred Egress Interface. 349 7. Measure Restoration Convergence Time [2] as DUT detects the 350 link up event and converges all IGP routes and traffic back to 351 the Preferred Egress Interface. 353 Results 354 The measured IGP Convergence time is influenced by the Local 355 SONET indication, SPF delay, SPF Holdtime, SPF Execution 356 Time, Tree Build Time, and Hardware Update Time. 358 4.1.3 Convergence Due to Remote Interface Failure 359 Objective 360 To obtain the IGP Route Convergence due to a Remote 361 Interface failure event. 363 Procedure 364 1. Advertise matching IGP routes from Tester to SUT on 365 Preferred Egress Interface [2] and Next-Best Egress Interface 366 [2] using the topology shown in Figure 2. Set the cost of the 367 routes so that the Preferred Egress Interface is the preferred 368 next-hop. 369 2. Send traffic at maximum forwarding rate to destinations 370 matching all IGP routes from Tester to DUT on Ingress Interface 371 [2]. 372 3. Verify traffic is routed over Preferred Egress Interface. 373 4. Remove SONET on Tester's Neighbor Interface [2] connected to 374 SUT' s Preferred Egress Interface. 376 IGP Data Plane Route Convergence 378 5. Measure Rate-Derived Convergence Time [2] as SUT detects 379 the link down event and converges all IGP routes and traffic 380 over the Next-Best Egress Interface. 381 6. Restore SONET on Tester's Neighbor Interface connected to 382 SUT's Preferred Egress Interface. 383 7. Measure Restoration Convergence Time [2] as SUT detects the 384 link up event and converges all IGP routes and traffic over 385 the Preferred Egress Interface. 387 Results 388 The measured IGP Convergence time is influenced by the 389 SONET failure indication, LSA/LSP Flood Packet Pacing, 390 LSA/LSP Retransmission Packet Pacing, LSA/LSP Generation 391 time, SPF delay, SPF Holdtime, SPF Execution Time, Tree 392 Build Time, and Hardware Update Time. The additional 393 convergence time contributed by LSP Propagation can be 394 obtained by subtracting the Rate-Derived Convergence Time 395 measured in 4.1.2 (Convergence Due to Neighbor Interface 396 Failure) from the Rate-Derived Convergence Time measured in 397 this test case. 399 4.2 Convergence Due to PPP Session Failure 400 Objective 401 To obtain the IGP Route Convergence due to a Local PPP Session 402 failure event. 404 Procedure 405 1. Advertise matching IGP routes from Tester to DUT on 406 Preferred Egress Interface [2] and Next-Best Egress Interface 407 [2] using the topology shown in Figure 1. Set the cost of 408 the routes so that the IGP routes along the Preferred Egress 409 Interface is the preferred next-hop. 410 2. Send traffic at maximum forwarding rate to destinations 411 matching all IGP routes from Tester to DUT on Ingress 412 Interface [2]. 413 3. Verify traffic routed over Preferred Egress Interface. 414 4. Remove PPP session from Tester's Neighbor Interface [2] 415 connected to Preferred Egress Interface. 416 5. Measure Rate-Derived Convergence Time [2] as DUT detects the 417 PPP session down event and converges all IGP routes and 418 traffic over the Next-Best Egress Interface. 419 6. Restore PPP session on DUT's Preferred Egress Interface. 420 7. Measure Restoration Convergence Time [2] as DUT detects the 421 session up event and converges all IGP routes and traffic over 422 the Preferred Egress Interface. 424 Results 425 The measured IGP Convergence time is influenced by the PPP 426 failure indication, SPF delay, SPF Holdtime, SPF Execution 427 Time, Tree Build Time, and Hardware Update Time. 429 IGP Data Plane Route Convergence 431 4.3 Convergence Due to IGP Adjacency Failure 433 Objective 434 To obtain the IGP Route Convergence due to a Local IGP Adjacency 435 failure event. 437 Procedure 438 1. Advertise matching IGP routes from Tester to DUT on 439 Preferred Egress Interface [2] and Next-Best Egress Interface 440 [2] using the topology shown in Figure 1. Set the cost of 441 the routes so that the Preferred Egress Interface is the 442 preferred next-hop. 443 2. Send traffic at maximum forwarding rate to destinations 444 matching all IGP routes from Tester to DUT on Ingress 445 Interface [2]. 446 3. Verify traffic routed over Preferred Egress Interface. 447 4. Remove IGP adjacency from Tester's Neighbor Interface [2] 448 connected to Preferred Egress Interface. 449 5. Measure Rate-Derived Convergence Time [2] as DUT detects the 450 IGP session failure event and converges all IGP routes and 451 traffic over the Next-Best Egress Interface. 452 6. Restore IGP session on DUT's Preferred Egress Interface. 453 7. Measure Restoration Convergence Time [2] as DUT detects the 454 session up event and converges all IGP routes and traffic over 455 the Preferred Egress Interface. 457 Results 458 The measured IGP Convergence time is influenced by the IGP 459 Hello Interval, IGP Dead Interval, SPF delay, SPF Holdtime, 460 SPF Execution Time, Tree Build Time, and Hardware Update 461 Time. 463 4.4 Convergence Due to Route Withdrawal 465 Objective 466 To obtain the IGP Route Convergence due to Route Withdrawal. 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. Tester withdraws all IGP routes from DUT's Local Interface 479 on Preferred Egress Interface. 481 IGP Data Plane Route Convergence 483 6. Re-advertise IGP routes to DUT's Preferred Egress Interface. 484 7. Measure Restoration Convergence Time [2] as DUT converges all 485 IGP routes and traffic over the Preferred Egress Interface. 487 Results 488 The measured IGP Convergence time is the SPF Processing and FIB 489 Update time as influenced by the SPF delay, SPF Holdtime, 490 SPF Execution Time, Tree Build Time, and Hardware Update Time. 492 4.5 Convergence Due to Cost Change 494 Objective 495 To obtain the IGP Route Convergence due to route cost change. 497 Procedure 498 1. Advertise matching IGP routes from Tester to DUT on 499 Preferred Egress Interface [2] and Next-Best Egress Interface 500 [2] using the topology shown in Figure 1. Set the cost of 501 the routes so that the Preferred Egress Interface is the 502 preferred next-hop. 503 2. Send traffic at maximum forwarding rate to destinations 504 matching all IGP routes from Tester to DUT on Ingress 505 Interface [2]. 506 3. Verify traffic routed over Preferred Egress Interface. 507 4. Tester increases cost for all IGP routes at DUT's Preferred 508 Egress Interface so that the Next-Best Egress Interface 509 has lower cost and becomes preferred path. 510 5. Measure Rate-Derived Convergence Time [2] as DUT detects the 511 cost change event and converges all IGP routes and traffic 512 over the Next-Best Egress Interface. 513 6. Re-advertise IGP routes to DUT's Preferred Egress Interface 514 with original lower cost metric. 515 7. Measure Restoration Convergence Time [2] as DUT converges all 516 IGP routes and traffic over the Preferred Egress Interface. 518 Results 519 There should be no measured packet loss for this case. 521 4.6 Convergence Due to ECMP Member Interface Failure 523 Objective 524 To obtain the IGP Route Convergence due to a local link 525 failure event of an ECMP Member. 527 Procedure 528 1. Configure ECMP Set as shown in Figure 3. 529 2. Advertise matching IGP routes from Tester to DUT on 530 each ECMP member. 532 IGP Data Plane Route Convergence 534 3. Send traffic at maximum forwarding rate to destinations 535 matching all IGP routes from Tester to DUT on Ingress 536 Interface [2]. 537 4. Verify traffic routed over all members of ECMP Set. 538 5. Remove SONET on Tester's Neighbor Interface [2] connected to 539 one of the DUT's ECMP member interfaces. 540 6. Measure Rate-Derived Convergence Time [2] as DUT detects the 541 link down event and converges all IGP routes and traffic 542 over the other ECMP members. 543 7. Restore SONET on Tester's Neighbor Interface connected to 544 DUT's ECMP member interface. 545 8. Measure Restoration Convergence Time [2] as DUT detects the 546 link up event and converges IGP routes and some distribution 547 of traffic over the restored ECMP member. 549 Results 550 The measured IGP Convergence time is influenced by the Local 551 SONET indication, Tree Build Time, and Hardware Update Time. 553 4.7 Convergence Due to Parallel Link Interface Failure 555 Objective 556 To obtain the IGP Route Convergence due to a local link 557 failure event for a Member of a Parallel Link. 559 Procedure 560 1. Configure Parallel Link as shown in Figure 4. 561 2. Advertise matching IGP routes from Tester to DUT on 562 each Parallel Link member. 563 3. Send traffic at maximum forwarding rate to destinations 564 matching all IGP routes from Tester to DUT on Ingress 565 Interface [2]. 566 4. Verify traffic routed over all members of Parallel Link. 567 5. Remove SONET on Tester's Neighbor Interface [2] connected to 568 one of the DUT's Parallel Link member interfaces. 569 6. Measure Rate-Derived Convergence Time [2] as DUT detects the 570 link down event and converges all IGP routes and traffic over 571 the other Parallel Link members. 572 7. Restore SONET on Tester's Neighbor Interface connected to 573 DUT's Parallel Link member interface. 574 8. Measure Restoration Convergence Time [2] as DUT detects the 575 link up event and converges IGP routes and some distribution 576 of traffic over the restored Parallel Link member. 578 Results 579 The measured IGP Convergence time is influenced by the Local 580 SONET indication, Tree Build Time, and Hardware Update Time. 582 IGP Data Plane Route Convergence 584 5. Security Considerations 586 Documents of this type do not directly affect the security of 587 the Internet or corporate networks as long as benchmarking 588 is not performed on devices or systems connected to operating 589 networks. 591 6. References 593 [1] Poretsky, S., "Benchmarking Applicability for IGP 594 Convergence", draft-ietf-bmwg-igp-dataplane-conv-app-03, work 595 in progress, July 2004. 597 [2] Poretsky, S., Imhoff, B., "Benchmarking Terminology for IGP 598 Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-03, work 599 in progress, July 2004 601 [3] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual 602 Environments", RFC 1195, December 1990. 604 [4] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 606 7. Author's Address 608 Scott Poretsky 609 Quarry Technologies 610 8 New England Executive Park 611 Burlington, MA 01803 612 USA 614 Phone: + 1 781 395 5090 615 EMail: sporetsky@quarrytech.com 617 Brent Imhoff 618 USA 619 EMail: bimhoff@planetspork.com 620 IGP Data Plane Route Convergence 622 Intellectual Property Statement 624 The IETF takes no position regarding the validity or scope of any Intel- 625 lectual Property Rights or other rights that might be claimed to pertain 626 to the implementation or use of the technology described in this docu- 627 ment or the extent to which any license under such rights might or might 628 not be available; nor does it represent that it has made any independent 629 effort to identify any such rights. Information on the procedures with 630 respect to rights in RFC documents can be found in BCP 78 and BCP 79. 632 Copies of IPR disclosures made to the IETF Secretariat and any 633 assurances of licenses to be made available, or the result of an attempt 634 made to obtain a general license or permission for the use of such 635 proprietary rights by implementers or users of this specification can be 636 obtained from the IETF on-line IPR repository at 637 http://www.ietf.org/ipr. 639 The IETF invites any interested party to bring to its attention any 640 copyrights, patents or patent applications, or other proprietary rights 641 that may cover technology that may be required to implement this stan- 642 dard. Please address the information to the IETF at ietf-ipr@ietf.org. 644 Disclaimer of Warranty 646 This document and the information contained herein are provided on an 647 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 648 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 649 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 650 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMA- 651 TION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 652 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 654 Copyright Statement 656 Copyright (C) The Internet Society (2004). This document is subject to 657 the rights, licenses and restrictions contained in BCP 78, and except as 658 set forth therein, the authors retain all their rights.