idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-term-16.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 983. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 995. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1002. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1008. 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 (October 15, 2008) is 5673 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-16 == Outdated reference: A later version (-23) exists of draft-ietf-bmwg-igp-dataplane-conv-meth-16 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 Allot Communications 3 Expires: April 2009 4 Intended Status: Informational Brent Imhoff 5 Juniper Networks 7 October 15, 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...............................................7 60 3.7 Convergence Packet Loss...................................7 61 3.8 Convergence Event Instant.................................8 62 3.9 Convergence Recovery Instant..............................8 63 3.10 First Route Convergence Instant..........................9 64 3.11 Convergence Event Transition.............................9 65 3.12 Convergence Recovery Transition..........................10 66 3.13 Rate-Derived Convergence Time............................10 67 3.14 Loss-Derived Convergence Time............................11 68 3.15 Route-Specific Convergence Time..........................12 69 3.16 Sustained Convergence Validation Time....................13 70 3.17 First Route Convergence Time.............................14 71 3.18 Reversion Convergence Time...............................15 72 3.19 Packet Sampling Interval.................................15 73 3.20 Local Interface..........................................16 74 3.21 Neighbor Interface.......................................16 75 3.22 Remote Interface.........................................17 76 3.23 Preferred Egress Interface...............................17 77 3.24 Next-Best Egress Interface...............................17 78 3.25 Stale Forwarding.........................................18 79 3.26 Nested Convergence Events................................18 80 4. IANA Considerations...........................................19 81 5. Security Considerations.......................................19 82 6. Acknowledgements..............................................19 83 7. References....................................................19 84 8. Author's Address..............................................20 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 Full Convergence, 111 Convergence Convergence 112 Recovery Event 113 Instant Instant Time = 0sec 114 Forwarding Rate = ^ ^ ^ Offered Load = 115 Offered Load --> ------\ Packet /-------- <---Max Throughput 116 \ Loss /<----Convergence 117 Convergence------->\ / Event Transition 118 Recovery Transition \ / 119 \_____/<------Maximum Packet Loss 120 ^ 121 First Route 122 Convergence Instant 124 Y-axis = Forwarding Rate 125 X-axis = Time (increases right to left to match commercial test 126 equipment displays) 128 Figure 1. Convergence Graph 130 2. Existing definitions 132 This document uses existing terminology defined in other BMWG 133 work. Examples include, but are not limited to: 135 Latency [Ref.[Ba91], section 3.8] 136 Frame Loss Rate [Ref.[Ba91], section 3.6] 137 Throughput [Ref.[Ba91], section 3.17] 138 Device Under Test (DUT) [Ref.[Ma98], section 3.1.1] 139 System Under Test (SUT) [Ref.[Ma98], section 3.1.2] 140 Out-of-order Packet [Ref.[Po06], section 3.3.2] 141 Duplicate Packet [Ref.[Po06], section 3.3.3] 142 Packet Reordering [Ref.[Mo06], section 3.3] 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in BCP 14, RFC 2119 147 [Br97]. RFC 2119 defines the use of these key words to help make the 148 intent of standards track documents as clear as possible. While this 149 document uses these keywords, this document is not a standards track 150 document. 152 Link-State IGP Data Plane Route Convergence 154 3. Term Definitions 155 3.1 Convergence Event 157 Definition: 158 The occurrence of a planned or unplanned event in the network 159 that results in a change in the egress interface of the Device 160 Under Test (DUT) for routed packets. 162 Discussion: 163 Convergence Events include link loss, routing protocol session 164 loss, router failure, configuration change, and better next-hop 165 learned via a routing protocol. 167 Measurement Units: 168 N/A 170 Issues: 171 None 173 See Also: 174 Convergence Packet Loss 175 Convergence Event Instant 177 3.2 Route Convergence 179 Definition: 180 The action to update all components of the router with the 181 most recent route change(s) including the Routing 182 Information Base (RIB) and Forwarding Information Base (FIB), 183 along with software and hardware tables, such that forwarding 184 is successful for one or more route entries. 186 Discussion: 187 Route Convergence MUST occur after a Convergence Event. 188 Route Convergence can be observed externally by the rerouting 189 of data traffic to the Next-best Egress Interface. Also, 190 completion of Route Convergence may or may not be sustained 191 over time. 193 Measurement Units: 194 N/A 196 Issues: 197 None 199 See Also: 200 Network Convergence 201 Full Convergence 202 Convergence Event 203 Link-State IGP Data Plane Route Convergence 205 3.3 Full Convergence 207 Definition: 208 Route Convergence for an entire FIB in which complete recovery 209 from the Convergence Event is indicated by the DUT Throughput 210 equal to the offered load. 212 Discussion: 213 When benchmarking convergence, it is useful to measure 214 the time to converge an entire FIB. For example, 215 a Convergence Event can be produced for an OSPF table of 216 5000 routes so that the time to converge routes 1 through 217 5000 is measured. Completion of Full Convergence is externally 218 observable from the data plane when the Throughput of the data 219 plane traffic on the Next-Best Egress Interface equals the 220 offered load. 222 Full convergence MAY be measured using Rate-Derived Convergence 223 Time (3.13) or calculated using Loss-Derived Convergence Time 224 (3.14). When performing Route-Specific Convergence (3.5) 225 measurements, Full Convergence may be obtained by measuring the 226 maximum Route Specific Convergence Time (3.15). Full 227 Convergence may or may not be sustained over time. The 228 Sustained Convergence Validation Time (3.16) MUST be applied. 230 Measurement Units: 231 N/A 233 Issues: 234 None 236 See Also: 237 Network Convergence 238 Route Convergence 239 Convergence Event 241 3.4 Network Convergence 243 Definition: 244 The process of updating of all routing tables, including 245 distributed FIBs, in all routers throughout the network. 247 Discussion: 248 Network Convergence requires completion of all Route 249 Convergence operations for all routers in the network following 250 a Convergence Event. Completion of Network Convergence can be 251 observed by recovery of System Under Test (SUT) Throughput to 252 equal the offered load, with no Stale Forwarding, and no 253 Blenders [Ca01][Ci03]. 255 Link-State IGP Data Plane Route Convergence 257 Measurement Units: 258 N/A 260 Issues: 261 None 263 See Also: 264 Route Convergence 265 Stale Forwarding 267 3.5 Route-Specific Convergence 269 Definition: 270 Route Convergence for one or more specific route entries in 271 the FIB in which recovery from the Convergence Event is 272 indicated by data-plane traffic for a flow [Po06] matching that 273 route entry(ies) being routed to the Next-Best Egress Interface. 275 Discussion: 276 When benchmarking convergence, it is sometimes useful to 277 measure the time to converge a single flow [Po06] or group of 278 flows to benchmark convergence time for one or a few route 279 entries in the FIB instead of the entire FIB. Route-Specific 280 Convergence of a flow is externally observable from the data 281 plane when the data plane traffic for that flow is routed to 282 the Next-Best Egress Interface. 284 Measurement Units: 285 N/A 287 Issues: 288 None 290 See Also: 291 Full Convergence 292 Route Convergence 293 Convergence Event 294 Link-State IGP Data Plane Route Convergence 296 3.6 Packet Loss 298 Definition: 299 The number of packets that should have been forwarded 300 by a DUT under a constant offered load that were 301 not forwarded due to lack of resources. 303 Discussion: 304 Packet Loss is a modified version of the term "Frame Loss Rate" 305 as defined in [Ba91]. The term "Frame Loss" is intended for 306 Ethernet Frames while "Packet Loss" is intended for IP packets. 307 Packet Loss can be measured as a reduction in forwarded traffic 308 from the Throughput [Ba91] of the DUT. 310 Measurement units: 311 Number of offered packets that are not forwarded. 313 Issues: None 315 See Also: 316 Convergence Packet Loss 318 3.7 Convergence Packet Loss 320 Definition: 321 The number of packets lost due to a Convergence Event 322 until Full Convergence completes. 324 Discussion: 325 Convergence Packet Loss includes packets that were lost and 326 packets that were delayed due to buffering. The Convergence 327 Packet Loss observed in a Packet Sampling Interval may or may 328 not be equal to the number of packets in the offered load 329 during the interval following a Convergence Event (see Figure 330 1). 332 Measurement Units: 333 number of packets 335 Issues: None 337 See Also: 338 Packet Loss 339 Route Convergence 340 Convergence Event 341 Packet Sampling Interval 342 Link-State IGP Data Plane Route Convergence 344 3.8 Convergence Event Instant 346 Definition: 347 The time instant that a Convergence Event becomes observable in 348 the data plane. 350 Discussion: 351 Convergence Event Instant is observable from the data 352 plane as the precise time that the device under test begins 353 to exhibit packet loss. 355 Measurement Units: 356 hh:mm:ss:nnn:uuu, 357 where 'nnn' is milliseconds and 'uuu' is microseconds. 359 Issues: 360 None 362 See Also: 363 Convergence Event 364 Convergence Packet Loss 365 Convergence Recovery Instant 367 3.9 Convergence Recovery Instant 369 Definition: 370 The time instant that Full Convergence completion is 371 measured and then maintained for an interval of duration 372 equal to the Sustained Convergence Validation Time. 374 Discussion: 375 Convergence Recovery Instant is measurable from the data 376 plane as the precise time that the device under test 377 completes Full Convergence. 379 Measurement Units: 380 hh:mm:ss:nnn:uuu, 381 where 'nnn' is milliseconds and 'uuu' is microseconds. 383 Issues: 384 None 386 See Also: 387 Sustained Convergence Validation Time 388 Convergence Packet Loss 389 Convergence Event Instant 390 Link-State IGP Data Plane Route Convergence 392 3.10 First Route Convergence Instant 393 Definition: 394 The time instant a first route entry has converged 395 following a Convergence Event, as observed by receipt of 396 the first packet from the Next-Best Egress Interface. 398 Discussion: 399 The First Route Convergence Instant is an indication that the 400 process to achieve Full Convergence has begun. Any route may 401 be the first to converge for First Route Convergence Instant. 402 Measurement on the data-plane enables the First Route 403 Convergence Instant to be observed without any white-box 404 information from the DUT. 406 Measurement Units: N/A 408 Issues: 409 None 411 See Also: 412 Route Convergence 413 Full Convergence 414 Stale Forwarding 416 3.11 Convergence Event Transition 417 Definition: 418 A time interval observed following a Convergence Event in which 419 Throughput gradually reduces to a minimum value. 421 Discussion: 422 The Convergence Event Transition is best observed for Full 423 Convergence. The egress packet rate observed during a 424 Convergence Event Transition may not decrease linearly and may 425 not decrease to zero. Both the offered load and the Packet 426 Sampling Interval influence the observations of the Convergence 427 Event Transition. For example, even if the Convergence Event 428 were to cause the Throughput [Ba91] to drop to zero there would 429 be some number of packets observed, unless the Packet Sampling 430 Interval is exactly aligned with the Convergence Event. This 431 is further discussed with the term "Packet Sampling Interval". 433 Measurement Units: 434 seconds 436 Issues: 437 None 439 See Also: 440 Convergence Event 441 Full Convergence 442 Packet Sampling Interval 443 Link-State IGP Data Plane Route Convergence 445 3.12 Convergence Recovery Transition 447 Definition: 448 The characteristic of the DUT in which Throughput gradually 449 increases to equal the offered load. 451 Discussion: 452 The Convergence Recovery Transition is best observed for 453 Full Convergence. The egress packet rate observed during 454 a Convergence Recovery Transition may not increase linearly. 455 Both the offered load and the Packet Sampling Interval 456 influence the observations of the Convergence Recovery 457 Transition. This is further discussed with the term 458 "Packet Sampling Interval". 460 Measurement Units: 461 seconds 463 Issues: None 465 See Also: 466 Full Convergence 467 Packet Sampling Interval 469 3.13 Rate-Derived Convergence Time 471 Definition: 472 The amount of time for Convergence Packet Loss to persist upon 473 occurrence of a Convergence Event until Full Convergence has 474 completed. 476 Rate-Derived Convergence Time can be measured as the time 477 difference from the Convergence Event Instant to the 478 Convergence Recovery Instant, as shown with Equation 1. 480 (Equation 1) 481 Rate-Derived Convergence Time = 482 Convergence Recovery Instant - Convergence Event Instant. 484 Discussion: 485 Rate-Derived Convergence Time SHOULD be measured at the maximum 486 Throughput of the DUT. At least one packet per route in the FIB 487 for all routes in the FIB MUST be offered to the DUT within the 488 Packet Sampling Interval. 490 Failure to achieve Full Convergence results in a Rate-Derived 491 Convergence Time benchmark of infinity. It is RECOMMENDED that 492 the Rate-Derived Convergence Time be measured when benchmarking 493 Full Convergence. 495 Link-State IGP Data Plane Route Convergence 497 Measurement Units: 498 seconds 500 Issues: None 502 See Also: 503 Convergence Packet Loss 504 Convergence Recovery Instant 505 Convergence Event Instant 506 Full Convergence 508 3.14 Loss-Derived Convergence Time 510 Definition: 511 The amount of time it takes for Full Convergence to be 512 completed as calculated from the amount of Convergence 513 Packet Loss. Loss-Derived Convergence Time can be 514 calculated from Convergence Packet Loss as shown with 515 Equation 2. 517 Equation 2 - 518 Loss-Derived Convergence Time = 519 Convergence Packets Loss / Offered Load 520 where units are packets / packets/second = seconds 522 Discussion: 523 Optimally, the Convergence Event Transition and Convergence 524 Recovery Transition are instantaneous so that the 525 Rate-Derived Convergence Time = Loss-Derived Convergence Time. 526 However, router implementations are less than ideal. 527 Loss-Derived Convergence Time gives a better than 528 actual result when converging many routes simultaneously 529 because it ignores the Convergence Recovery Transition. 530 Rate-Derived Convergence Time takes the Convergence Recovery 531 Transition into account. Equation 2 calculates the average 532 convergence time over all routes to which packets have been 533 sent. Since this average convergence time is in general 534 smaller than the maximum convergence time over all routes, 535 Loss-Derived Convergence Time is not the preferred metric to 536 indicate Full Convergence completion. For this reason the 537 RECOMMENDED benchmark metric for Full Convergence is the 538 Rate-Derived Convergence Time. 540 Link-State IGP Data Plane Route Convergence 542 Guidelines for reporting Loss-Derived Convergence Time are 543 provided in [Po07m]. 545 Measurement Units: 546 seconds 548 Issues: 549 None 551 See Also: 552 Convergence Event 553 Convergence Packet Loss 554 Rate-Derived Convergence Time 555 Route-Specific Convergence 556 Convergence Event Transition 557 Convergence Recovery Transition 559 3.15 Route-Specific Convergence Time 561 Definition: 562 The amount of time it takes for Route-Specific Convergence to 563 be completed as calculated from the amount of Convergence 564 Packet Loss per flow. 566 Route-Specific Convergence Time can be calculated from 567 Convergence Packet Loss as shown with Equation 3. 569 Equation 3 - 570 Route-Specific Convergence Time = 571 Convergence Packets Loss / Offered Load 572 where units are packets / packets/second = seconds 574 Discussion: 576 It is possible to provide an offered load that has flows 577 matching every route entry in the FIB and benchmarking 578 Route-Specific Convergence Time for all route entries. The 579 number of flows that can be measured is dependent upon the flow 580 measurement capabilities of the Tester. When benchmarking 581 Route-Specific Convergence, Convergence Packet Loss is measured 582 for specific flow(s) and Equation 3 is applied for each flow. 583 Each flow has a single destination address matching a different 584 route entry. The fastest measurable convergence time is equal 585 to the time between two consecutive packets of a flow offered 586 by the Tester. 588 The Route-Specific Convergence Time benchmarks enable minimum, 589 maximum, average, and median convergence time measurements to be 590 reported by comparing the results for the different route 591 Link-State IGP Data Plane Route Convergence 593 entries. It also enables benchmarking of convergence time when 594 configuring a priority value for route entry(ies). Since 595 multiple Route-Specific Convergence Times can be measured it is 596 possible to have an array of results. The format for reporting 597 Route-Specific Convergence Time is provided in [Po07m]. 599 The Route-Specific Convergence Time MAY be used to benchmark 600 Full Convergence when used in combination with many flows 601 matching every FIB entry. In this case 602 Full Convergence = max(Route-Specific Convergence Time). 604 Measurement Units: 605 seconds 607 Issues: 608 None 610 See Also: 611 Convergence Event 612 Convergence Packet Loss 613 Route-Specific Convergence 615 3.16 Sustained Convergence Validation Time 617 Definition: 618 The amount of time for which the completion of Full 619 Convergence is maintained without additional packet loss. 621 Discussion: 622 The purpose of the Sustained Convergence Validation Time is to 623 produce Convergence benchmarks protected against fluctuation 624 in Throughput after the completion of Full Convergence is 625 observed. The RECOMMENDED Sustained Convergence Validation 626 Time to be used is 5 seconds. The BMWG selected 5 seconds 627 based upon RFC 2544 [Ba99] which recommends waiting 2 seconds 628 for residual frames to arrive and 5 seconds for DUT 629 restabilization. 631 Measurement Units: 632 seconds 634 Issues: None 636 See Also: 637 Full Convergence 638 Convergence Recovery Instant 639 Link-State IGP Data Plane Route Convergence 641 3.17 First Route Convergence Time 643 Definition: 644 The amount of time for Convergence Packet Loss until the 645 convergence of a first route entry on the Next-Best Egress 646 Interface, as indicated by the First Route Convergence 647 Instant. 649 Discussion: 650 The First Route Convergence Time benchmarking metric can be 651 measured when benchmarking either Full Convergence or 652 Route-Specific Convergence. When benchmarking Full Convergence, 653 First Route Convergence Time can be measured as the time 654 difference from the Convergence Event Instant and the First 655 Route Convergence Instant, as shown with Equation 4a. 657 (Equation 4a) 658 First Route Convergence Time = 659 First Route Convergence Instant - Convergence Event Instant 661 When benchmarking Route-Specific Convergence, First Route 662 Convergence Time can be measured as the minimum Route-Specific 663 Convergence Time, as shown with Equation 4b. 665 (Equation 4b) 666 First Route Convergence Time = 667 min(Route-Specific Convergence Time) 669 First Route Convergence Time should be measured at the maximum 670 Throughput of the DUT. At least one packet per route in the FIB 671 for all routes in the FIB MUST be offered to the DUT within the 672 Packet Sampling Interval. Failure to achieve the First Route 673 Convergence Instant results in a First Route Convergence Time 674 benchmark of infinity. 676 Measurement Units: 677 seconds 679 Issues: None 681 See Also: 682 Convergence Packet Loss 683 First Route Convergence Instant 684 Link-State IGP Data Plane Route Convergence 686 3.18 Reversion Convergence Time 687 Definition: 688 The amount of time for the DUT to complete Full Convergence 689 to the Preferred Egress Interface, instead of the Next-Best 690 Egress Interface, upon recovery from a Convergence Event. 692 Discussion: 693 Reversion Convergence Time is the amount of time for Full 694 Convergence to the original egress interface. This is 695 achieved by recovering from the Convergence Event, such as 696 restoring the failed link. Reversion Convergence Time is 697 measured using the Rate-Derived Convergence Time calculation 698 technique, as provided in Equation 1. It is possible to have 699 the Reversion Convergence Time differ from the Rate-Derived 700 Convergence Time. 702 Measurement Units: seconds 704 Issues: None 706 See Also: 707 Preferred Egress Interface 708 Convergence Event 709 Rate-Derived Convergence Time 711 3.19 Packet Sampling Interval 712 Definition: 713 The interval at which the tester (test equipment) polls to make 714 measurements for arriving packet flows. 716 Discussion: 717 At least one packet per route in the FIB for all routes in the 718 FIB MUST be offered to the DUT within the Packet Sampling 719 Interval. Metrics measured at the Packet Sampling Interval 720 MUST include Forwarding Rate and Convergence Packet Loss. 722 Packet Sampling Interval can influence the Convergence Graph. 723 This is particularly true when implementations complete Full 724 Convergence in less than the Packet Sampling Interval. The 725 Convergence Event Transition and Convergence Recovery Transition 726 can become exaggerated when the Packet Sampling Interval is too 727 long. This will produce a larger than actual Rate-Derived 728 Convergence Time. The recommended value for configuration of 729 the Packet Sampling Interval is provided in [Po07m]. 731 Measurement Units: seconds 733 Issues: None 735 See Also: 736 Convergence Packet Loss 737 Convergence Event Transition 738 Convergence Recovery Transition 739 Link-State IGP Data Plane Route Convergence 741 3.20 Local Interface 743 Definition: 744 An interface on the DUT. 746 Discussion: 747 A failure of the Local Interface indicates that the failure 748 occurred directly on the DUT. 750 Measurement Units: 751 N/A 753 Issues: 754 None 756 See Also: 757 Neighbor Interface 758 Remote Interface 760 3.21 Neighbor Interface 762 Definition: 763 The interface on the neighbor router or tester that is 764 directly linked to the DUT's Local Interface. 766 Discussion: 767 A failure of a Neighbor Interface indicates that a 768 failure occurred on a neighbor router's interface that 769 directly links the neighbor router to the DUT. 771 Measurement Units: 772 N/A 774 Issues: 775 None 777 See Also: 778 Local Interface 779 Remote Interface 780 Link-State IGP Data Plane Route Convergence 782 3.22 Remote Interface 784 Definition: 785 An interface on a neighboring router that is not directly 786 connected to any interface on the DUT. 788 Discussion: 789 A failure of a Remote Interface indicates that the failure 790 occurred on a neighbor router's interface that is not 791 directly connected to the DUT. 793 Measurement Units: 794 N/A 796 Issues: 797 None 799 See Also: 800 Local Interface 801 Neighbor Interface 803 3.23 Preferred Egress Interface 805 Definition: 806 The outbound interface from the DUT for traffic routed to the 807 preferred next-hop. 809 Discussion: 810 The Preferred Egress Interface is the egress interface prior 811 to a Convergence Event. 813 Measurement Units: 814 N/A 816 Issues: 817 None 819 See Also: 820 Next-Best Egress Interface 822 3.24 Next-Best Egress Interface 824 Definition: 825 The outbound interface from the DUT for traffic routed to the 826 second-best next-hop. It is the same media type and link speed 827 as the Preferred Egress Interface 829 Discussion: 830 The Next-Best Egress Interface becomes the egress interface 831 after a Convergence Event. 833 Link-State IGP Data Plane Route Convergence 835 Measurement Units: 836 N/A 838 Issues: None 840 See Also: 841 Preferred Egress Interface 843 3.25 Stale Forwarding 845 Definition: 846 Forwarding of traffic to route entries that no longer exist 847 or to route entries with next-hops that are no longer preferred. 849 Discussion: 850 Stale Forwarding can be caused by a Convergence Event and can 851 manifest as a "black-hole" or microloop that produces packet 852 loss. Stale Forwarding can exist until Network Convergence is 853 completed. Stale Forwarding cannot be observed with a single 854 DUT. 856 Measurement Units: 857 N/A 859 Issues: None 861 See Also: 862 Network Convergence 864 3.26 Nested Convergence Events 866 Definition: 867 The occurrence of a Convergence Event while the route 868 table is converging from a prior Convergence Event. 870 Discussion: 871 The Convergence Events for a Nested Convergence Event 872 MUST occur with different neighbors. A common 873 observation from a Nested Convergence Event will be 874 the withdrawal of routes from one neighbor while the 875 routes of another neighbor are being installed. 877 Measurement Units: 878 N/A 880 Issues: None 882 See Also: 883 Convergence Event 884 Link-State IGP Data Plane Route Convergence 886 4. IANA Considerations 888 This document requires no IANA considerations. 890 5. Security Considerations 892 Documents of this type do not directly affect the security of 893 Internet or corporate networks as long as benchmarking 894 is not performed on devices or systems connected to production 895 networks. 897 6. Acknowledgements 898 Thanks to Sue Hares, Al Morton, Kevin Dubray, Ron Bonica, David Ward, 899 Kris Michielsen and the BMWG for their contributions to this work. 901 7. References 902 7.1 Normative References 904 [Ba91] Bradner, S. "Benchmarking Terminology for Network 905 Interconnection Devices", RFC1242, July 1991. 907 [Ba99] Bradner, S. and McQuaid, J., "Benchmarking 908 Methodology for Network Interconnect Devices", 909 RFC 2544, March 1999. 911 [Br97] Bradner, S., "Key words for use in RFCs to Indicate 912 Requirement Levels", RFC 2119, March 1997 914 [Ca90] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual 915 Environments", RFC 1195, December 1990. 917 [Ma98] Mandeville, R., "Benchmarking Terminology for LAN 918 Switching Devices", RFC 2285, February 1998. 920 [Mo98] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 922 [Mo06] Morton, A., et al, "Packet Reordering Metrics", RFC 4737, 923 November 2006. 925 [Po06] Poretsky, S., et al., "Terminology for Benchmarking 926 Network-layer Traffic Control Mechanisms", RFC 4689, 927 November 2006. 929 [Po07a] Poretsky, S., "Benchmarking Applicability for Link-State 930 IGP Data Plane Route Convergence", 931 draft-ietf-bmwg-igp-dataplane-conv-app-16, work in progress, 932 October 2008. 934 [Po07m] Poretsky, S. and Imhoff, B., "Benchmarking Methodology for 935 Link-State IGP Data Plane Route Convergence", 936 draft-ietf-bmwg-igp-dataplane-conv-meth-16, work in progress, 937 October 2008. 939 Link-State IGP Data Plane Route Convergence 941 7.2 Informative References 943 [Ca01] S. Casner, C. Alaettinoglu, and C. Kuan, "A Fine-Grained View 944 of High Performance Networking", NANOG 22, June 2001. 946 [Ci03] L. Ciavattone, A. Morton, and G. Ramachandran, "Standardized 947 Active Measurements on a Tier 1 IP Backbone", IEEE 948 Communications Magazine, pp90-97, May 2003. 950 8. Author's Address 952 Scott Poretsky 953 Allot Communications 954 67 South Bedford Street, Suite 400 955 Burlington, MA 01803 956 USA 957 Phone: + 1 508 309 2179 958 Email: sporetsky@allot.com 960 Brent Imhoff 961 Juniper Networks 962 1194 North Mathilda Ave 963 Sunnyvale, CA 94089 964 USA 965 Phone: + 1 314 378 2571 966 EMail: bimhoff@planetspork.com 968 Full Copyright Statement 970 Copyright (C) The IETF Trust (2008). 972 This document is subject to the rights, licenses and restrictions 973 contained in BCP 78, and except as set forth therein, the authors 974 retain all their rights. 976 This document and the information contained herein are provided 977 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 978 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 979 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 980 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 981 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 982 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 983 FOR A PARTICULAR PURPOSE. 985 Link-State IGP Data Plane Route Convergence 987 Intellectual Property 988 The IETF takes no position regarding the validity or scope of any 989 Intellectual Property Rights or other rights that might be claimed to 990 pertain to the implementation or use of the technology described in 991 this document or the extent to which any license under such rights 992 might or might not be available; nor does it represent that it has 993 made any independent effort to identify any such rights. Information 994 on the procedures with respect to rights in RFC documents can be 995 found in BCP 78 and BCP 79. 997 Copies of IPR disclosures made to the IETF Secretariat and any 998 assurances of licenses to be made available, or the result of an 999 attempt made to obtain a general license or permission for the use of 1000 such proprietary rights by implementers or users of this 1001 specification can be obtained from the IETF on-line IPR repository at 1002 http://www.ietf.org/ipr. 1004 The IETF invites any interested party to bring to its attention any 1005 copyrights, patents or patent applications, or other proprietary 1006 rights that may cover technology that may be required to implement 1007 this standard. Please address the information to the IETF at ietf- 1008 ipr@ietf.org. 1010 Acknowledgement 1011 Funding for the RFC Editor function is currently provided by the 1012 Internet Society.