idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-term-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 971. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 983. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 990. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 996. 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 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 (February 25, 2008) is 5904 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-bmwg-igp-dataplane-conv-app-15 == Outdated reference: A later version (-23) exists of draft-ietf-bmwg-igp-dataplane-conv-meth-15 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Poretsky 2 Internet Draft NextPoint Networks 3 Expires: August 2008 4 Intended Status: Informational Brent Imhoff 5 Juniper Networks 7 February 25, 2008 9 Terminology for Benchmarking 10 Link-State IGP Data Plane Route Convergence 12 14 Intellectual Property Rights (IPR) statement: 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Status of this Memo 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 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 ABSTRACT 42 This document describes the terminology for benchmarking Interior 43 Gateway Protocol (IGP) Route Convergence. The terminology is to 44 be used for benchmarking IGP convergence time through externally 45 observable (black box) data plane measurements. The terminology 46 can be applied to any link-state IGP, such as ISIS and OSPF. 48 Link-State IGP Data Plane Route Convergence 50 Table of Contents 51 1. Introduction .................................................2 52 2. Existing definitions .........................................3 53 3. Term definitions..............................................4 54 3.1 Convergence Event.........................................4 55 3.2 Route Convergence.........................................4 56 3.3 Full Convergence..........................................5 57 3.4 Network Convergence.......................................5 58 3.5 Route-Specific Convergence................................6 59 3.6 Packet Loss...............................................6 60 3.7 Convergence Packet Loss...................................7 61 3.8 Convergence Event Instant.................................7 62 3.9 Convergence Recovery Instant..............................8 63 3.10 First Route Convergence Instant..........................8 64 3.11 Convergence Event Transition.............................9 65 3.12 Convergence Recovery Transition..........................9 66 3.13 Rate-Derived Convergence Time............................10 67 3.14 Loss-Derived Convergence Time............................10 68 3.15 Route-Specific Convergence Time..........................12 69 3.16 Sustained Convergence Validation Time....................13 70 3.17 First Route Convergence Time.............................13 71 3.18 Reversion Convergence Time...............................14 72 3.19 Packet Sampling Interval.................................14 73 3.20 Local Interface..........................................15 74 3.21 Neighbor Interface.......................................15 75 3.22 Remote Interface.........................................15 76 3.23 Preferred Egress Interface...............................16 77 3.24 Next-Best Egress Interface...............................16 78 3.25 Stale Forwarding.........................................17 79 3.26 Nested Convergence Events................................17 80 4. IANA Considerations...........................................18 81 5. Security Considerations.......................................18 82 6. Acknowledgements..............................................18 83 7. References....................................................18 84 8. Author's Address..............................................19 86 1. Introduction 87 This draft describes the terminology for benchmarking Interior 88 Gateway Protocol (IGP) Route Convergence. The motivation and 89 applicability for this benchmarking is provided in [Po07a]. The 90 methodology to be used for this benchmarking is described in [Po07m]. 91 The methodology and terminology to be used for benchmarking Route 92 Convergence can be applied to any link-state IGP such as ISIS [Ca90] 93 and OSPF [Mo98]. The data plane is measured to obtain black-box 94 (externally observable) convergence benchmarking metrics. The 95 purpose of this document is to introduce new terms required to 96 complete execution of the IGP Route Convergence Methodology [Po07m]. 97 These terms apply to IPv4 and IPv6 traffic and IGPs. 99 Link-State IGP Data Plane Route Convergence 101 An example of Route Convergence as observed and measured from the 102 data plane is shown in Figure 1. The graph in Figure 1 shows 103 Forwarding Rate versus Time. Time 0 on the X-axis is on the far 104 right of the graph. The Offered Load to the ingress interface of 105 the DUT SHOULD equal the measured maximum Throughput [Ba99][Ma98] 106 of the DUT and the Forwarding Rate [Ma98] is measured at the egress 107 interfaces of the DUT. The components of the graph and the metrics 108 are defined in the Term Definitions section. 110 Convergence Convergence 111 Recovery Event 112 Instant Instant Time = 0sec 113 Forwarding Rate = ^ ^ ^ Offered Load = 114 Offered Load --> ------\ Packet /-------- <---Max Throughput 115 \ Loss /<----Convergence 116 Convergence------->\ / Event Transition 117 Recovery Transition \ / 118 \_____/<------Maximum Packet Loss 119 ^ 120 First Route 121 Convergence Instant 123 Y-axis = Forwarding Rate 124 X-axis = Time (increases right to left to match commercial test 125 equipment displays) 127 Figure 1. Convergence Graph 129 2. Existing definitions 131 This document uses existing terminology defined in other BMWG 132 work. Examples include, but are not limited to: 134 Latency [Ref.[Ba91], section 3.8] 135 Frame Loss Rate [Ref.[Ba91], section 3.6] 136 Throughput [Ref.[Ba91], section 3.17] 137 Device Under Test (DUT) [Ref.[Ma98], section 3.1.1] 138 System Under Test (SUT) [Ref.[Ma98], section 3.1.2] 139 Out-of-order Packet [Ref.[Po06], section 3.3.2] 140 Duplicate Packet [Ref.[Po06], section 3.3.3] 141 Packet Reordering [Ref.[Mo06], section 3.3] 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in BCP 14, RFC 2119 146 [Br97]. RFC 2119 defines the use of these key words to help make the 147 intent of standards track documents as clear as possible. While this 148 document uses these keywords, this document is not a standards track 149 document. 151 Link-State IGP Data Plane Route Convergence 153 3. Term Definitions 154 3.1 Convergence Event 156 Definition: 157 The occurrence of a planned or unplanned event in the network 158 that results in a change in the egress interface of the Device 159 Under Test (DUT) for routed packets. 161 Discussion: 162 Convergence Events include link loss, routing protocol session 163 loss, router failure, configuration change, and better next-hop 164 learned via a routing protocol. 166 Measurement Units: 167 N/A 169 Issues: 170 None 172 See Also: 173 Convergence Packet Loss 174 Convergence Event Instant 176 3.2 Route Convergence 178 Definition: 179 The action to update all components of the router with the 180 most recent route change(s) including the Routing 181 Information Base (RIB) and Forwarding Information Base (FIB), 182 along with software and hardware tables, such that forwarding 183 is successful for one or more route entries. 185 Discussion: 186 Route Convergence MUST occur after a Convergence Event. 187 Route Convergence can be observed externally by the rerouting 188 of data traffic to the Next-best Egress Interface. Also, 189 completion of Route Convergence may or may not be sustained 190 over time. 192 Measurement Units: 193 N/A 195 Issues: 196 None 198 See Also: 199 Network Convergence 200 Full Convergence 201 Convergence Event 202 Link-State IGP Data Plane Route Convergence 204 3.3 Full Convergence 206 Definition: 207 Route Convergence for an entire FIB in which complete recovery 208 from the Convergence Event is indicated by the DUT Throughput 209 equal to the offered load. 211 Discussion: 212 When benchmarking convergence, it is useful to measure 213 the time to converge an entire FIB. For example, 214 a Convergence Event can be produced for an OSPF table of 215 5000 routes so that the time to converge routes 1 through 216 5000 is measured. Completion of Full Convergence is externally 217 observable from the data plane when the Throughput of the data 218 plane traffic on the Next-Best Egress Interface equals the 219 offered load. Full Convergence may or may not be sustained over 220 time. The Sustained Convergence Validation Time MUST be 221 applied. 223 Measurement Units: 224 N/A 226 Issues: 227 None 229 See Also: 230 Network Convergence 231 Route Convergence 232 Convergence Event 234 3.4 Network Convergence 236 Definition: 237 The process of updating of all routing tables, including 238 distributed FIBs, in all routers throughout the network. 240 Discussion: 241 Network Convergence requires completion of all Route 242 Convergence operations for all routers in the network following 243 a Convergence Event. Completion of Network Convergence can be 244 observed by recovery of System Under Test (SUT) Throughput to 245 equal the offered load, with no Stale Forwarding, and no 246 Blenders [Ca01][Ci03]. 248 Measurement Units: 249 N/A 251 Issues: 252 None 254 See Also: 255 Route Convergence 256 Stale Forwarding 257 Link-State IGP Data Plane Route Convergence 259 3.5 Route-Specific Convergence 261 Definition: 262 Route Convergence for one or more specific route entries in 263 the FIB in which recovery from the Convergence Event is 264 indicated by data-plane traffic for a flow [Po06] matching that 265 route entry(ies) being routed to the Next-Best Egress Interface. 267 Discussion: 268 When benchmarking convergence, it is sometimes useful to 269 measure the time to converge a single flow [Po06] or group of 270 flows to benchmark convergence time for one or a few route 271 entries in the FIB instead of the entire FIB. Route-Specific 272 Convergence of a flow is externally observable from the data 273 plane when the data plane traffic for that flow is routed to 274 the Next-Best Egress Interface. 276 Measurement Units: 277 N/A 279 Issues: 280 None 282 See Also: 283 Full Convergence 284 Route Convergence 285 Convergence Event 287 3.6 Packet Loss 289 Definition: 290 The number of packets that should have been forwarded 291 by a DUT under a constant offered load that were 292 not forwarded due to lack of resources. 294 Discussion: 295 Packet Lss is a modified version of the term "Frame Loss Rate" 296 as defined in [Ba91]. The term "Frame Loss" is intended for 297 Ethernet Frames while "Packet Loss" is intended for IP packets. 298 Packet Loss can be measured as a reduction in forwarded traffic 299 from the Throughput [Ba91] of the DUT. 301 Measurement units: 302 Number of offered packets that are not forwarded. 304 Issues: None 306 See Also: 307 Convergence Packet Loss 308 Link-State IGP Data Plane Route Convergence 310 3.7 Convergence Packet Loss 312 Definition: 313 The number of packets lost due to a Convergence Event 314 until Full Convergence completes. 316 Discussion: 317 Convergence Packet Loss includes packets that were lost and 318 packets that were delayed due to buffering. The Convergence 319 Packet Loss observed in a Packet Sampling Interval may or may 320 not be equal to the number of packets in the offered load 321 during the interval following a Convergence Event (see Figure 322 1). 324 Measurement Units: 325 number of packets 327 Issues: None 329 See Also: 330 Packet Loss 331 Route Convergence 332 Convergence Event 333 Packet Sampling Interval 335 3.8 Convergence Event Instant 337 Definition: 338 The time instant that a Convergence Event becomes observable in 339 the data plane. 341 Discussion: 342 Convergence Event Instant is observable from the data 343 plane as the precise time that the device under test begins 344 to exhibit packet loss. 346 Measurement Units: 347 hh:mm:ss:nnn:uuu, 348 where 'nnn' is milliseconds and 'uuu' is microseconds. 350 Issues: 351 None 353 See Also: 354 Convergence Event 355 Convergence Packet Loss 356 Convergence Recovery Instant 357 Link-State IGP Data Plane Route Convergence 359 3.9 Convergence Recovery Instant 361 Definition: 362 The time instant that Full Convergence completion is 363 measured and then maintained for an interval of duration 364 equal to the Sustained Convergence Validation Time. 366 Discussion: 367 Convergence Recovery Instant is measurable from the data 368 plane as the precise time that the device under test 369 completes Full Convergence. 371 Measurement Units: 372 hh:mm:ss:nnn:uuu, 373 where 'nnn' is milliseconds and 'uuu' is microseconds. 375 Issues: 376 None 378 See Also: 379 Sustained Convergence Validation Time 380 Convergence Packet Loss 381 Convergence Event Instant 383 3.10 First Route Convergence Instant 385 Definition: 386 The time instant a first route entry has converged 387 following a Convergence Event, as observed by receipt of 388 the first packet from the Next-Best Egress Interface. 390 Discussion: 391 The First Route Convergence Instant is an indication that the 392 process to achieve Full Convergence has begun. Any route may 393 be the first to converge for First Route Convergence Instant. 394 Measurement on the data-plane enables the First Route 395 Convergence Instant to be observed without any white-box 396 information from the DUT. 398 Measurement Units: 399 N/A 401 Issues: 402 None 404 See Also: 405 Route Convergence 406 Full Convergence 407 Stale Forwarding 408 Link-State IGP Data Plane Route Convergence 410 3.11 Convergence Event Transition 412 Definition: 413 A time interval observed following a Convergence Event in which 414 Throughput gradually reduces to a minimum value. 416 Discussion: 417 The Convergence Event Transition is best observed for Full 418 Convergence. The egress packet rate observed during a 419 Convergence Event Transition may not decrease linearly and may 420 not decrease to zero. Both the offered load and the Packet 421 Sampling Interval influence the observations of the Convergence 422 Event Transition. For example, even if the Convergence Event 423 were to cause the Throughput [Ba91] to drop to zero there would 424 be some number of packets observed, unless the Packet Sampling 425 Interval is exactly aligned with the Convergence Event. This 426 is further discussed with the term "Packet Sampling Interval". 428 Measurement Units: 429 seconds 431 Issues: 432 None 434 See Also: 435 Convergence Event 436 Full Convergence 437 Packet Sampling Interval 439 3.12 Convergence Recovery Transition 441 Definition: 442 The characteristic of the DUT in which Throughput gradually 443 increases to equal the offered load. 445 Discussion: 446 The Convergence Recovery Transition is best observed for 447 Full Convergence. The egress packet rate observed during 448 a Convergence Recovery Transition may not increase linearly. 449 Both the offered load and the Packet Sampling Interval 450 influence the observations of the Convergence Recovery 451 Transition. This is further discussed with the term 452 "Packet Sampling Interval". 454 Measurement Units: 455 seconds 457 Issues: None 459 See Also: 460 Full Convergence 461 Packet Sampling Interval 462 Link-State IGP Data Plane Route Convergence 464 3.13 Rate-Derived Convergence Time 466 Definition: 467 The amount of time for Convergence Packet Loss to persist upon 468 occurrence of a Convergence Event until Full Convergence has 469 completed. 471 Rate-Derived Convergence Time can be measured as the time 472 difference from the Convergence Event Instant to the 473 Convergence Recovery Instant, as shown with Equation 1. 475 (Equation 1) 476 Rate-Derived Convergence Time = 477 Convergence Recovery Instant - Convergence Event Instant. 479 Discussion: 480 Rate-Derived Convergence Time SHOULD be measured at the maximum 481 Throughput of the DUT. At least one packet per route in the FIB 482 for all routes in the FIB MUST be offered to the DUT within the 483 Packet Sampling Interval. 485 Failure to achieve Full Convergence results in a Rate-Derived 486 Convergence Time benchmark of infinity. It is RECOMMENDED that 487 the Rate-Derived Convergence Time be measured when benchmarking 488 Full Convergence. 490 Measurement Units: 491 seconds 493 Issues: None 495 See Also: 496 Convergence Packet Loss 497 Convergence Recovery Instant 498 Convergence Event Instant 499 Full Convergence 501 3.14 Loss-Derived Convergence Time 503 Definition: 504 The amount of time it takes for Full Convergence to be 505 completed as calculated from the amount of Convergence 506 Packet Loss. Loss-Derived Convergence Time can be 507 calculated from Convergence Packet Loss as shown with 508 Equation 2. 510 Equation 2 - 511 Loss-Derived Convergence Time = 512 Convergence Packets Loss / Offered Load 513 where units are packets / packets/second = seconds 514 Link-State IGP Data Plane Route Convergence 516 Discussion: 517 Optimally, the Convergence Event Transition and Convergence 518 Recovery Transition are instantaneous so that the 519 Rate-Derived Convergence Time = Loss-Derived Convergence Time. 520 However, router implementations are less than ideal. 521 Loss-Derived Convergence Time gives a better than 522 actual result when converging many routes simultaneously 523 because it ignores the Convergence Recovery Transition. 524 Rate-Derived Convergence Time takes the Convergence Recovery 525 Transition into account. Equation 2 calculates the average 526 convergence time over all routes to which packets have been 527 sent. Since this average convergence time is in general 528 smaller than the maximum convergence time over all routes, 529 Loss-Derived Convergence Time is not the preferred metric to 530 indicate Full Convergence completion. For this reason the 531 RECOMMENDED benchmark metric for Full Convergence is the 532 Rate-Derived Convergence Time. 534 Guidelines for reporting Loss-Derived Convergence Time are 535 provided in [Po07m]. 537 Measurement Units: 538 seconds 540 Issues: 541 None 543 See Also: 544 Convergence Event 545 Convergence Packet Loss 546 Rate-Derived Convergence Time 547 Route-Specific Convergence 548 Convergence Event Transition 549 Convergence Recovery Transition 550 Link-State IGP Data Plane Route Convergence 552 3.15 Route-Specific Convergence Time 554 Definition: 555 The amount of time it takes for Route-Specific Convergence to 556 be completed as calculated from the amount of Convergence 557 Packet Loss per flow. 559 Route-Specific Convergence Time can be calculated from 560 Convergence Packet Loss as shown with Equation 3. 562 Equation 3 - 563 Route-Specific Convergence Time = 564 Convergence Packets Loss / Offered Load 565 where units are packets / packets/second = seconds 567 Discussion: 569 It is possible to provide an offered load that has flows 570 matching every route entry in the FIB and benchmarking 571 Route-Specific Convergence Time for all route entries. The 572 number of flows that can be measured is dependent upon the flow 573 measurement capabilities of the Tester. When benchmarking 574 Route-Specific Convergence, Convergence Packet Loss is measured 575 for specific flow(s) and Equation 3 is applied for each flow. 576 Each flow has a single destination address matching a different 577 route entry. The fastest measurable convergence time is equal 578 to the time between two consecutive packets of a flow offered 579 by the Tester. 581 The Route-Specific Convergence Time benchmarks enable minimum, 582 maximum, average, and median convergence time measurements to be 583 reported by comparing the results for the different route 584 entries. It also enables benchmarking of convergence time when 585 configuring a priority value for route entry(ies). Since 586 multiple Route-Specific Convergence Times can be measured it is 587 possible to have an array of results. The format for reporting 588 Route-Specific Convergence Time is provided in [Po07m]. 590 The Route-Specific Convergence Time MAY be used to benchmark 591 Full Convergence when used in combination with many flows 592 matching every FIB entry. 594 Measurement Units: 595 seconds 597 Issues: 598 None 600 See Also: 601 Convergence Event 602 Convergence Packet Loss 603 Route-Specific Convergence 604 Link-State IGP Data Plane Route Convergence 606 3.16 First Route Convergence Time 608 Definition: 609 The amount of time for Convergence Packet Loss until the 610 convergence of a first route entry on the Next-Best Egress 611 Interface, as indicated by the First Route Convergence 612 Instant. 614 Discussion: 615 The First Route Convergence Time benchmarking metric can be 616 measured when benchmarking either Full Convergence or 617 Route-Specific Convergence. When benchmarking Full Convergence, 618 First Route Convergence Time can be measured as the time 619 difference from the Convergence Event Instant and the First 620 Route Convergence Instant, as shown with Equation 4a. 622 (Equation 4a) 623 First Route Convergence Time = 624 First Route Convergence Instant - Convergence Event Instant 626 When benchmarking Route-Specific Convergence, First Route 627 Convergence Time can be measured as the minimum Route-Specific 628 Convergence Time, as shown with Equation 4b. 630 (Equation 4b) 631 First Route Convergence Time = 632 min(Route-Specific Convergence Time) 634 First Route Convergence Time should be measured at the maximum 635 Throughput of the DUT. At least one packet per route in the FIB 636 for all routes in the FIB MUST be offered to the DUT within the 637 Packet Sampling Interval. Failure to achieve the First Route 638 Convergence Instant results in a First Route Convergence Time 639 benchmark of infinity. 641 Measurement Units: 642 seconds 644 Issues: None 646 See Also: 647 Convergence Packet Loss 648 First Route Convergence Instant 650 3.17 Sustained Convergence Validation Time 652 Definition: 653 The amount of time for which the completion of Full 654 Convergence is maintained without additional packet loss. 656 Link-State IGP Data Plane Route Convergence 658 Discussion: 659 The purpose of the Sustained Convergence Validation Time is to 660 produce Convergence benchmarks protected against fluctuation 661 in Throughput after the completion of Full Convergence is 662 observed. The RECOMMENDED Sustained Convergence Validation 663 Time to be used is 5 seconds. 665 Measurement Units: 666 seconds 668 Issues: None 670 See Also: 671 Full Convergence 672 Convergence Recovery Instant 674 3.18 Reversion Convergence Time 675 Definition: 676 The amount of time for the DUT to complete Full Convergence 677 to the Preferred Egress Interface, instead of the Next-Best 678 Egress Interface, upon recovery from a Convergence Event. 680 Discussion: 681 Reversion Convergence Time is the amount of time for Full 682 COnvergence to the original egress interface. This is 683 achieved by recovering from the Convergence Event, such as 684 restoring the failed link. Reversion Convergence Time is 685 measured using the Rate-Derived Convergence Time calculation 686 technique, as provided in Equation 1. It is possible to have 687 the Reversion Convergence Time differ from the Rate-Derived 688 Convergence Time. 690 Measurement Units: 691 seconds 693 Issues: None 695 See Also: 696 Preferred Egress Interface 697 Convergence Event 698 Rate-Derived Convergence Time 700 3.19 Packet Sampling Interval 701 Definition: 702 The interval at which the tester (test equipment) polls to make 703 measurements for arriving packet flows. 705 Discussion: 706 At least one packet per route in the FIB 707 for all routes in the FIB MUST be offered to the DUT within the 708 Packet Sampling Interval. Metrics measured at the Packet 709 Sampling Interval MUST include Forwarding Rate and Convergence 710 Packet Loss. 712 Link-State IGP Data Plane Route Convergence 714 Measurement Units: 715 seconds 717 Issues: 718 Packet Sampling Interval can influence the Convergence Graph. 719 This is particularly true when implementations complete Full 720 Convergence in less than the Packet Sampling Interval. The 721 Convergence Event Transition and Convergence Recovery Transition 722 can become exaggerated when the Packet Sampling Interval is too 723 long. This will produce a larger than actual Rate-Derived 724 Convergence Time. The recommended value for configuration of 725 the Packet Sampling Interval is provided in [Po07m]. 727 See Also: 728 Convergence Packet Loss 729 Convergence Event Transition 730 Convergence Recovery Transition 732 3.20 Local Interface 734 Definition: 735 An interface on the DUT. 737 Discussion: 738 A failure of the Local Interface indicates that the failure 739 occurred directly on the DUT. 741 Measurement Units: 742 N/A 744 Issues: 745 None 747 See Also: 748 Neighbor Interface 749 Remote Interface 751 3.21 Neighbor Interface 753 Definition: 754 The interface on the neighbor router or tester that is 755 directly linked to the DUT's Local Interface. 757 Discussion: 758 A failure of a Neighbor Interface indicates that a 759 failure occurred on a neighbor router's interface that 760 directly links the neighbor router to the DUT. 762 Measurement Units: 763 N/A 764 Link-State IGP Data Plane Route Convergence 766 Issues: 767 None 769 See Also: 770 Local Interface 771 Remote Interface 773 3.22 Remote Interface 775 Definition: 776 An interface on a neighboring router that is not directly 777 connected to any interface on the DUT. 779 Discussion: 780 A failure of a Remote Interface indicates that the failure 781 occurred on a neighbor router's interface that is not 782 directly connected to the DUT. 784 Measurement Units: 785 N/A 787 Issues: 788 None 790 See Also: 791 Local Interface 792 Neighbor Interface 794 3.23 Preferred Egress Interface 796 Definition: 797 The outbound interface from the DUT for traffic routed to the 798 preferred next-hop. 800 Discussion: 801 The Preferred Egress Interface is the egress interface prior 802 to a Convergence Event. 804 Measurement Units: 805 N/A 807 Issues: 808 None 810 See Also: 811 Next-Best Egress Interface 813 3.24 Next-Best Egress Interface 815 Definition: 816 The outbound interface from the DUT for traffic routed to the 817 second-best next-hop. It is the same media type and link speed 818 as the Preferred Egress Interface 819 Link-State IGP Data Plane Route Convergence 821 Discussion: 822 The Next-Best Egress Interface becomes the egress interface 823 after a Convergence Event. 825 Measurement Units: 826 N/A 828 Issues: None 830 See Also: 831 Preferred Egress Interface 833 3.25 Stale Forwarding 834 Definition: 835 Forwarding of traffic to route entries that no longer exist 836 or to route entries with next-hops that are no longer preferred. 838 Discussion: 839 Stale Forwarding can be caused by a Convergence Event and can 840 manifest as a "black-hole" or microloop that produces packet 841 loss. Stale Forwarding can exist until Network Convergence is 842 completed. Stale Forwarding cannot be observed with a single 843 DUT. 845 Measurement Units: 846 N/A 848 Issues: None 850 See Also: 851 Network Convergence 853 3.26 Nested Convergence Events 854 Definition: 855 The occurrence of a Convergence Event while the route 856 table is converging from a prior Convergence Event. 858 Discussion: 859 The Convergence Events for a Nested Convergence Event 860 MUST occur with different neighbors. A common 861 observation from a Nested Convergence Event will be 862 the withdrawal of routes from one neighbor while the 863 routes of another neighbor are being installed. 865 Measurement Units: 866 N/A 868 Issues: None 870 See Also: 871 Convergence Event 872 Link-State IGP Data Plane Route Convergence 874 4. IANA Considerations 876 This document requires no IANA considerations. 878 5. Security Considerations 880 Documents of this type do not directly affect the security of 881 Internet or corporate networks as long as benchmarking 882 is not performed on devices or systems connected to production 883 networks. 885 6. Acknowledgements 886 Thanks to Sue Hares, Al Morton, Kevin Dubray, Ron Bonica, David Ward, 887 Kris Michielsen and the BMWG for their contributions to this work. 889 7. References 890 7.1 Normative References 892 [Ba91] Bradner, S. "Benchmarking Terminology for Network 893 Interconnection Devices", RFC1242, July 1991. 895 [Ba99] Bradner, S. and McQuaid, J., "Benchmarking 896 Methodology for Network Interconnect Devices", 897 RFC 2544, March 1999. 899 [Br97] Bradner, S., "Key words for use in RFCs to Indicate 900 Requirement Levels", RFC 2119, March 1997 902 [Ca90] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual 903 Environments", RFC 1195, December 1990. 905 [Ma98] Mandeville, R., "Benchmarking Terminology for LAN 906 Switching Devices", RFC 2285, February 1998. 908 [Mo98] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 910 [Mo06] Morton, A., et al, "Packet Reordering Metrics", RFC 4737, 911 November 2006. 913 [Po06] Poretsky, S., et al., "Terminology for Benchmarking 914 Network-layer Traffic Control Mechanisms", RFC 4689, 915 November 2006. 917 [Po07a] Poretsky, S., "Benchmarking Applicability for Link-State 918 IGP Data Plane Route Convergence", 919 draft-ietf-bmwg-igp-dataplane-conv-app-15, work in progress, 920 February 2008. 922 Link-State IGP Data Plane Route Convergence 924 [Po07m] Poretsky, S. and Imhoff, B., "Benchmarking Methodology for 925 Link-State IGP Data Plane Route Convergence", 926 draft-ietf-bmwg-igp-dataplane-conv-meth-15, work in progress, 927 February 2008. 929 7.2 Informative References 931 [Ca01] S. Casner, C. Alaettinoglu, and C. Kuan, "A Fine-Grained View 932 of High Performance Networking", NANOG 22, June 2001. 934 [Ci03] L. Ciavattone, A. Morton, and G. Ramachandran, "Standardized 935 Active Measurements on a Tier 1 IP Backbone", IEEE 936 Communications Magazine, pp90-97, May 2003. 938 8. Author's Address 940 Scott Poretsky 941 NextPoint Networks 942 3 Federal Street 943 Billerica, MA 01821 944 USA 945 Phone: + 1 508 439 9008 946 EMail: sporetsky@nextpointnetworks.com 948 Brent Imhoff 949 Juniper Networks 950 1194 North Mathilda Ave 951 Sunnyvale, CA 94089 952 USA 953 Phone: + 1 314 378 2571 954 EMail: bimhoff@planetspork.com 956 Full Copyright Statement 958 Copyright (C) The IETF Trust (2008). 960 This document is subject to the rights, licenses and restrictions 961 contained in BCP 78, and except as set forth therein, the authors 962 retain all their rights. 964 This document and the information contained herein are provided 965 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 966 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 967 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 968 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 969 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 970 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 971 FOR A PARTICULAR PURPOSE. 973 Link-State IGP Data Plane Route Convergence 975 Intellectual Property 976 The IETF takes no position regarding the validity or scope of any 977 Intellectual Property Rights or other rights that might be claimed to 978 pertain to the implementation or use of the technology described in 979 this document or the extent to which any license under such rights 980 might or might not be available; nor does it represent that it has 981 made any independent effort to identify any such rights. Information 982 on the procedures with respect to rights in RFC documents can be 983 found in BCP 78 and BCP 79. 985 Copies of IPR disclosures made to the IETF Secretariat and any 986 assurances of licenses to be made available, or the result of an 987 attempt made to obtain a general license or permission for the use of 988 such proprietary rights by implementers or users of this 989 specification can be obtained from the IETF on-line IPR repository at 990 http://www.ietf.org/ipr. 992 The IETF invites any interested party to bring to its attention any 993 copyrights, patents or patent applications, or other proprietary 994 rights that may cover technology that may be required to implement 995 this standard. Please address the information to the IETF at ietf- 996 ipr@ietf.org. 998 Acknowledgement 999 Funding for the RFC Editor function is currently provided by the 1000 Internet Society.