idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-term-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 113 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 31 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: ' 6. 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 4 instances of too long lines in the document, the longest one being 11 characters in excess of 72. ** There are 769 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [8], [9], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2004) is 7217 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 1487 looks like a reference -- Missing reference section? '2' on line 1491 looks like a reference -- Missing reference section? '3' on line 1495 looks like a reference -- Missing reference section? '4' on line 1498 looks like a reference -- Missing reference section? '5' on line 1500 looks like a reference -- Missing reference section? '6' on line 1503 looks like a reference -- Missing reference section? '7' on line 1506 looks like a reference -- Missing reference section? '8' on line 1512 looks like a reference -- Missing reference section? '9' on line 1516 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group 2 INTERNET-DRAFT 3 Expires in: July 2004 4 Scott Poretsky 5 Quarry Technologies 7 Brent Imhoff 8 Wiltel Communications 10 January 2004 12 Terminology for Benchmarking 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 41 1. Introduction .................................................2 42 2. Existing definitions .........................................2 43 3. Term definitions..............................................3 44 3.1 Convergence Event.........................................3 45 3.2 Network Convergence.......................................3 46 3.3 Route Convergence.........................................4 47 3.4 Full Convergence..........................................4 48 3.5 Convergence Packet Loss...................................5 49 3.6 Convergence Event Instant.................................5 50 3.7 Convergence Recovery Instant..............................6 51 3.8 Rate-Derived Convergence Time.............................6 52 3.9 Convergence Event Transition..............................7 53 3.10 Convergence Recovery Transition..........................7 54 3.11 Loss-Derived Convergence Time............................8 55 3.12 Sustained Forwarding Convergence Time...................................9 56 IGP Data Plane Route Convergence 58 3.13 Restoration Convergence Time.............................9 59 3.14 Packet Sampling Interval.................................10 60 3.15 Local Interface..........................................10 61 3.16 Neighbor Interface.......................................11 62 3.17 Remote Interface.........................................11 63 3.18 Preferred Egress Interface...............................11 64 3.19 Next-Best Egress Interface...............................12 65 3.20 Stale Forwarding.........................................12 66 4. Security Considerations.......................................12 67 5. References....................................................13 68 6. Author's Address..............................................13 69 7. Full Copyright Statement......................................14 71 1. Introduction 72 This draft describes the terminology for benchmarking IGP Route 73 Convergence. The motivation and applicability for this 74 benchmarking is provided in [1]. The methodology to be used for 75 this benchmarking is described in [2]. The methodology and 76 terminology to be used for benchmarking route convergence can be 77 applied to any link-state IGP such as ISIS [3] and OSPF [4]. The 78 data plane is measured to obtain black-box (externally observable) 79 convergence benchmarking metrics. The purpose of this document is 80 to introduce new terms required to complete execution of the IGP 81 Route Convergence Methodology [2]. 83 An example of Route Convergence as observed and measured from the 84 data plane is shown in Figure 1. The graph in Figure 1 shows 85 Forwarding Rate versus Time. Time 0 on the X-axis is on the far 86 right of the graph. The components of the graph and metrics are 87 defined in the Term Definitions section of this document. 89 Recovery Convergence Event Time = 0sec 90 Maximum ^ ^ ^ 91 Forwarding Rate--> ----\ Packet /--------------- 92 \ Loss /<----Convergence 93 Convergence------->\ / Event Transition 94 Recovery Transition \ / 95 \_____/<------100% Packet Loss 97 X-axis = Time 98 Y-axis = Forwarding Rate 100 Figure 1. Convergence Graph 102 2. Existing definitions 103 For the sake of clarity and continuity this RFC adopts the template 104 for definitions set out in Section 2 of RFC 1242. Definitions are 105 indexed and grouped together in sections for ease of reference. 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 108 this document are to be interpreted as described in RFC 2119. 110 IGP Data Plane Route Convergence 112 3. Term Definitions 114 3.1 Convergence Event 116 Definition: 117 The occurrence of a planned or unplanned action in the network 118 that results in a change to an entry in the route table. 120 Discussion: 121 Convergence Events include link loss, routing protocol session 122 loss, router failure, and better next-hop. 124 Measurement Units: 125 N/A 127 Issues: 128 None 130 See Also: 131 Convergence Packet Loss 132 Convergence Event Instant 134 3.2 Network Convergence 136 Definition: 137 The completion of updating of all routing tables, including the 138 FIB, in all routers throughout the network. 140 Discussion: 141 Network Convergence can be approximated to the sum of Route 142 Convergence for all routers in the network. Network Convergence 143 can be determined by recovery of the forwarding rate to equal 144 the offer load, no stale forwarding, and no blenders[5][6]. 146 Measurement Units: 147 N/A 149 Issues: 150 None 152 See Also: 153 Route Convergence 154 Stale Forwarding 155 IGP Data Plane Route Convergence 157 3.3 Route Convergence 159 Definition: 160 Recovery from a Convergence Event indicated by the DUT 161 forwarding rate equal to the offered load. 163 Discussion: 164 Route Convergence is the action of all components of the router 165 being updated with the most recent route change(s) including the 166 RIB and FIB, along with software and hardware tables. Route 167 Convergence can be observed externally by the rerouting of data 168 Traffic to a new egress interface. 170 Measurement Units: 171 N/A 173 Issues: 174 None 176 See Also: 177 Network Convergence 178 Full Convergence 179 Convergence Event 181 3.4 Full Convergence 182 Definition: 183 Route Convergence for an entire FIB. 185 Discussion: 186 When benchmarking convergence it is useful to measure 187 the time to converge an entire route table. For example, 189 a Convergence Event can be produced for an OSPF table of 5000 190 routes so that the time to converge routes 1 through 5000 191 is measured. 193 Measurement Units: 194 N/A 196 Issues: 197 None 199 See Also: 200 Network Convergence 201 Route Convergence 202 Convergence Event 203 IGP Data Plane Route Convergence 205 3.5 Convergence Packet Loss 207 Definition: 208 The amount of packet loss produced by a Convergence Event 209 until Route Convergence occurs. 211 Discussion: 212 Packet loss can be observed as a reduction of forwarded 213 traffic from the maximum forwarding rate. 215 Measurement Units: 216 number of packets 218 Issues: 219 None 221 See Also: 222 Route Convergence 223 Convergence Event 224 Rate-Derived Convergence Time 225 Loss-Derived Convergence Time 227 3.6 Convergence Event Instant 229 Definition: 230 The time instant that a Convergence Event occurs. 232 Discussion: 233 Convergence Event Instant is observable from the data 234 plane as the precise time that the device under test begins 235 to exhibit packet loss. 237 Measurement Units: 238 hh:mm:ss:uuu 240 Issues: 241 None 243 See Also: 244 Convergence Event 245 Convergence Packet Loss 246 Convergence Recovery Instant 247 IGP Data Plane Route Convergence 249 3.7 Convergence Recovery Instant 250 Definition: 251 The time instant that Full Convergence is measured 252 and maintained for at least an additional five seconds. 254 Discussion: 255 Convergence Recovery Instant is measurable from the data 256 plane as the precise time that the device under test 257 achieves Full Convergence. 259 Measurement Units: 260 hh:mm:ss:uuu 262 Issues: 263 None 265 See Also: 266 Convergence Packet Loss 267 Convergence Event Instant 269 3.8 Rate-Derived Convergence Time 271 Definition: 272 The amount of time for Convergence Packet Loss to 273 persist upon occurrence of a Convergence Event until 274 occurrence of Route Convergence. 276 Discussion: 278 Rate-Derived Convergence Time can be measured as the time 279 difference from the Convergence Event Instant to the 280 Convergence Recovery Instant, as shown with Equation 1. 282 (eq 1) Rate-Derived Convergence Time = 283 Convergence Recovery Instant - Convergence Event Instant. 285 Rate-Derived Convergence Time should be measured at the maximum 286 forwarding rate. Failure to achieve Full Convergence results in 287 a Rate-Derived Convergence Time benchmark of infinity. 289 Measurement Units: 290 seconds/milliseconds 292 Issues: 293 None 295 See Also: 296 Convergence Packet Loss 297 Convergence Recovery Instant 298 Convergence Event Instant 299 Full Convergence 300 IGP Data Plane Route Convergence 302 3.9 Convergence Event Transition 304 Definition: 305 The characteristic of a router in which forwarding rate 306 gradually reduces to zero after a Convergence Event. 308 Discussion: 309 The Convergence Event Transition is best observed for 310 Full Convergence. 312 Measurement Units: 313 seconds/milliseconds 315 Issues: 316 None 318 See Also: 319 Convergence Event 320 Rate-Derived Convergence Time 321 Convergence Packet Loss 322 Convergence Recovery Transition 324 3.10 Convergence Recovery Transition 326 Definition: 327 The characteristic of a router in which forwarding rate 328 gradually increases to equal the offered load. 330 Discussion: 331 The Convergence Recovery Transition is best observed for 332 Full Convergence. 334 Measurement Units: 335 seconds/milliseconds 337 Issues: 338 None 340 See Also: 341 Full Convergence 342 Rate-Derived Convergence Time 343 Convergence Packet Loss 344 Convergence Event Transition 345 IGP Data Plane Route Convergence 347 3.11 Loss-Derived Convergence Time 349 Definition: 350 The amount of time it takes for Route Convergence to 351 to be achieved as calculated from the Convergence Packet 352 Loss. 354 Discussion: 355 Loss-Derived Convergence Time can be calculated from 356 Convergence Packet Loss that occurs due to a Convergence Event 357 and Route Convergence, as shown with Equation 2. 359 (eq 2) Loss-Derived Convergence Time = 360 Convergence Packets Loss / Forwarding Rate 362 NOTE: Units for this measurement are 363 packets / packets/second = seconds 365 Measurement Units: 366 seconds/milliseconds 368 Issues: 369 Loss-Derived Convergence time gives a better than 370 actual result when converging many routes simultaneously. 371 Rate-Derived Convergence Time takes the Convergence Recovery 372 Transition into account, but Loss-Derived Convergence Time 373 ignores the Route Convergence Recovery Transition because 374 it is obtained from the measured Convergence Packet Loss. 375 Ideally, the Convergence Event Transition and Convergence 376 Recovery Transition are instantaneous so that the 377 Rate-Derived Convergence Time = Loss-Derived Convergence Time. 378 However, router implementations are less than ideal. 379 For these reasons the preferred reporting benchmark for IGP 380 Route Convergence is the Rate-Derived Convergence Time. 381 Guidelines for reporting Loss-Derived Convergence Time are 382 provided in [2]. 384 See Also: 385 Route Convergence 386 Convergence Packet Loss 387 Rate-Derived Convergence Time 388 Convergence Event Transition 389 Convergence Recovery Transition 390 IGP Data Plane Route Convergence 392 3.12 Sustained Forwarding Convergence Time 394 Definition: 395 The amount of time for Route Convergence to be achieved for 396 cases in which there is no packet loss. 398 Discussion: 399 Sustained Forwarding Convergence Time is the IGP Route Convergence 400 benchmark to be used for Convergence Events that produce 401 a change in next-hop without packet loss. 403 Measurement Units: 404 seconds/milliseconds 406 Issues: 407 None 409 See Also: 410 Route Convergence 411 Rate-Derived Convergence Time 412 Loss-Derived Convergence Time 414 3.13 Restoration Convergence Time 416 Definition: 417 The amount of time for the router under test to restore 418 traffic to the original outbound port after recovery from 419 a Convergence Event. 421 Discussion: 422 Restoration Convergence Time is the amount of time to 423 Converge back to the original outbound port. This is achieved 424 by recovering from the Convergence Event, such as restoring 425 the failed link. Restoration Convergence Time is measured 426 using the Rate-Derived Convergence Time calculation technique, 427 as provided in Equation 1. It is possible, but not desired 428 to have the Restoration Convergence Time differ from the 429 Rate-Derived Convergence Time. 431 Measurement Units: 432 seconds or milliseconds 434 Issues: 435 None 437 See Also: 438 Convergence Event 439 Rate-Derived Convergence Time 440 IGP Data Plane Route Convergence 442 3.14 Packet Sampling Interval 443 Definition: 444 The rate at which the tester (test equipment) polls to make 445 measurements for arriving packet flows. 447 Discussion: 448 Metrics measured at the Packet Sampling Interval include 449 packets received and Convergence Packet Loss. 451 Measurement Units: 452 seconds or milliseconds 454 Issues: 455 Packet Sampling Interval can influence the Convergence Graph. 456 This is particularly true as implementations achieve Full 457 Convergence in less than 1 second. The Convergence Event 458 Transition and Convergence Recovery Transition can become 459 exaggerated when the Packet Sampling Interval is too long. 460 This will produce a larger than actual Rate-Derived 461 Convergence Time. The recommended value for configuration 462 of the Packet Sampling Interval is provided in [2]. 464 See Also: 465 Convergence Packet Loss 466 Convergence Event Transition 467 Convergence Recovery Transition 469 3.15 Local Interface 470 Definition: 471 An interface on the DUT. 473 Discussion: 474 None 476 Measurement Units: 477 N/A 479 Issues: 480 None 482 See Also: 483 Neighbor Interface 484 Remote interface 485 IGP Data Plane Route Convergence 487 3.16 Neighbor Interface 488 Definition: 489 The interface on the neighbor router or tester that is 490 directly linked to the DUT's Local Interface. 492 Discussion: 493 None 495 Measurement Units: 496 N/A 498 Issues: 499 None 501 See Also: 502 Local Interface 503 Remote interface 505 3.17 Remote Interface 506 Definition: 507 An interface on a neighboring router that is not directly 508 connected to any interface on the DUT. 510 Discussion: 511 None 513 Measurement Units: 514 N/A 516 Issues: 517 None 519 See Also: 520 Local interface 521 Neighbor Interface 523 3.18 Preferred Egress Interface 524 Definition: 525 The outbound interface on DUT to the preferred next-hop. 527 Discussion: 528 Preferred Egress Interface is the egress interface prior to 529 a Convergence Event 531 Measurement Units: 532 N/A 534 Issues: 535 None 537 See Also: 538 Next-Best Egress Interface 539 IGP Data Plane Route Convergence 541 3.19 Next-Best Egress Interface 543 Definition: 544 The outbound interface on DUT to the second-best next-hop. 546 Discussion: 547 Next-Best Egress Interface is the egress interface after 548 a Convergence Event. 550 Measurement Units: 551 N/A 553 Issues: 554 None 556 See Also: 557 Preferred Egress Interface 559 3.20 Stale Forwarding 561 Definition: 562 Forwarding of traffic to route entries that no longer exist 563 or to route entries with next-hops that are no longer preferred. 565 Discussion: 566 Stale Forwarding can be caused by a Convergence Event and is 567 also known as a "black-hole" since it may produce packet loss. 568 Stale Forwarding exists until Network Convergence is achieved. 570 Measurement Units: 571 N/A 573 Issues: 574 None 576 See Also: 577 Network Convergence 579 4. Security Considerations 581 Documents of this type do not directly affect the security of 582 Internet or corporate networks as long as benchmarking 583 is not performed on devices or systems connected to operating 584 networks. 586 IGP Data Plane Route Convergence 588 5. References 590 [1] Poretsky, S., "Benchmarking Applicability for IGP Data Plane 591 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-app-02, 592 work in progress, January 2004. 594 [2] Poretsky, S., "Benchmarking Methodology for IGP Data Plane 595 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-meth-02, 596 work in progress, January 2004. 598 [3] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual 599 Environments", RFC 1195, December 1990. 601 [4] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 603 [5] S. Casner, C. Alaettinoglu, and C. Kuan, "A Fine-Grained View 604 of High Performance Networking", NANOG 22, May 2001. 606 [6] L. Ciavattone, A. Morton, and G. Ramachandran, "Standardized 607 Active Measurements on a Tier 1 IP Backbone", IEEE Communications 608 Magazine, pp90-97, June, 2003. 610 6. Author's Address 612 Scott Poretsky 613 Quarry Technologies 614 8 New England Executive Park 615 Burlington, MA 01803 616 USA 617 Phone: + 1 781 395 5090 618 EMail: sporetsky@quarrytech.com 620 Brent Imhoff 621 WilTel Communications 622 3180 Rider Trail South 623 Bridgeton, MO 63045 USA 624 Phone: +1 314 595 6853 625 EMail: brent.imhoff@wcg.com 626 IGP Data Plane Route Convergence 628 7. Full Copyright Statement 630 Copyright (C) The Internet Society (1998). All Rights 631 Reserved. 633 This document and translations of it may be copied and 634 furnished to others, and derivative works that comment on or 635 otherwise explain it or assist in its implementation may be 636 prepared, copied, published and distributed, in whole or in 637 part, without restriction of any kind, provided that the above 638 copyright notice and this paragraph are included on all such 639 copies and derivative works. However, this document itself may 640 not be modified in any way, such as by removing the copyright 641 notice or references to the Internet Society or other Internet 642 organizations, except as needed for the purpose of developing 643 Internet standards in which case the procedures for copyrights 644 defined in the Internet Standards process must be followed, or 645 as required to translate it into languages other than English. 647 The limited permissions granted above are perpetual and will 648 not be revoked by the Internet Society or its successors or 649 assigns. This document and the information contained herein is 650 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 651 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 652 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 653 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 654 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 655 FOR A PARTICULAR PURPOSE. 657 Network Working Group 658 INTERNET-DRAFT 659 Expires in: July 2004 660 Scott Poretsky 661 Quarry Technologies 663 Brent Imhoff 664 Wiltel Communications 666 January 2004 668 Benchmarking Methodology for 669 IGP Data Plane Route Convergence 671 673 Status of this Memo 675 This document is an Internet-Draft and is in full conformance with 676 all provisions of Section 10 of RFC2026. 678 Internet-Drafts are working documents of the Internet Engineering 679 Task Force (IETF), its areas, and its working groups. Note that 680 other groups may also distribute working documents as Internet- 681 Drafts. 683 Internet-Drafts are draft documents valid for a maximum of six 684 months and may be updated, replaced, or obsoleted by other 685 documents at any time. It is inappropriate to use Internet-Drafts 686 as reference material or to cite them other than as "work in 687 progress." 689 The list of current Internet-Drafts can be accessed at 690 http://www.ietf.org/ietf/1id-abstracts.txt 692 The list of Internet-Draft Shadow Directories can be accessed at 693 http://www.ietf.org/shadow.html. 695 Table of Contents 696 1. Introduction ...............................................2 697 2. Existing definitions .......................................2 698 3. Test Setup..................................................2 699 3.1 Test Topologies............................................2 700 3.2 Test Considerations........................................4 701 3.2.1 IGP Selection............................................4 702 3.2.2 BGP Configuration........................................4 703 3.2.3 IGP Route Scaling........................................5 704 3.2.4 Timers...................................................5 705 3.2.5 Convergence Time Metrics.................................5 706 3.2.6 Offered Load.............................................5 707 3.2.7 Interface Types..........................................5 708 3.3 Reporting Format...........................................6 709 4. Test Cases..................................................6 710 IGP Data Plane Route Convergence 712 4.1 Convergence Due to Link Failure............................6 713 4.1.1 Convergence Due to Local Interface Failure...............6 714 4.1.2 Convergence Due to Neighbor Interface Failure............7 715 4.1.3 Convergence Due to Remote Interface Failure..............7 716 4.2 Convergence Due to PPP Session Failure.....................8 717 4.3 Convergence Due to IGP Adjacency Failure...................9 718 4.4 Convergence Due to Route Withdrawal........................9 719 4.5 Convergence Due to Cost Change.............................10 720 4.6 Convergence Due to ECMP Member Interface Failure...........10 721 4.7 Convergence Due to Parallel Link Interface Failure.........11 722 5. Security Considerations.....................................12 723 6. References..................................................12 724 7. Author's Address............................................12 725 8. Full Copyright Statement....................................13 727 1. Introduction 728 This draft describes the methodology for benchmarking IGP Route 729 Convergence. The applicability of this testing is described in 730 [1] and the new terminology that it introduces is defined in [2]. 731 Service Providers use IGP Convergence time as a key metric of 732 router design and architecture. Customers of Service Providers 733 observe convergence time by packet loss, so IGP Route Convergence 734 is considered a Direct Measure of Quality (DMOQ). The test cases 735 in this document are black-box tests that emulate the network 736 events that cause route convergence, as described in [1]. The 737 black-box test designs benchmark the data plane accounting for 738 all of the factors contributing to convergence time, as discussed 739 in [1]. The methodology (and terminology) for benchmarking route 740 convergence can be applied to any link-state IGP such as ISIS [3] 741 and OSPF [4]. 743 2. Existing definitions 745 For the sake of clarity and continuity this RFC adopts the template 746 for definitions set out in Section 2 of RFC 1242. Definitions are 747 indexed and grouped together in sections for ease of reference. 749 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 750 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 751 this document are to be interpreted as described in RFC 2119. 753 3. Test Setup 754 3.1 Test Topologies 756 Figure 1 shows the test topology to measure IGP Route Convergence due 757 to local Convergence Events such as SONET Link Failure, PPP Session 758 Failure, IGP Adjacency Failure, Route Withdrawal, and route cost 759 change. These test cases discussed in section 4 provide route 760 convergence times that account for the Event Detection time, SPF 761 Processing time, and FIB Update time. These times are measured 762 by observing packet loss in the data plane. 764 IGP Data Plane Route Convergence 766 --------- Ingress Interface --------- 767 | |<------------------------------| | 768 | | | | 769 | | Preferred Egress Interface | | 770 | DUT |------------------------------>|Tester | 771 | | | | 772 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| | 773 | | Next-Best Egress Interface | | 774 --------- --------- 776 Figure 1. IGP Route Convergence Test Topology for Local Changes 778 Figure 2 shows the test topology to measure IGP Route Convergence 779 time due to remote changes in the network topology. These times are 780 measured by observing packet loss in the data plane. In this 781 topology the three routers are considered a System Under Test (SUT). 782 NOTE: All routers in the SUT must be the same model and identically configured. 784 ----- ----------- 785 | | Preferred | | 786 ----- |R2 |---------------------->| | 787 | |-->| | Egress Interface | | 788 | | ----- | | 789 |R1 | | Tester | 790 | | ----- | | 791 | |-->| | Next-Best | | 792 ----- |R3 |~~~~~~~~~~~~~~~~~~~~~~>| | 793 ^ | | Egress Interface | | 794 | ----- ----------- 795 | | 796 |-------------------------------------- 797 Ingress Interface 799 Figure 2. IGP Route Convergence Test Topology 800 for Remote Changes 802 Figure 3 shows the test topology to measure IGP Route Convergence 803 time with members of an ECMP Set. These times are measured by 804 observing packet loss in the data plane. In this topology, the DUT 805 is configured with each Egress interface as a member of an ECMP set 806 and the Tester emulates multiple next-hop routers (emulates one 807 router for each member). 809 IGP Data Plane Route Convergence 811 --------- Ingress Interface --------- 812 | |<--------------------------------| | 813 | | | | 814 | | ECMP Set Interface 1 | | 815 | DUT |-------------------------------->| Tester| 816 | | . | | 817 | | . | | 818 | | . | | 819 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| | 820 | | ECMP Set Interface N | | 821 --------- --------- 823 Figure 3. IGP Route Convergence Test Topology 824 for ECMP Convergence 826 Figure 4 shows the test topology to measure IGP Route Convergence 827 time with members of a Parallel Link. These times are measured by 828 observing packet loss in the data plane. In this topology, the DUT 829 is configured with each Egress interface as a member of a Parallel 830 Link and the Tester emulates the single next-hop router. 832 --------- Ingress Interface --------- 833 | |<--------------------------------| | 834 | | | | 835 | | Parallel Link Interface 1 | | 836 | DUT |-------------------------------->| Tester| 837 | | . | | 838 | | . | | 839 | | . | | 840 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| | 841 | | Parallel Link Interface N | | 842 --------- --------- 844 Figure 4. IGP Route Convergence Test Topology 845 for Parallel Link Convergence 847 3.2 Test Considerations 849 3.2.1 IGP Selection 850 The test cases described in section 4 can be used for ISIS or 851 OSPF. The Route Convergence test methodology for both is 852 identical. The IGP adjacencies are established on the Preferred 853 Egress Interface and Next-Best Egress Interface. 855 3.2.2 BGP Configuration 856 The obtained results for IGP Route Convergence may vary if 857 BGP routes are installed. It is recommended that the IGP 858 Convergence times be benchmarked without BGP routes installed. 860 IGP Data Plane Route Convergence 862 3.2.3 IGP Route Scaling 863 The number of IGP routes will impact the measured IGP Route 864 Convergence because convergence for the entire IGP route table is 865 measured. For results similar to those that would be observed in 866 an operational network it is recommended that the number of 867 installed routes closely approximate that for routers in the 868 network. 870 3.2.4 Timers 871 There are some timers that will impact the measured IGP Convergence 872 time. The following timers should be configured to the minimum value 873 prior to beginning execution of the test cases: 875 Timer Recommended Value 876 ----- ----------------- 877 SONET Failure Indication Delay <10milliseconds 878 IGP Hello Timer 1 second 879 IGP Dead-Interval 3 seconds 880 LSA Generation Delay 0 881 LSA Flood Packet Pacing 0 882 LSA Retransmission Packet Pacing 0 883 SPF Delay 0 885 3.2.5 Convergence Time Metrics 886 The recommended value for the Packet Sampling Interval [2] is 887 100 milliseconds. Rate-Derived Convergence Time [2] is the 888 preferred benchmark for IGP Route Convergence. This benchmark 889 must always be reported when the 890 Packet Sampling Interval [2] <= 100 milliseconds. 891 If the test equipment does not permit the Packet Sampling 892 Interval to be set as low as 100 msec, then both the 893 Rate-Derived Convergence Time and Loss-Derived Convergence 894 Time [2] must be reported. 896 3.2.6 Offered Load 897 An offered Load of maximum forwarding rate at a fixed packet size 898 is recommended for accurate measurement. The duration of offered 899 load must be greater than the convergence time. 901 3.2.7 Interface Types 902 All test cases in this methodology document may be executed with 903 any interface type. SONET is recommended and specifically 904 mentioned in the procedures because it can be configured to have 905 no or negligible affect on the measured convergence time. 906 Ethernet (10Mb, 100Mb, 1Gb, and 10Gb) is not preferred since 907 broadcast media are unable to detect loss of host and rely upon 908 IGP Hellos to detect session loss. 910 IGP Data Plane Route Convergence 912 3.3 Reporting Format 913 For each test case, it is recommended that the following reporting 914 format be completed: 916 Parameter Units 917 --------- ----- 918 IGP (ISIS or OSPF) 919 Interface Type (GigE, POS, ATM, etc.) 920 Packet Size bytes 921 IGP Routes number of IGP routes 922 Packet Sampling Interval seconds or milliseconds 923 IGP Timer Values 924 SONET Failure Indication Delay seconds or milliseconds 925 IGP Hello Timer seconds or milliseconds 926 IGP Dead-Interval seconds or milliseconds 927 LSA Generation Delay seconds or milliseconds 928 LSA Flood Packet Pacing seconds or milliseconds 929 LSA Retransmission Packet Pacing seconds or milliseconds 930 SPF Delay seconds or milliseconds 931 Benchmarks 932 Rate-Derived Convergence Time seconds or milliseconds 933 Loss-Derived Convergence Time seconds or milliseconds 934 Restoration Convergence Time seconds or milliseconds 936 4. Test Cases 937 4.1 Convergence Due to Link Failure 938 4.1.1 Convergence Due to Local Interface Failure 939 Objective 940 To obtain the IGP Route Convergence due to a local link 941 failure event at the DUT's Local Interface. 943 Procedure 944 1. Advertise matching IGP routes from Tester to DUT on 945 Preferred Egress Interface [2] and Next-Best Egress Interface 946 [2] using the topology shown in Figure 1. Set the cost of the 947 routes so that the Preferred Egress Interface is the preferred 948 next-hop. 949 2. Send traffic at maximum forwarding rate to destinations 950 matching all IGP routes from Tester to DUT on Ingress Interface 951 [2]. 952 3. Verify traffic routed over Preferred Egress Interface. 953 4. Remove SONET on DUT's Local Interface [2] by performing an 954 administrative shutdown of the interface. 955 5. Measure Rate-Derived Convergence Time [2] as DUT detects the 956 link down event and converges all IGP routes and traffic over 957 the Next-Best Egress Interface. 958 6. Restore SONET on DUT's Local Interface by administratively 959 enabling the interface. 960 7. Measure Restoration Convergence Time [2] as DUT detects the link 961 up event and converges all IGP routes and traffic back to the 962 Preferred Egress Interface. 964 IGP Data Plane Route Convergence 965 Results 966 The measured IGP Convergence time is influenced by the Local 967 SONET indication, SPF delay, SPF Holdtime, SPF Execution 968 Time, Tree Build Time, and Hardware Update Time. 970 4.1.2 Convergence Due to Neighbor Interface Failure 971 Objective 972 To obtain the IGP Route Convergence due to a local link 973 failure event at the Tester's Neighbor Interface. 975 Procedure 976 1. Advertise matching IGP routes from Tester to DUT on 977 Preferred Egress Interface [2] and Next-Best Egress Interface 978 [2] using the topology shown in Figure 1. Set the cost of 979 the routes so that the Preferred Egress Interface is the 980 preferred next-hop. 981 2. Send traffic at maximum forwarding rate to destinations 982 matching all IGP routes from Tester to DUT on Ingress 983 Interface [2]. 984 3. Verify traffic routed over Preferred Egress Interface. 985 4. Remove SONET on Tester's Neighbor Interface [2] connected to 986 DUT' s Preferred Egress Interface. 987 5. Measure Rate-Derived Convergence Time [2] as DUT detects the 988 link down event and converges all IGP routes and traffic over 989 the Next-Best Egress Interface. 990 6. Restore SONET on Tester's Neighbor Interface connected to 991 DUT's Preferred Egress Interface. 992 7. Measure Restoration Convergence Time [2] as DUT detects the 993 link up event and converges all IGP routes and traffic back to 994 the Preferred Egress Interface. 996 Results 997 The measured IGP Convergence time is influenced by the Local 998 SONET indication, SPF delay, SPF Holdtime, SPF Execution 999 Time, Tree Build Time, and Hardware Update Time. 1001 4.1.3 Convergence Due to Remote Interface Failure 1002 Objective 1003 To obtain the IGP Route Convergence due to a Remote 1004 Interface failure event. 1006 Procedure 1007 1. Advertise matching IGP routes from Tester to SUT on 1008 Preferred Egress Interface [2] and Next-Best Egress Interface 1009 [2] using the topology shown in Figure 2. Set the cost of the 1010 routes so that the Preferred Egress Interface is the preferred 1011 next-hop. 1012 2. Send traffic at maximum forwarding rate to destinations 1013 matching all IGP routes from Tester to DUT on Ingress Interface 1014 [2]. 1015 3. Verify traffic is routed over Preferred Egress Interface. 1016 4. Remove SONET on Tester's Neighbor Interface [2] connected to 1017 SUT' s Preferred Egress Interface. 1019 IGP Data Plane Route Convergence 1021 5. Measure Rate-Derived Convergence Time [2] as SUT detects 1022 the link down event and converges all IGP routes and traffic 1023 over the Next-Best Egress Interface. 1024 6. Restore SONET on Tester's Neighbor Interface connected to 1025 SUT's Preferred Egress Interface. 1026 7. Measure Restoration Convergence Time [2] as SUT detects the 1027 link up event and converges all IGP routes and traffic over 1028 the Preferred Egress Interface. 1030 Results 1031 The measured IGP Convergence time is influenced by the 1032 SONET failure indication, LSA/LSP Flood Packet Pacing, 1033 LSA/LSP Retransmission Packet Pacing, LSA/LSP Generation 1034 time, SPF delay, SPF Holdtime, SPF Execution Time, Tree 1035 Build Time, and Hardware Update Time. The additional 1036 convergence time contributed by LSP Propagation can be 1037 obtained by subtracting the Rate-Derived Convergence Time 1038 measured in 4.1.2 (Convergence Due to Neighbor Interface 1039 Failure) from the Rate-Derived Convergence Time measured in 1040 this test case. 1042 4.2 Convergence Due to PPP Session Failure 1043 Objective 1044 To obtain the IGP Route Convergence due to a Local PPP Session 1045 failure event. 1047 Procedure 1048 1. Advertise matching IGP routes from Tester to DUT on 1049 Preferred Egress Interface [2] and Next-Best Egress Interface 1050 [2] using the topology shown in Figure 1. Set the cost of 1051 the routes so that the IGP routes along the Preferred Egress 1052 Interface is the preferred next-hop. 1053 2. Send traffic at maximum forwarding rate to destinations 1054 matching all IGP routes from Tester to DUT on Ingress 1055 Interface [2]. 1056 3. Verify traffic routed over Preferred Egress Interface. 1057 4. Remove PPP session from Tester's Neighbor Interface [2] 1058 connected to Preferred Egress Interface. 1059 5. Measure Rate-Derived Convergence Time [2] as DUT detects the 1060 PPP session down event and converges all IGP routes and 1061 traffic over the Next-Best Egress Interface. 1062 6. Restore PPP session on DUT's Preferred Egress Interface. 1063 7. Measure Restoration Convergence Time [2] as DUT detects the 1064 session up event and converges all IGP routes and traffic over 1065 the Preferred Egress Interface. 1067 Results 1068 The measured IGP Convergence time is influenced by the PPP 1069 failure indication, SPF delay, SPF Holdtime, SPF Execution 1070 Time, Tree Build Time, and Hardware Update Time. 1072 IGP Data Plane Route Convergence 1074 4.3 Convergence Due to IGP Adjacency Failure 1076 Objective 1077 To obtain the IGP Route Convergence due to a Local IGP Adjacency 1078 failure event. 1080 Procedure 1081 1. Advertise matching IGP routes from Tester to DUT on 1082 Preferred Egress Interface [2] and Next-Best Egress Interface 1083 [2] using the topology shown in Figure 1. Set the cost of 1084 the routes so that the Preferred Egress Interface is the 1085 preferred next-hop. 1086 2. Send traffic at maximum forwarding rate to destinations 1087 matching all IGP routes from Tester to DUT on Ingress 1088 Interface [2]. 1089 3. Verify traffic routed over Preferred Egress Interface. 1090 4. Remove IGP adjacency from Tester's Neighbor Interface [2] 1091 connected to Preferred Egress Interface. 1092 5. Measure Rate-Derived Convergence Time [2] as DUT detects the 1093 IGP session failure event and converges all IGP routes and 1094 traffic over the Next-Best Egress Interface. 1095 6. Restore IGP session on DUT's Preferred Egress Interface. 1096 7. Measure Restoration Convergence Time [2] as DUT detects the 1097 session up event and converges all IGP routes and traffic over 1098 the Preferred Egress Interface. 1100 Results 1101 The measured IGP Convergence time is influenced by the IGP 1102 Hello Interval, IGP Dead Interval, SPF delay, SPF Holdtime, 1103 SPF Execution Time, Tree Build Time, and Hardware Update 1104 Time. 1106 4.4 Convergence Due to Route Withdrawal 1108 Objective 1109 To obtain the IGP Route Convergence due to Route Withdrawal. 1111 Procedure 1112 1. Advertise matching IGP routes from Tester to DUT on 1113 Preferred Egress Interface [2] and Next-Best Egress Interface 1114 [2] using the topology shown in Figure 1. Set the cost of 1115 the routes so that the Preferred Egress Interface is the 1116 preferred next-hop. 1117 2. Send traffic at maximum forwarding rate to destinations 1118 matching all IGP routes from Tester to DUT on Ingress 1119 Interface [2]. 1120 3. Verify traffic routed over Preferred Egress Interface. 1121 4. Tester withdraws all IGP routes from DUT's Local Interface 1122 on Preferred Egress Interface. 1124 IGP Data Plane Route Convergence 1126 6. Re-advertise IGP routes to DUT's Preferred Egress Interface. 1127 7. Measure Restoration Convergence Time [2] as DUT converges all 1128 IGP routes and traffic over the Preferred Egress Interface. 1130 Results 1131 The measured IGP Convergence time is the SPF Processing and FIB 1132 Update time as influenced by the SPF delay, SPF Holdtime, 1133 SPF Execution Time, Tree Build Time, and Hardware Update Time. 1135 4.5 Convergence Due to Cost Change 1137 Objective 1138 To obtain the IGP Route Convergence due to route cost change. 1140 Procedure 1141 1. Advertise matching IGP routes from Tester to DUT on 1142 Preferred Egress Interface [2] and Next-Best Egress Interface 1143 [2] using the topology shown in Figure 1. Set the cost of 1144 the routes so that the Preferred Egress Interface is the 1145 preferred next-hop. 1146 2. Send traffic at maximum forwarding rate to destinations 1147 matching all IGP routes from Tester to DUT on Ingress 1148 Interface [2]. 1149 3. Verify traffic routed over Preferred Egress Interface. 1150 4. Tester increases cost for all IGP routes at DUT's Preferred 1151 Egress Interface so that the Next-Best Egress Interface 1152 has lower cost and becomes preferred path. 1153 5. Measure Rate-Derived Convergence Time [2] as DUT detects the 1154 cost change event and converges all IGP routes and traffic 1155 over the Next-Best Egress Interface. 1156 6. Re-advertise IGP routes to DUT's Preferred Egress Interface 1157 with original lower cost metric. 1158 7. Measure Restoration Convergence Time [2] as DUT converges all 1159 IGP routes and traffic over the Preferred Egress Interface. 1161 Results 1162 There should be no measured packet loss for this case. 1164 4.6 Convergence Due to ECMP Member Interface Failure 1166 Objective 1167 To obtain the IGP Route Convergence due to a local link 1168 failure event of an ECMP Member. 1170 Procedure 1171 1. Configure ECMP Set as shown in Figure 3. 1172 2. Advertise matching IGP routes from Tester to DUT on 1173 each ECMP member. 1175 IGP Data Plane Route Convergence 1177 3. Send traffic at maximum forwarding rate to destinations 1178 matching all IGP routes from Tester to DUT on Ingress 1179 Interface [2]. 1180 4. Verify traffic routed over all members of ECMP Set. 1181 5. Remove SONET on Tester's Neighbor Interface [2] connected to 1182 one of the DUT's ECMP member interfaces. 1183 6. Measure Rate-Derived Convergence Time [2] as DUT detects the 1184 link down event and converges all IGP routes and traffic 1185 over the other ECMP members. 1186 7. Restore SONET on Tester's Neighbor Interface connected to 1187 DUT's ECMP member interface. 1188 8. Measure Restoration Convergence Time [2] as DUT detects the 1189 link up event and converges IGP routes and some distribution 1190 of traffic over the restored ECMP member. 1192 Results 1193 The measured IGP Convergence time is influenced by the Local 1194 SONET indication, Tree Build Time, and Hardware Update Time. 1196 4.7 Convergence Due to Parallel Link Interface Failure 1198 Objective 1199 To obtain the IGP Route Convergence due to a local link 1200 failure event for a Member of a Parallel Link. 1202 Procedure 1203 1. Configure Parallel Link as shown in Figure 4. 1204 2. Advertise matching IGP routes from Tester to DUT on 1205 each Parallel Link member. 1206 3. Send traffic at maximum forwarding rate to destinations 1207 matching all IGP routes from Tester to DUT on Ingress 1208 Interface [2]. 1209 4. Verify traffic routed over all members of Parallel Link. 1210 5. Remove SONET on Tester's Neighbor Interface [2] connected to 1211 one of the DUT's Parallel Link member interfaces. 1212 6. Measure Rate-Derived Convergence Time [2] as DUT detects the 1213 link down event and converges all IGP routes and traffic over 1214 the other Parallel Link members. 1215 7. Restore SONET on Tester's Neighbor Interface connected to 1216 DUT's Parallel Link member interface. 1217 8. Measure Restoration Convergence Time [2] as DUT detects the 1218 link up event and converges IGP routes and some distribution 1219 of traffic over the restored Parallel Link member. 1221 Results 1222 The measured IGP Convergence time is influenced by the Local 1223 SONET indication, Tree Build Time, and Hardware Update Time. 1225 IGP Data Plane Route Convergence 1227 5. Security Considerations 1229 Documents of this type do not directly affect the security of 1230 the Internet or corporate networks as long as benchmarking 1231 is not performed on devices or systems connected to operating 1232 networks. 1234 6. References 1236 [1] Poretsky, S., "Benchmarking Applicability for IGP 1237 Convergence", draft-ietf-bmwg-igp-dataplane-conv-app-02, work 1238 in progress, January 2004. 1240 [2] Poretsky, S., Imhoff, B., "Benchmarking Terminology for IGP 1241 Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-02, work 1242 in progress, January 2004 1244 [3] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual 1245 Environments", RFC 1195, December 1990. 1247 [4] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 1249 7. Author's Address 1251 Scott Poretsky 1252 Quarry Technologies 1253 8 New England Executive Park 1254 Burlington, MA 01803 1255 USA 1257 Phone: + 1 781 395 5090 1258 EMail: sporetsky@quarrytech.com 1260 Brent Imhoff 1261 WilTel Communications 1262 3180 Rider Trail South 1263 Bridgeton, MO 63045 1264 USA 1266 Phone: +1 314 595 6853 1267 EMail: brent.imhoff@wcg.com 1268 IGP Data Plane Route Convergence 1270 8. Full Copyright Statement 1271 Copyright (C) The Internet Society (1998). All Rights 1272 Reserved. 1274 This document and translations of it may be copied and 1275 furnished to others, and derivative works that comment on or 1276 otherwise explain it or assist in its implementation may be 1277 prepared, copied, published and distributed, in whole or in 1278 part, without restriction of any kind, provided that the above 1279 copyright notice and this paragraph are included on all such 1280 copies and derivative works. However, this document itself may 1281 not be modified in any way, such as by removing the copyright 1282 notice or references to the Internet Society or other Internet 1283 organizations, except as needed for the purpose of developing 1284 Internet standards in which case the procedures for copyrights 1285 defined in the Internet Standards process must be followed, or 1286 as required to translate it into languages other than English. 1288 The limited permissions granted above are perpetual and will 1289 not be revoked by the Internet Society or its successors or 1290 assigns. This document and the information contained herein is 1291 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1292 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 1293 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 1294 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 1295 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1296 FOR A PARTICULAR PURPOSE. 1298 Poretsky, Imhoff [Page 13] Network Working Group 1299 INTERNET-DRAFT 1300 Expires in: July 2004 1301 Scott Poretsky 1302 Quarry Technologies 1304 January 2004 1306 Benchmarking Applicability for 1307 IGP Data Plane Route Convergence 1309 1311 Status of this Memo 1313 This document is an Internet-Draft and is in full conformance with 1314 all provisions of Section 10 of RFC2026. 1316 Internet-Drafts are working documents of the Internet Engineering 1317 Task Force (IETF), its areas, and its working groups. Note that 1318 other groups may also distribute working documents as Internet- 1319 Drafts. 1321 Internet-Drafts are draft documents valid for a maximum of six 1322 months and may be updated, replaced, or obsoleted by other 1323 documents at any time. It is inappropriate to use Internet-Drafts 1324 as reference material or to cite them other than as "work in 1325 progress." 1327 The list of current Internet-Drafts can be accessed at 1328 http://www.ietf.org/ietf/1id-abstracts.txt 1330 The list of Internet-Draft Shadow Directories can be accessed at 1331 http://www.ietf.org/shadow.html. 1333 ABSTRACT 1334 This draft describes the applicability of IGP Route Convergence 1335 benchmarking methodology [1] and IGP Route Convergence benchmarking 1336 terminology [2]. The methodology and terminology is to be used 1337 for benchmarking route convergence and can be applied to any 1338 link-state IGP such as ISIS [3] and OSPF [4]. The data plane is 1339 measured to obtain the convergence benchmarking metrics described 1340 in [1]. 1342 Table of Contents 1343 1. Introduction ...............................................2 1344 2. Existing definitions .......................................2 1345 3. Factors for IGP Route Convergence Time......................2 1346 4. Network Events that Cause Route Convergence.................3 1347 5. Use of Data Traffic for IGP Route Convergence Benchmarking..3 1348 6. Security Considerations.....................................4 1349 7. Acknowledgements............................................4 1350 8. References..................................................4 1351 IGP Data Plane Route Convergence 1353 9. Author's Address............................................5 1354 10. Full Copyright Statement...................................5 1356 1. Introduction 1357 IGP Convergence is a critical performance parameter. Customers 1358 of Service Providers use packet loss due to IGP Convergence as a 1359 key metric of their network service quality. Service Providers 1360 use IGP Convergence time as a key metric of router design and 1361 architecture. Fast network convergence can be optimally achieved 1362 through deployment of fast converging routers. The fundamental 1363 basis by which network users and operators benchmark convergence 1364 is packet loss, which is an externally observable event having 1365 direct impact on their application performance. 1367 IGP Route Convergence is a Direct Measure of Quality (DMOQ) when 1368 benchmarking the data plane. For this reason it is important to 1369 develop a standard router benchmarking methodology and terminology 1370 for measuring IGP convergence that uses the data plane as described 1371 in [1] and [2]. This document describes all of the factors that 1372 influence a convergence measurement and how a purely black box test 1373 can be designed to account for all of these factors. This enables 1374 accurate benchmarking and evaluation for route convergence time. 1376 2. Existing definitions 1378 For the sake of clarity and continuity this RFC adopts the template 1379 for definitions set out in Section 2 of RFC 1242. Definitions are 1380 indexed and grouped together in sections for ease of reference. 1382 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 1383 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 1384 this document are to be interpreted as described in RFC 2119. 1386 3. Factors for IGP Route Convergence Time 1388 There are four major categories of factors contributing to the 1389 measured Router IGP Convergence Time. As discussed in [5], [6], 1390 [7], [8] and [9], these categories are Event Detection, SPF 1391 Processing, IGP Advertisement, and FIB Update. These have numerous 1392 components that influence the convergence time. These are listed 1393 as follow: 1395 -Event Detection- 1396 SONET failure indication time 1397 PPP failure indication time 1398 IGP Hello Dead Interval 1400 -SPF Processing- 1401 SPF Delay Time 1402 SPF Hold time 1403 SPF Execution time 1404 IGP Data Plane Route Convergence 1405 -IGP Advertisement- 1406 LSA/LSP Flood Packet Pacing 1407 LSA/LSP Retransmission Packet Pacing 1408 LSA/LSP Generation time 1410 -FIB Update- 1411 Tree Build time 1412 Hardware Update time 1414 The contribution of each of these factors listed above will vary 1415 with each router vendors' architecture and IGP implementation. 1416 It is therefore necessary to design a convergence test that 1417 considers all of these components, not just one or a few of these 1418 components. The additional benefit of designing a test for all 1419 components is that it enables black-box testing in which knowledge 1420 of the routers' internal implementations is not required. It is 1421 then possible to make valid use of the convergence benchmarking 1422 metrics when comparing routers from different vendors. 1424 4. Network Events that Cause Convergence 1426 There are different types of network events that can cause IGP 1427 convergence. These network events are administrative link 1428 removal, unplanned link failure, line card failure, and route 1429 changes such as withdrawal, flap, next-hop change, and cost change. 1430 When benchmarking a router it is important to measure the 1431 convergence time for local and remote occurrence of these network 1432 events. The convergence time measured will vary whether the network 1433 event occurred locally or remotely due to varying combinations of 1434 factors listed in the previous sections. This behavior makes it 1435 possible to design purely black-box tests that isolate 1436 measurements for each of the components of convergence time. 1438 5. Use of Data Plane for IGP Route Convergence Benchmarking 1440 Customers of service providers use packet loss as the metric to 1441 calculate convergence time. Packet loss is an externally observable 1442 event having direct impact on customers' application performance. 1443 For this reason it is important to develop a standard router 1444 benchmarking methodology and terminology that is a Direct Measure 1445 of Quality (DMOQ)for measuring IGP convergence. Such a 1446 methodology uses the data plane as described in [1] and [2]. 1448 An additional benefit of using packet loss for calculation of 1449 IGP Route Convergence time is that it enables black-box tests to 1450 be designed. Data traffic can be offered to the 1451 device under test (DUT), an emulated network event can be forced 1452 to occur, and packet loss can be externally measured to calculate 1453 the convergence time. Knowledge of the DUT architecture and IGP 1454 implementation is not required. There is no need to rely on the 1455 DUT to produce the test results. There is no need to build 1456 intrusive test harnesses for the DUT. 1458 IGP Data Plane Route Convergence 1460 Use of data traffic and measurement of packet loss on the data 1461 plane also enables Route Convergence methodology test cases that 1462 consider the time for the Route Controller to update the FIB on 1463 the forwarding engine of the hardware. A router is not fully 1464 converged until all components are updated and traffic is 1465 rerouted to the correct egress interface. As long as there is 1466 packet loss, routes have not converged. It is possible to send 1467 diverse traffic flows to destinations matching every route in the 1468 FIB so that the time it takes for the router to converge an entire 1469 route table can be benchmarked. 1471 6. Security Considerations 1473 Documents of this type do not directly effect the security of 1474 the Internet or of corporate networks as long as benchmarking 1475 is not performed on devices or systems connected to operating 1476 networks. 1478 7. Acknowledgements 1479 Thanks to Curtis Villamizar for sharing so much of his 1480 knowledge and experience through the years. Also, special 1481 thanks to the many Network Engineers and Network Architects 1482 at the Service Providers who are always eager to discuss 1483 Route Convergence. 1485 8. References 1487 [1] Poretsky, S., "Benchmarking Methodology for IGP Data Plane 1488 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-meth-01, 1489 work in progress, October 2004. 1491 [2] Poretsky, S., "Benchmarking Terminology for IGP Data Plane 1492 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-01, 1493 work in progress, October 2004. 1495 [3] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual 1496 Environments", RFC 1195, December 1990. 1498 [4] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 1500 [5] Villamizar, C., "Convergence and Restoration Techniques for 1501 ISP Interior Routing", NANOG 25, October 2002. 1503 [6] Katz, D., "Why are we Scared of SPF? IGP Scaling and 1504 Stability", NANOG 25, October 2002. 1506 [7] Filsfils, C., "Deploying Tight-SLA Services on an Internet 1507 Backbone: ISIS Fast Convergence and Differentiated Services 1508 Design (tutorial)", NANOG 25, October 2002. 1510 IGP Data Plane Route Convergence 1512 [8] Alaettinoglu, C. and Casner, S., "ISIS Routing on the Qwest 1513 Backbone: a Recipe for Subsecond ISIS Convergence", NANOG 24, 1514 October 2002. 1516 [9] Alaettinoglu, C., Jacobson, V., and Yu, H., "Towards 1517 Millisecond IGP Convergence", NANOG 20, October 2000. 1519 9. Author's Address 1521 Scott Poretsky 1522 Quarry Technologies 1523 8 New England Executive Park 1524 Burlington, MA 01803 1525 USA 1527 Phone: + 1 781 395 5090 1528 EMail: sporetsky@quarrytech.com 1530 10. Full Copyright Statement 1532 Copyright (C) The Internet Society (1998). All Rights 1533 Reserved. 1535 This document and translations of it may be copied and 1536 furnished to others, and derivative works that comment on or 1537 otherwise explain it or assist in its implementation may be 1538 prepared, copied, published and distributed, in whole or in 1539 part, without restriction of any kind, provided that the above 1540 copyright notice and this paragraph are included on all such 1541 copies and derivative works. However, this document itself may 1542 not be modified in any way, such as by removing the copyright 1543 notice or references to the Internet Society or other Internet 1544 organizations, except as needed for the purpose of developing 1545 Internet standards in which case the procedures for copyrights 1546 defined in the Internet Standards process must be followed, or 1547 as required to translate it into languages other than English. 1549 The limited permissions granted above are perpetual and will 1550 not be revoked by the Internet Society or its successors or 1551 assigns. This document and the information contained herein is 1552 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1553 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 1554 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 1555 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 1556 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1557 FOR A PARTICULAR PURPOSE.