idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-term-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (March 08, 2009) is 5525 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-23) exists of draft-ietf-bmwg-igp-dataplane-conv-meth-17 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Poretsky 2 Internet Draft Allot Communications 3 Expires: September 08, 2009 4 Intended Status: Informational Brent Imhoff 5 Juniper Networks 7 March 08, 2009 9 Terminology for Benchmarking 10 Link-State IGP Data Plane Route Convergence 12 14 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 8, 2009. 35 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 ABSTRACT 46 This document describes the terminology for benchmarking Interior 47 Gateway Protocol (IGP) Route Convergence. The terminology is to 48 be used for benchmarking IGP convergence time through externally 49 observable (black box) data plane measurements. The terminology 50 can be applied to any link-state IGP, such as ISIS and OSPF. 52 Link-State IGP Data Plane Route Convergence 54 Table of Contents 55 1. Introduction and Scope........................................3 56 2. Existing Definitions .........................................4 57 3. Term Definitions..............................................4 58 3.1 States 59 3.1.1 Route Convergence....................................4 60 3.1.2 Full Convergence.....................................5 61 3.1.3 Network Convergence..................................5 62 3.1.4 Route-Specific Convergence...........................6 63 3.1.5 Stale Forwarding.....................................6 64 3.2 Events 65 3.2.1 Convergence Event....................................7 66 3.2.2 Convergence Event Trigger............................7 67 3.2.3 Convergence Event Instant............................8 68 3.2.4 Convergence Recovery Instant.........................8 69 3.2.5 First Route Convergence Instant......................9 70 3.2.6 Convergence Event Transition.........................9 71 3.2.7 Convergence Recovery Transition......................10 72 3.2.8 Nested Convergence Events............................10 73 3.3 Interfaces 74 3.3.1 Local Interface......................................11 75 3.3.2 Neighbor Interface...................................11 76 3.3.3 Remote Interface.....................................11 77 3.3.4 Preferred Egress Interface...........................12 78 3.3.5 Next-Best Egress Interface...........................12 79 3.4 Benchmarking Method 80 3.4.1 Packet Loss..........................................13 81 3.4.2 Convergence Packet Loss..............................13 82 3.4.3 Rate-Derived Convergence Method......................14 83 3.4.4 Loss-Derived Convergence Method......................14 84 3.4.5 Packet Sampling Interval.............................15 85 3.5 Benchmarks 86 3.5.1 Full Convergence Time................................17 87 3.5.2 First Route Convergence Time.........................17 88 3.5.3 Route-Specific Convergence Time......................17 89 3.5.4 Sustained Convergence Validation Time................18 90 3.5.5 Reversion Convergence Time...........................19 91 4. IANA Considerations...........................................19 92 5. Security Considerations.......................................19 93 6. Acknowledgements..............................................20 94 7. References....................................................20 95 8. Author's Address..............................................21 96 Link-State IGP Data Plane Route Convergence 98 1. Introduction and Scope 100 This draft describes the terminology for benchmarking Interior 101 Gateway Protocol (IGP) Route Convergence. The motivation and 102 applicability for this benchmarking is provided in [Po07a]. The 103 methodology to be used for this benchmarking is described in [Po07m]. 104 The purpose of this document is to introduce new terms required to 105 complete execution of the IGP Route Convergence Methodology [Po07m]. 106 These terms apply to IPv4 and IPv6 traffic and IGPs. 108 Convergence times are measured at the Tester on the data plane by 109 observing packet loss through the DUT. The methodology and 110 terminology to be used for benchmarking Route Convergence can be 111 applied to any link-state IGP such as ISIS [Ca90] and OSPF [Mo98]. 112 The data plane is measured to obtain black-box (externally 113 observable) convergence benchmarking metrics. When there is no 114 packer loss observed in the data plane, the convergence time 115 SHALL be reported as zero. 117 An example of Route Convergence as observed and measured from the 118 data plane is shown in Figure 1. The graph in Figure 1 shows 119 Forwarding Rate versus Time. Time 0 on the X-axis is on the far 120 right of the graph. The Offered Load to the ingress interface of 121 the DUT SHOULD equal the measured Throughput [Ba99][Ma98] of the DUT 122 and the Forwarding Rate [Ma98] and Convergence Packet Loss is 123 measured at the Preferred and Next-Best Egress interfaces of the DUT 124 befire, during, and after a Convergence Event Trigger. These 125 components of the graph are defined in the Term Definitions section. 127 Full Convergence-> Convergence Convergence 128 Recovery Event Event Time= 129 Instant Instant Trigger 0sec 130 Forwarding Rate= ^ ^ ^ ^ Offered Load= 131 Offered Load --> ------\ Packet /----------- <--Max Throughput 132 \ Loss /<----Convergence 133 Convergence------->\ / Event Transition 134 Recovery Transition \ / 135 \_____/<------Maximum Packet Loss 136 ^ 137 First Route 138 Convergence Instant 140 Y-axis = Forwarding Rate 141 X-axis = Time (increases right to left to match commercial test 142 equipment displays) 144 Figure 1. Convergence Graph 146 Link-State IGP Data Plane Route Convergence 148 2. Existing Definitions 149 This document uses existing terminology defined in other BMWG 150 work. Examples include, but are not limited to: 152 Latency [Ref.[Ba91], section 3.8] 153 Frame Loss Rate [Ref.[Ba91], section 3.6] 154 Throughput [Ref.[Ba91], section 3.17] 155 Device Under Test (DUT) [Ref.[Ma98], section 3.1.1] 156 System Under Test (SUT) [Ref.[Ma98], section 3.1.2] 157 Out-of-order Packet [Ref.[Po06], section 3.3.2] 158 Duplicate Packet [Ref.[Po06], section 3.3.3] 159 Packet Reordering [Ref.[Mo06], section 3.3] 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in BCP 14, RFC 2119 164 [Br97]. RFC 2119 defines the use of these key words to help make the 165 intent of standards track documents as clear as possible. While this 166 document uses these keywords, this document is not a standards track 167 document. 169 3. Term Definitions 171 3.1 States 172 3.1.1 Route Convergence 174 Definition: 175 The action to update all components of the router with the 176 most recent route change(s) including the Routing 177 Information Base (RIB) and Forwarding Information Base (FIB), 178 along with software and hardware tables, such that forwarding 179 is successful for one or more route entries. 181 Discussion: 182 Route Convergence MUST occur after a Convergence Event. 183 Route Convergence can be observed externally by the rerouting 184 of data traffic to the Next-best Egress Interface. Also, 185 completion of Route Convergence may or may not be sustained 186 over time. 188 Measurement Units: N/A 190 Issues: None 192 See Also: 193 Network Convergence 194 Full Convergence 195 Convergence Event 196 Link-State IGP Data Plane Route Convergence 198 3.1.2 Full Convergence 200 Definition: 201 Route Convergence for an entire FIB in which complete recovery 202 from the Convergence Event is indicated by the DUT throughput 203 equal to the offered load. 205 Discussion: 206 When benchmarking convergence, it is useful to measure 207 the time to converge an entire FIB. For example, 208 a Convergence Event can be produced for an OSPF table of 209 5000 routes so that the time to converge routes 1 through 210 5000 is measured. Completion of Full Convergence is externally 211 observable from the data plane when the Throughput of the data 212 plane traffic on the Next-Best Egress Interface equals the 213 offered load. 215 Full Convergence MAY be measured using Rate-Derived Convergence 216 Method or calculated using Loss-Derived Convergence Method. 217 Full Convergence may or may not be sustained over time. The 218 Sustained Convergence Validation Time MUST be applied. 220 Measurement Units: N/A 222 Issues: None 224 See Also: 225 Network Convergence 226 Route Convergence 227 Convergence Event 229 3.1.3 Network Convergence 231 Definition: 232 The process of updating of all routing tables, including 233 distributed FIBs, in all routers throughout the network. 235 Discussion: 236 Network Convergence requires completion of all Route 237 Convergence operations for all routers in the network following 238 a Convergence Event. Completion of Network Convergence can be 239 observed by recovery of System Under Test (SUT) Throughput to 240 equal the offered load, with no Stale Forwarding, and no 241 Blenders [Ca01][Ci03]. 243 Measurement Units: N/A 245 Issues: None 246 Link-State IGP Data Plane Route Convergence 248 See Also: 249 Route Convergence 250 Stale Forwarding 252 3.1.4 Route-Specific Convergence 253 Definition: 254 Route Convergence for one or more specific route entries in 255 the FIB in which recovery from the Convergence Event is 256 indicated when data-plane traffic for the flow [Po06] matching 257 that route entry(ies) is routed to the Next-Best Egress 258 Interface. 260 Discussion: 261 When benchmarking convergence, it is sometimes useful to 262 measure the time to converge a single flow [Po06] or group of 263 flows to benchmark convergence time for one or a few route 264 entries in the FIB instead of the entire FIB. Route-Specific 265 Convergence of a flow is externally observable from the data 266 plane when the data plane traffic for that flow is routed to 267 the Next-Best Egress Interface. 269 Measurement Units: N/A 271 Issues: None 273 See Also: 274 Full Convergence 275 Route Convergence 276 Convergence Event 278 3.1.5 Stale Forwarding 279 Definition: 280 Forwarding of traffic to route entries that no longer exist 281 or to route entries with next-hops that are no longer preferred. 283 Discussion: 284 Stale Forwarding can be caused by a Convergence Event and can 285 manifest as a "black-hole" or microloop that produces packet 286 loss. Stale Forwarding can exist until Network Convergence is 287 completed. Stale Forwarding cannot be observed with a single 288 DUT. 290 Measurement Units: N/A 292 Issues: None 294 See Also: 295 Network Convergence 296 Link-State IGP Data Plane Route Convergence 298 3.2 Events 300 3.2.1 Convergence Event 302 Definition: 303 The occurrence of a planned or unplanned event in the network 304 that results in a change in the egress interface of the Device 305 Under Test (DUT) for routed packets. 307 Discussion: 308 Convergence Events include link loss, routing protocol session 309 loss, router failure, configuration change, and better next-hop 310 learned via a routing protocol. 312 Measurement Units: 313 N/A 315 Issues: 316 None 318 See Also: 319 Convergence Packet Loss 320 Convergence Event Instant 322 3.2.2 Convergence Event Trigger 324 Definition: 325 An action taken by the Tester to produce a Convergence Event. 327 Discussion: 328 The Convergence Event Trigger is introduced by the Tester and 329 may be indicated by link loss, routing protocol session loss, 330 router failure, configuration change, or a better next-hop 331 learned via a routing protocol introduced by the Tester. 333 Measurement Units: 334 N/A 336 Issues: 337 None 339 See Also: 340 Convergence Event 341 Convergence Packet Loss 342 Convergence Recovery Instant 343 Link-State IGP Data Plane Route Convergence 345 3.2.3 Convergence Event Instant 347 Definition: 348 The time instant that a Convergence Event becomes observable in 349 the data plane. 351 Discussion: 352 Convergence Event Instant is observable from the data 353 plane as the precise time that the device under test begins 354 to exhibit packet loss. The Convergence Event Instant is 355 produced by the Convergence Event Trigger. The Convergence 356 Event Instant always occurs concurrent or subsequent to the 357 Tester introducing the Convergence Event Trigger. 359 Measurement Units: 360 hh:mm:ss:nnn:uuu, 361 where 'nnn' is milliseconds and 'uuu' is microseconds. 363 Issues: None 365 See Also: 366 Convergence Event 367 Convergence Packet Loss 368 Convergence Recovery Instant 370 3.2.4 Convergence Recovery Instant 372 Definition: 373 The time instant that Full Convergence completion is 374 observed. 376 Discussion: 377 Convergence Recovery Instant is measurable from the data 378 plane as the precise time that the device under test completes 379 Full Convergence. The Convergence Recovery Instant MUST be 380 maintained for an interval of duration equal to the Sustained 381 Convergence Validation Time. 383 Measurement Units: 384 hh:mm:ss:nnn:uuu, 385 where 'nnn' is milliseconds and 'uuu' is microseconds. 387 Issues: 388 None 390 See Also: 391 Sustained Convergence Validation Time 392 Convergence Packet Loss 393 Convergence Event Instant 394 Link-State IGP Data Plane Route Convergence 396 3.2.5 First Route Convergence Instant 397 Definition: 398 The time instant a first route entry has converged 399 following a Convergence Event, as observed by receipt of 400 the first packet from the Next-Best Egress Interface. 402 Discussion: 403 The First Route Convergence Instant is an indication that the 404 process to achieve Full Convergence has begun. Any route may 405 be the first to converge for First Route Convergence Instant. 406 Measurement on the data-plane enables the First Route 407 Convergence Instant to be observed without any white-box 408 information from the DUT. 410 Measurement Units: 411 hh:mm:ss:nnn:uuu, 412 where 'nnn' is milliseconds and 'uuu' is microseconds. 414 Issues: 415 None 417 See Also: 418 Route Convergence 419 Full Convergence 420 Stale Forwarding 422 3.2.6 Convergence Event Transition 423 Definition: 424 A time interval observed following a Convergence Event in which 425 Throughput gradually reduces to a minimum value. 427 Discussion: 428 The Convergence Event Transition is best observed for Full 429 Convergence. The egress packet rate observed during a 430 Convergence Event Transition may not decrease linearly and may 431 not decrease to zero. Both the offered load and the Packet 432 Sampling Interval influence the observations of the Convergence 433 Event Transition. For example, it is possible that if the 434 Convergence Event were to cause the Throughput [Ba91] to drop 435 to zero then this may not be observed if the Packet Sampling 436 Interval is set too high. This is further discussed with the 437 term "Packet Sampling Interval". 439 Measurement Units: 440 seconds 442 Issues: None 443 Link-State IGP Data Plane Route Convergence 445 See Also: 446 Convergence Event 447 Full Convergence 448 Packet Sampling Interval 450 3.2.7 Convergence Recovery Transition 452 Definition: 453 The characteristic of the DUT in which Throughput gradually 454 increases to equal the offered load. 456 Discussion: 457 The Convergence Recovery Transition is best observed for 458 Full Convergence. The egress packet rate observed during 459 a Convergence Recovery Transition may not increase linearly. 460 Both the offered load and the Packet Sampling Interval 461 influence the observations of the Convergence Recovery 462 Transition. This is further discussed with the term 463 "Packet Sampling Interval". 465 Measurement Units: 466 seconds 468 Issues: None 470 See Also: 471 Full Convergence 472 Packet Sampling Interval 474 3.2.8 Nested Convergence Events 476 Definition: 477 The occurrence of a Convergence Event while the route 478 table is converging from a prior Convergence Event. 480 Discussion: 481 The Convergence Events for a Nested Convergence Event 482 MUST occur with different neighbors. A common 483 observation from a Nested Convergence Event will be 484 the withdrawal of routes from one neighbor while the 485 routes of another neighbor are being installed. 487 Measurement Units: N/A 489 Issues: None 491 See Also: 492 Convergence Event 493 Link-State IGP Data Plane Route Convergence 495 3.3 Interfaces 497 3.3.1 Local Interface 499 Definition: 500 An interface on the DUT. 502 Discussion: 503 A failure of the Local Interface indicates that the failure 504 occurred directly on the DUT. 506 Measurement Units: N/A 508 Issues: None 510 See Also: 511 Neighbor Interface 512 Remote Interface 514 3.3.2 Neighbor Interface 516 Definition: 517 The interface on the neighbor router or tester that is 518 directly linked to the DUT's Local Interface. 520 Discussion: 521 A failure of a Neighbor Interface indicates that a 522 failure occurred on a neighbor router's interface that 523 directly links the neighbor router to the DUT. 525 Measurement Units: N/A 527 Issues: None 529 See Also: 530 Local Interface 531 Remote Interface 533 3.3.3 Remote Interface 535 Definition: 536 An interface on a neighboring router that is not directly 537 connected to any interface on the DUT. 539 Discussion: 540 A failure of a Remote Interface indicates that the failure 541 occurred on a neighbor router's interface that is not 542 directly connected to the DUT. 544 Link-State IGP Data Plane Route Convergence 546 Measurement Units: 547 N/A 549 Issues: 550 None 552 See Also: 553 Local Interface 554 Neighbor Interface 556 3.3.4 Preferred Egress Interface 558 Definition: 559 The outbound interface from the DUT for traffic routed to the 560 preferred next-hop. 562 Discussion: 563 The Preferred Egress Interface is the egress interface prior 564 to a Convergence Event. 566 Measurement Units: 567 N/A 569 Issues: 570 None 572 See Also: 573 Next-Best Egress Interface 575 3.3.5 Next-Best Egress Interface 577 Definition: 578 The outbound interface from the DUT for traffic routed to the 579 second-best next-hop. It is the same media type and link speed 580 as the Preferred Egress Interface 582 Discussion: 583 The Next-Best Egress Interface becomes the egress interface 584 after a Convergence Event. 586 Measurement Units: 587 N/A 589 Issues: None 591 See Also: 592 Preferred Egress Interface 593 Link-State IGP Data Plane Route Convergence 594 3.4 Benchmarking Methods 596 3.4.1 Packet Loss 598 Definition: 599 The number of packets that should have been forwarded 600 by a DUT under a constant offered load that were 601 not forwarded due to lack of resources. 603 Discussion: 604 Packet Loss is a modified version of the term "Frame Loss Rate" 605 as defined in [Ba91]. The term "Frame Loss" is intended for 606 Ethernet Frames while "Packet Loss" is intended for IP packets. 607 Packet Loss can be measured as a reduction in forwarded traffic 608 from the Throughput [Ba91] of the DUT. 610 Measurement units: 611 Number of offered packets that are not forwarded. 613 Issues: None 615 See Also: 616 Convergence Packet Loss 618 3.4.2 Convergence Packet Loss 620 Definition: 621 The number of packets lost due to a Convergence Event 622 until Full Convergence completes. 624 Discussion: 625 Convergence Packet Loss includes packets that were lost and 626 packets that were delayed due to buffering. The Convergence 627 Packet Loss observed in a Packet Sampling Interval may or may 628 not be equal to the number of packets in the offered load 629 during the interval following a Convergence Event (see Figure 630 1). 632 Measurement Units: 633 number of packets 635 Issues: None 637 See Also: 638 Packet Loss 639 Route Convergence 640 Convergence Event 641 Packet Sampling Interval 642 Link-State IGP Data Plane Route Convergence 644 3.4.3 Rate-Derived Convergence Method 645 Definition: 646 The method to calculate convergence time benchmarks from the 647 amount of time that Convergence Packet Loss persists upon 648 occurrence of a Convergence Event. 650 Rate-Derived Convergence Method can be calculated as the time 651 difference from the Convergence Event Instant to the 652 Convergence Recovery Instant, as shown with Equation 1. 654 (Equation 1) 655 Rate-Derived Convergence Method = 656 Convergence Recovery Instant - Convergence Event Instant. 658 Discussion: 659 It is RECOMMENDED that the Rate-Derived Convergence Method be 660 measured when benchmarking convergence times. The Rate-Derived 661 Convergence Method SHOULD be measured with an Offered Load at 662 the Throughput of the DUT. At least one packet per route 663 in the FIB for all routes in the FIB MUST be offered to the DUT 664 within the Packet Sampling Interval. 666 It is possible to measure no packet loss, which results in a 667 Rate-Derived Convergence Time benchmark of zero. Failure to 668 achieve Full Convergence results in a Rate-Derived Convergence 669 Time benchmark of infinity. 671 Measurement Units: 672 seconds 674 Issues: None 676 See Also: 677 Convergence Packet Loss 678 Convergence Recovery Instant 679 Convergence Event Instant 680 Full Convergence 682 3.4.4 Loss-Derived Convergence Method 683 Definition: 684 The method to calculate convergence time benchmarks from the 685 amount of Convergence Packet Loss. Loss-Derived Convergence 686 Method can be calculated from Convergence Packet Loss as shown 687 with Equation 2. 689 Equation 2 - 690 Loss-Derived Convergence Method = 691 Convergence Packets Loss / Offered Load 692 where units are packets / packets/second = seconds 693 Link-State IGP Data Plane Route Convergence 695 Discussion: 696 Ideally, the Convergence Event Transition and Convergence 697 Recovery Transition are instantaneous so that the Rate-Derived 698 Convergence Method = Loss-Derived Convergence Method. However, 699 router implementations are less than ideal. Loss-Derived 700 Convergence Method gives a better than actual result when 701 converging many routes simultaneously because it ignores the 702 transitions. The Rate-Derived Convergence Method takes the 703 transitions into account. 705 Equation 2 calculates the average convergence time over all 706 routes to which packets have been sent. The average convergence 707 time is often lower than the maximum convergence time 708 over all routes, so it can produce a result that is faster than 709 the actual convergence time.. Therefore, Loss-Derived 710 Convergence Method is not the preferred method to measure 711 convergence benchmarks. For these reasons the RECOMMENDED 712 method to obtain a benchmark metric for convergence time is the 713 Rate-Derived Convergence Method. 715 Measurement Units: 716 seconds 718 Issues: None 720 See Also: 721 Convergence Packet Loss 722 Rate-Derived Convergence Method 723 Route-Specific Convergence 724 Convergence Event Transition 725 Convergence Recovery Transition 727 3.4.5 Packet Sampling Interval 728 Definition: 729 The interval at which the tester (test equipment) polls to make 730 measurements for arriving packet flows. 732 Discussion: 733 At least one packet per route in the FIB for all routes in the 734 FIB MUST be offered to the DUT within the Packet Sampling 735 Interval. Metrics measured at the Packet Sampling Interval 736 MUST include Forwarding Rate and Convergence Packet Loss. 738 Packet Sampling Interval can influence the Convergence Graph. 739 This is particularly true when implementations complete Full 740 Convergence in less time than the Packet Sampling Interval. The 741 Convergence Event Transition and Convergence Recovery Transition 742 Link-State IGP Data Plane Route Convergence 744 can become exaggerated when the Packet Sampling Interval is too 745 long. In this condition, the Rate-Derived Convergence Method 746 may produce a larger than actual convergence time. In such 747 cases the Loss-Derived Convergence Method may produce a more 748 accurate result. The recommended value for configuration of 749 the Packet Sampling Interval is provided in [Po07m]. 751 Measurement Units: seconds 753 Issues: None 755 See Also: 756 Convergence Packet Loss 757 Convergence Event Transition 758 Convergence Recovery Transition 760 3.5 Benchmarks 762 3.5.1 Full Convergence Time 764 Definition: 765 The amount of time it takes for Full Convergence to occur. 767 Discussion: 768 Full Convergence Time can be determined using the Rate-Derived 769 Convergence Method or Loss-Derived Convergence Method. The 770 Rate-Derived Convergence Method is RECOMMENDED. When 771 measuring Route-Specific Convergence Time, there may be 772 conditions in which the maximum Route Specific Convergence Time 773 can be reported as the Full Convergence Time. Full Convergence 774 may or may not be sustained over time. The Sustained 775 Convergence Validation Time MUST be applied. 777 Measurement Units: 778 seconds 780 Issues: None 782 See Also: 783 Full Convergence 784 Rate-Derived Convergence Method 785 Loss-Derived Convergence Method 787 3.5.2 First Route Convergence Time 789 Definition: 790 The amount of time for Convergence Packet Loss until the 791 convergence of a first route entry on the Next-Best Egress 792 Interface, as indicated by the First Route Convergence 793 Instant. 795 Link-State IGP Data Plane Route Convergence 797 Discussion: 798 The First Route Convergence Time benchmarking metric can be 799 measured when benchmarking either Full Convergence or 800 Route-Specific Convergence. When benchmarking Full Convergence, 801 First Route Convergence Time can be measured as the time 802 difference from the Convergence Event Instant and the First 803 Route Convergence Instant, as shown with Equation 4a. 805 (Equation 4a) 806 First Route Convergence Time = 807 First Route Convergence Instant - Convergence Event Instant 809 First Route Convergence Time should be measured at the maximum 810 Throughput of the DUT. At least one packet per route in the FIB 811 for all routes in the FIB MUST be offered to the DUT within the 812 Packet Sampling Interval. Failure to achieve the First Route 813 Convergence Instant results in a First Route Convergence Time 814 benchmark of infinity. 816 Measurement Units: 817 seconds 819 Issues: None 821 See Also: 822 Convergence Packet Loss 823 First Route Convergence Instant 825 3.5.3 Route-Specific Convergence Time 827 Definition: 828 The amount of time it takes for Route-Specific Convergence to 829 be completed as calculated from the amount of Convergence 830 Packet Loss for the flow associated to a specific route. 832 Route-Specific Convergence Time can be calculated from 833 Convergence Packet Loss as shown with Equation 3. 835 (Equation 3) Route-Specific Convergence Time = 836 Convergence Packets Loss / Offered Load 837 where units are packets / packets/second = seconds 838 Link-State IGP Data Plane Route Convergence 840 Discussion: 841 It is possible to provide an offered load that has flows 842 matching every route entry in the FIB and benchmarking 843 Route-Specific Convergence Time for all route entries. The 844 number of flows that can be measured is dependent upon the flow 845 measurement capabilities of the Tester. When benchmarking 846 Route-Specific Convergence, Convergence Packet Loss is measured 847 for specific flow(s) and Equation 3 is applied for each flow. 848 Each flow has a single destination address matching a different 849 route entry. The fastest measurable convergence time is equal 850 to the time between two consecutive packets of a flow offered 851 by the Tester. In practice, the fastest measurable 852 convergence time is the Packet Sampling Interval of the Tester. 854 The Route-Specific Convergence Time benchmarks enable minimum, 855 maximum, average, and median convergence time measurements to be 856 reported by comparing the results for the different route 857 entries. It also enables benchmarking of convergence time when 858 configuring a priority value for route entry(ies). Since 859 multiple Route-Specific Convergence Times can be measured it is 860 possible to have an array of results. The format for reporting 861 Route-Specific Convergence Time is provided in [Po07m]. 863 Measurement Units: 864 seconds 866 Issues: 867 None 869 See Also: 870 Convergence Event 871 Convergence Packet Loss 872 Route-Specific Convergence 874 3.5.4 Sustained Convergence Validation Time 875 Definition: 876 The amount of time for which the completion of Full 877 Convergence is maintained without additional packet loss. 879 Discussion: 880 The purpose of the Sustained Convergence Validation Time is to 881 produce Convergence benchmarks protected against fluctuation 882 in Throughput after the completion of Full Convergence is 883 observed. The RECOMMENDED Sustained Convergence Validation 884 Time to be used is 5 seconds. The BMWG selected 5 seconds 885 based upon RFC 2544 [Ba99] which recommends waiting 2 seconds 886 for residual frames to arrive and 5 seconds for DUT 887 restabilization. 889 Link-State IGP Data Plane Route Convergence 891 Measurement Units: 892 seconds 894 Issues: None 896 See Also: 897 Full Convergence 898 Convergence Recovery Instant 900 3.5.5 Reversion Convergence Time 902 Definition: 903 The amount of time for the DUT to complete Full Convergence 904 to the Preferred Egress Interface, instead of the Next-Best 905 Egress Interface, upon recovery from a Convergence Event. 907 Discussion: 908 Reversion Convergence Time is the amount of time for Full 909 Convergence to the original egress interface. This is 910 achieved by recovering from the Convergence Event, such as 911 restoring the failed link. Reversion Convergence Time 912 can be measured using the Rate-Derived Convergence Method 913 or Loss-Derived Convergence Method. The Rate-Derived 914 Convergence Method is RECOMMENDED. It is possible to have 915 the Reversion Convergence Time differ from the Full 916 Convergence Time. 918 Measurement Units: seconds 920 Issues: None 922 See Also: 923 Preferred Egress Interface 924 Convergence Event 925 Rate-Derived Convergence Method 927 4. IANA Considerations 929 This document requires no IANA considerations. 931 5. Security Considerations 933 Documents of this type do not directly affect the security of 934 Internet or corporate networks as long as benchmarking is not 935 performed on devices or systems connected to production networks. 936 Security threats and how to counter these in SIP and the media 937 layer is discussed in RFC3261, RFC3550, and RFC3711 and various 938 other drafts. This document attempts to formalize a set of 939 common terminology for benchmarking IGP convergence performance 940 in a lab environment. 942 Link-State IGP Data Plane Route Convergence 944 6. Acknowledgements 945 Thanks to Sue Hares, Al Morton, Kevin Dubray, Ron Bonica, David Ward, 946 Kris Michielsen and the BMWG for their contributions to this work. 948 7. References 949 7.1 Normative References 950 [Ba91] Bradner, S. "Benchmarking Terminology for Network 951 Interconnection Devices", RFC1242, July 1991. 953 [Ba99] Bradner, S. and McQuaid, J., "Benchmarking 954 Methodology for Network Interconnect Devices", 955 RFC 2544, March 1999. 957 [Br97] Bradner, S., "Key words for use in RFCs to Indicate 958 Requirement Levels", RFC 2119, March 1997 960 [Ca90] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual 961 Environments", RFC 1195, December 1990. 963 [Ma98] Mandeville, R., "Benchmarking Terminology for LAN 964 Switching Devices", RFC 2285, February 1998. 966 [Mo98] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 968 [Mo06] Morton, A., et al, "Packet Reordering Metrics", RFC 4737, 969 November 2006. 971 [Po06] Poretsky, S., et al., "Terminology for Benchmarking 972 Network-layer Traffic Control Mechanisms", RFC 4689, 973 November 2006. 975 [Po07a] Poretsky, S., "Benchmarking Applicability for Link-State 976 IGP Data Plane Route Convergence", 977 draft-ietf-bmwg-igp-dataplane-conv-app-17, work in progress, 978 March 2009. 980 [Po07m] Poretsky, S. and Imhoff, B., "Benchmarking Methodology for 981 Link-State IGP Data Plane Route Convergence", 982 draft-ietf-bmwg-igp-dataplane-conv-meth-17, work in progress, 983 March 2009. 985 7.2 Informative References 986 [Ca01] S. Casner, C. Alaettinoglu, and C. Kuan, "A Fine-Grained View 987 of High Performance Networking", NANOG 22, June 2001. 989 [Ci03] L. Ciavattone, A. Morton, and G. Ramachandran, "Standardized 990 Active Measurements on a Tier 1 IP Backbone", IEEE 991 Communications Magazine, pp90-97, May 2003. 993 Link-State IGP Data Plane Route Convergence 995 8. Author's Address 997 Scott Poretsky 998 Allot Communications 999 67 South Bedford Street, Suite 400 1000 Burlington, MA 01803 1001 USA 1002 Phone: + 1 508 309 2179 1003 Email: sporetsky@allot.com 1005 Brent Imhoff 1006 Juniper Networks 1007 1194 North Mathilda Ave 1008 Sunnyvale, CA 94089 1009 USA 1010 Phone: + 1 314 378 2571 1011 EMail: bimhoff@planetspork.com