idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-term-14.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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 890. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 900. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 907. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 915. 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 (May 2008) is 5822 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-14 == Outdated reference: A later version (-23) exists of draft-ietf-bmwg-igp-dataplane-conv-meth-14 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 2 INTERNET-DRAFT 3 Expires in: May 2008 4 Intended Status: Informational 5 Scott Poretsky 6 Reef Point Systems 8 Brent Imhoff 9 Juniper Networks 11 November 2007 13 Terminology for Benchmarking 14 Link-State IGP Data Plane Route Convergence 16 18 Intellectual Property Rights (IPR) statement: 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Status of this Memo 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as 29 Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 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 IGP Data Plane Route Convergence 54 Table of Contents 55 1. Introduction .................................................2 56 2. Existing definitions .........................................3 57 3. Term definitions..............................................4 58 3.1 Convergence Event.........................................4 59 3.2 Route Convergence.........................................4 60 3.3 Network Convergence.......................................5 61 3.4 Full Convergence..........................................5 62 3.5 Packet Loss...............................................6 63 3.6 Convergence Packet Loss...................................6 64 3.7 Convergence Event Instant.................................7 65 3.8 Convergence Recovery Instant..............................7 66 3.9 First Prefix Convergence Instant..........................8 67 3.10 Convergence Event Transition.............................8 68 3.11 Convergence Recovery Transition..........................9 69 3.12 Rate-Derived Convergence Time............................9 70 3.13 Loss-Derived Convergence Time............................10 71 3.14 Sustained Forwarding Convergence Time....................11 72 3.15 First Prefix Convergence Time............................12 73 3.16 Reversion Convergence Time...............................12 74 3.17 Packet Sampling Interval.................................13 75 3.18 Local Interface..........................................13 76 3.19 Neighbor Interface.......................................14 77 3.20 Remote Interface.........................................14 78 3.21 Preferred Egress Interface...............................15 79 3.22 Next-Best Egress Interface...............................15 80 3.23 Stale Forwarding.........................................15 81 3.24 Nested Convergence Events................................16 82 4. IANA Considerations...........................................16 83 5. Security Considerations.......................................16 84 6. Acknowledgements..............................................16 85 7. References....................................................17 86 8. Author's Address..............................................18 88 1. Introduction 89 This draft describes the terminology for benchmarking Interior 90 Gateway Protocol (IGP) Route Convergence. The motivation and 91 applicability for this benchmarking is provided in [Po07a]. The 92 methodology to be used for this benchmarking is described in [Po07m]. 93 The methodology and terminology to be used for benchmarking Route 94 Convergence can be applied to any link-state IGP such as ISIS [Ca90] 95 and OSPF [Mo98]. The data plane is measured to obtain black-box 96 (externally observable) convergence benchmarking metrics. The 97 purpose of this document is to introduce new terms required to 98 complete execution of the IGP Route Convergence Methodology [Po07m]. 99 These terms apply to IPv4 and IPv6 traffic and IGPs. 101 IGP Data Plane Route Convergence 103 An example of Route Convergence as observed and measured from the 104 data plane is shown in Figure 1. The graph in Figure 1 shows 105 Forwarding Rate versus Time. Time 0 on the X-axis is on the far 106 right of the graph. The Offered Load to the ingress interface of 107 the DUT SHOULD equal the measured maximum Throughput [Ba99][Ma98] 108 of the DUT and the Forwarding Rate [Ma98] is measured at the egress 109 interfaces of the DUT. The components of the graph and the metrics 110 are defined in the Term Definitions section. 112 Convergence Convergence 113 Recovery Event 114 Instant Instant Time = 0sec 115 Forwarding Rate = ^ ^ ^ Offered Load = 116 Offered Load --> ------\ Packet /-------- <---Max Throughput 117 \ Loss /<----Convergence 118 Convergence------->\ / Event Transition 119 Recovery Transition \ / 120 \_____/<------Maximum Packet Loss 121 X-axis = Time 122 Y-axis = Forwarding Rate 124 Figure 1. Convergence Graph 126 2. Existing definitions 128 This document uses existing terminology defined in other BMWG 129 work. Examples include, but are not limited to: 131 Latency [Ref.[Ba91], section 3.8] 132 Frame Loss Rate [Ref.[Ba91], section 3.6] 133 Throughput [Ref.[Ba91], section 3.17] 134 Device Under Test (DUT) [Ref.[Ma98], section 3.1.1] 135 System Under Test (SUT) [Ref.[Ma98], section 3.1.2] 136 Out-of-order Packet [Ref.[Po06], section 3.3.2] 137 Duplicate Packet [Ref.[Po06], section 3.3.3] 138 Packet Reordering [Ref.[Mo06], section 3.3] 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in BCP 14, RFC 2119 143 [Br97]. RFC 2119 defines the use of these key words to help make the 144 intent of standards track documents as clear as possible. While this 145 document uses these keywords, this document is not a standards track 146 document. 148 IGP Data Plane Route Convergence 150 3. Term Definitions 151 3.1 Convergence Event 153 Definition: 154 The occurrence of a planned or unplanned action in the network 155 that results in a change in the egress interface of the Device 156 Under Test (DUT) for routed packets. 158 Discussion: 159 Convergence Events include link loss, routing protocol session 160 loss, router failure, configuration change, and better next-hop 161 learned via a routing protocol. 163 Measurement Units: 164 N/A 166 Issues: 167 None 169 See Also: 170 Convergence Packet Loss 171 Convergence Event Instant 173 3.2 Route Convergence 175 Definition: 176 Route Convergence is the action to update all components of the 177 router with the most recent route change(s) including the 178 Routing Information Base (RIB) and Forwarding Information Base 179 (FIB), along with software and hardware tables, such that 180 forwarding is successful for one or more destinations. 182 Discussion: 183 Route Convergence MUST occur after a Convergence Event. 184 Route Convergence can be observed externally by the rerouting 185 of data traffic to the Next-best Egress Interface. Also, 186 Route Convergence may or may not be sustained over time. 188 Measurement Units: 189 N/A 191 Issues: 192 None 194 See Also: 195 Network Convergence 196 Full Convergence 197 Convergence Event 198 IGP Data Plane Route Convergence 200 3.3 Network Convergence 202 Definition: 203 The completion of updating of all routing tables, including 204 distributed FIBs, in all routers throughout the network. 206 Discussion: 207 Network Convergence requires completion of all Route 208 Convergenceoperations for all routers in the network following 209 a Convergence Event. Network Convergence can be observed by 210 recovery of System Under Test (SUT) Throughput to equal the 211 offered load, with no Stale Forwarding, and no Blenders 212 [Ca01][Ci03]. 214 Measurement Units: 215 N/A 217 Issues: 218 None 220 See Also: 221 Route Convergence 222 Stale Forwarding 224 3.4 Full Convergence 226 Definition: 227 Route Convergence for an entire FIB in which complete recovery 228 from the Convergence Event is indicated by the DUT Throughput 229 equal to the offered load. 231 Discussion: 232 When benchmarking convergence, it is useful to measure 233 the time to converge an entire FIB. For example, 234 a Convergence Event can be produced for an OSPF table of 235 5000 routes so that the time to converge routes 1 through 236 5000 is measured. Full Convergence is externally observable 237 from the data plane when the Throughput of the data 238 plane traffic on the Next-Best Egress Interface equals the 239 offered load. 241 Measurement Units: 242 N/A 244 Issues: 245 None 247 See Also: 248 Network Convergence 249 Route Convergence 250 Convergence Event 251 IGP Data Plane Route Convergence 253 3.5 Packet Loss 255 Definition: 256 The number of packets that should have been forwarded 257 by a DUT under a constant offered load that were 258 not forwarded due to lack of resources. 260 Discussion: 261 Packet Loss is a modified version of the term "Frame Loss Rate" 262 as defined in [Ba91]. The term "Frame Loss" is intended for 263 Ethernet Frames while "Packet Loss" is intended for IP packets. 264 Packet Loss can be measured as a reduction in forwarded traffic 265 from the Throughput [Ba91] of the DUT. 267 Measurement units: 268 Number of offered packets that are not forwarded. 270 Issues: None 272 See Also: 273 Convergence Packet Loss 275 3.6 Convergence Packet Loss 277 Definition: 278 The number of packets lost due to a Convergence Event 279 until Full Convergence occurs. 281 Discussion: 282 Convergence Packet Loss includes packets that were lost and 283 packets that were delayed due to buffering. The Convergence 284 Packet Loss observed in a Packet Sampling Interval may or may 285 not be equal to the number of packets in the offered load 286 during the interval following a Convergence Event (see Figure 287 1). 289 Measurement Units: 290 number of packets 292 Issues: None 294 See Also: 295 Packet Loss 296 Route Convergence 297 Convergence Event 298 Packet Sampling Interval 299 IGP Data Plane Route Convergence 301 3.7 Convergence Event Instant 303 Definition: 304 The time instant that a Convergence Event becomes observable in 305 the data plane. 307 Discussion: 308 Convergence Event Instant is observable from the data 309 plane as the precise time that the device under test begins 310 to exhibit packet loss. 312 Measurement Units: 313 hh:mm:ss:nnn:uuu, 314 where 'nnn' is milliseconds and 'uuu' is microseconds. 316 Issues: 317 None 319 See Also: 320 Convergence Event 321 Convergence Packet Loss 322 Convergence Recovery Instant 324 3.8 Convergence Recovery Instant 326 Definition: 327 The time instant that Full Convergence is measured 328 and then maintained for an interval of duration equal to 329 the Sustained Forwarding Convergence Time 331 Discussion: 332 Convergence Recovery Instant is measurable from the data 333 plane as the precise time that the device under test 334 achieves Full Convergence. 336 Measurement Units: 337 hh:mm:ss:nnn:uuu, 338 where 'nnn' is milliseconds and 'uuu' is microseconds. 340 Issues: 341 None 343 See Also: 344 Sustained Forwarding Convergence Time 345 Convergence Packet Loss 346 Convergence Event Instant 347 IGP Data Plane Route Convergence 349 3.9 First Prefix Convergence Instant 351 Definition: 352 The time instant for convergence of a first route entry 353 following a Convergence Event, as observed by receipt of 354 the first packet from the Next-Best Egress Interface. 356 Discussion: 357 The First Prefix Convergence Instant is an indication that the 358 process to achieve Full Convergence has begun. Any route may be 359 the first to converge for First Convergence. Measurement on the 360 data-plane enables First Convergence to be observed without any 361 white-box information from the DUT. 363 Measurement Units: 364 N/A 366 Issues: 367 None 369 See Also: 370 Route Convergence 371 Full Convergence 372 Stale Forwarding 374 3.10 Convergence Event Transition 376 Definition: 377 A time interval observed following a Convergence Event in which 378 Throughput gradually reduces to zero. 380 Discussion: 381 The Convergence Event Transition is best observed for Full 382 Convergence. The egress packet rate observed during a 383 Convergence Event Transition may not decrease linearly. Both 384 the offered load and the Packet Sampling Interval influence the 385 observations of the Convergence Event Transition. For example, 386 even if the Convergence Event were to cause the Throughput 387 [Ba91] to drop to zero there would be some number of packets 388 observed, unless the Packet Sampling Interval is exactly 389 aligned with the Convergence Event. This is further discussed 390 with the term "Packet Sampling Interval". 392 IGP Data Plane Route Convergence 394 Measurement Units: 395 seconds 397 Issues: 398 None 400 See Also: 401 Convergence Event 402 Full Convergence 403 Packet Sampling Interval 405 3.11 Convergence Recovery Transition 407 Definition: 408 The characteristic of the DUT in which Throughput gradually 409 increases to equal the offered load. 411 Discussion: 412 The Convergence Recovery Transition is best observed for 413 Full Convergence. The egress packet rate observed during 414 a Convergence Recovery Transition may not increase linearly. 415 Both the offered load and the Packet Sampling Interval 416 influence the observations of the Convergence Recovery 417 Transition. This is further discussed with the term 418 "Packet Sampling Interval". 420 Measurement Units: 421 seconds 423 Issues: None 425 See Also: 426 Full Convergence 427 Packet Sampling Interval 429 3.12 Rate-Derived Convergence Time 431 Definition: 432 The amount of time for Convergence Packet Loss to persist upon 433 occurrence of a Convergence Event until measurement of Full 434 Convergence. 436 Rate-Derived Convergence Time can be measured as the time 437 difference from the Convergence Event Instant to the 438 Convergence Recovery Instant, as shown with Equation 1. 440 (Equation 1) 441 Rate-Derived Convergence Time = 442 Convergence Recovery Instant - Convergence Event Instant. 444 IGP Data Plane Route Convergence 446 Discussion: 447 Rate-Derived Convergence Time should be measured at the maximum 448 Throughput of the DUT. At least one packet per route in the FIB 449 for all routes in the FIB MUST be offered to the DUT per second. 450 Failure to achieve Full Convergence results in a Rate-Derived 451 Convergence Time benchmark of infinity. 453 Measurement Units: 454 seconds 456 Issues: 457 None 459 See Also: 460 Convergence Packet Loss 461 Convergence Recovery Instant 462 Convergence Event Instant 463 Full Convergence 465 3.13 Loss-Derived Convergence Time 467 Definition: 468 The amount of time it takes for Full Convergence to be 469 achieved as calculated from the amount of Convergence 470 Packet Loss. Loss-Derived Convergence Time can be 471 calculated from Convergence Packet Loss that occurs due 472 to a Convergence Event and Route Convergence as shown 473 with Equation 2. 475 Equation 2 - 476 Loss-Derived Convergence Time = 477 Convergence Packets Loss / Offered Load 478 NOTE: Units for this measurement are 479 packets / packets/second = seconds 481 Discussion: 482 Loss-Derived Convergence Time gives a better than 483 actual result when converging many routes simultaneously. 484 Rate-Derived Convergence Time takes the Convergence Recovery 485 Transition into account, but Loss-Derived Convergence Time 486 ignores the Route Convergence Recovery Transition because 487 it is obtained from the measured Convergence Packet Loss. 489 Ideally, the Convergence Event Transition and Convergence 490 Recovery Transition are instantaneous so that the 491 Rate-Derived Convergence Time = Loss-Derived Convergence Time. 492 However, router implementations are less than ideal. 493 For these reasons the preferred reporting benchmark for IGP 494 Route Convergence is the Rate-Derived Convergence Time. 495 Guidelines for reporting Loss-Derived Convergence Time are 496 provided in [Po07m]. 498 IGP Data Plane Route Convergence 500 Measurement Units: 501 seconds 503 Issues: 504 None 506 See Also: 507 Convergence Event 508 Convergence Packet Loss 509 Rate-Derived Convergence Time 510 Convergence Event Transition 511 Convergence Recovery Transition 513 3.14 Sustained Forwarding Convergence Time 515 Definition: 516 The amount of time for which Full Convergence is maintained 517 without additional packet loss. 519 Discussion: 520 The purpose of the Sustained Forwarding Convergence Time is to 521 produce Convergence benchmarks protected against fluctuation 522 in Throughput after Full Convergence is observed. The 523 Sustained Forwarding Convergence Time to be used is calculated 524 as shown in Equation 3. 526 Equation 3 - 527 Sustained Forwarding Convergence Time = 528 C*(Convergence Packet Loss/Offered Load) 530 where, 531 a. units are packets/pps = sec and 533 b. C is a constant. The RECOMMENDED value for C is 5 as 534 selected from working group consensus. This is similar 535 to RFC 2544 [Ba99] which recommends waiting 2 seconds for 536 residual frames to arrive and 5 seconds for DUT 537 restabilization. 539 c. at least one packet per route in the FIB for all 540 routes in the FIB MUST be offered to the DUT per second. 542 Measurement Units: 543 seconds 545 Issues: None 547 See Also: 548 Full Convergence 549 Convergence Recovery Instant 550 IGP Data Plane Route Convergence 552 3.15 First Prefix Convergence Time 554 Definition: 555 The amount of time for Convergence Packet Loss until the 556 convergence of a first route entry on the Next-Best Egress 557 Interface, as indicated by the First Prefix Convergence 558 Instant. 560 First Prefix Convergence Time can be measured as the time 561 difference from the Convergence Event Instant and the First 562 Prefix Convergence Instant, as shown with Equation 4. 564 (Equation 4) 565 First Prefix Convergence Time = 566 First Prefix Convergence Instant - 567 Convergence Event Instant. 569 Discussion: 570 First Prefix Convergence Time should be measured at the maximum 571 Throughput of the DUT. At least one packet per route in the FIB 572 for all routes in the FIB MUST be offered to the DUT per second. 573 Failure to achieve the First Prefix Convergence Instant results 574 in a First Prefix Convergence Time benchmark of infinity. 576 Measurement Units: 577 hh:mm:ss:nnn:uuu, 578 where 'nnn' is milliseconds and 'uuu' is microseconds. 580 Issues: 581 None 583 See Also: 584 Convergence Packet Loss 585 First Prefix Convergence Instant 587 3.16 Reversion Convergence Time 589 Definition: 590 The amount of time for the DUT to forward traffic from the 591 Preferred Egress Interface, instead of the Next-Best Egress 592 Interface, upon recovery from a Convergence Event. 594 Discussion: 595 Reversion Convergence Time is the amount of time for routes 596 to converge to the original outbound port. This is achieved 597 by recovering from the Convergence Event, such as restoring 598 the failed link. Reversion Convergence Time is measured 599 using the Rate-Derived Convergence Time calculation technique, 600 as provided in Equation 1. It is possible to have the 601 Reversion Convergence Time differ from the Rate-Derived 602 Convergence Time. 604 IGP Data Plane Route Convergence 606 Measurement Units: 607 seconds 609 Issues: 610 None 612 See Also: 613 Preferred Egress Interface 614 Convergence Event 615 Rate-Derived Convergence Time 617 3.17 Packet Sampling Interval 619 Definition: 620 The interval at which the tester (test equipment) polls to make 621 measurements for arriving packet flows. 623 Discussion: 624 Metrics measured at the Packet Sampling Interval MUST include 625 Forwarding Rate and Convergence Packet Loss. 627 Measurement Units: 628 seconds 630 Issues: 631 Packet Sampling Interval can influence the Convergence Graph. 632 This is particularly true when implementations achieve Full 633 Convergence in less than 1 second. The Convergence Event 634 Transition and Convergence Recovery Transition can become 635 exaggerated when the Packet Sampling Interval is too long. 636 This will produce a larger than actual Rate-Derived 637 Convergence Time. The recommended value for configuration 638 of the Packet Sampling Interval is provided in [Po07m]. 640 See Also: 641 Convergence Packet Loss 642 Convergence Event Transition 643 Convergence Recovery Transition 645 3.18 Local Interface 647 Definition: 648 An interface on the DUT. 650 Discussion: 651 A failure of the Local Interface indicates that the failure 652 occured directly on the DUT. 654 IGP Data Plane Route Convergence 656 Measurement Units: 657 N/A 659 Issues: 660 None 662 See Also: 663 Neighbor Interface 664 Remote Interface 666 3.19 Neighbor Interface 668 Definition: 669 The interface on the neighbor router or tester that is 670 directly linked to the DUT's Local Interface. 672 Discussion: 673 None 675 Measurement Units: 676 N/A 678 Issues: 679 None 681 See Also: 682 Local Interface 683 Remote Interface 685 3.20 Remote Interface 687 Definition: 688 An interface on a neighboring router that is not directly 689 connected to any interface on the DUT. 691 Discussion: 692 A failure of a Remote Interface indicates that the failure 693 occurred on an interface that is not directly connected 694 to the DUT. 696 Measurement Units: 697 N/A 699 Issues: 700 None 702 See Also: 703 Local Interface 704 Neighbor Interface 705 IGP Data Plane Route Convergence 707 3.21 Preferred Egress Interface 709 Definition: 710 The outbound interface from the DUT for traffic routed to the 711 preferred next-hop. 713 Discussion: 714 The Preferred Egress Interface is the egress interface prior 715 to a Convergence Event. 717 Measurement Units: 718 N/A 720 Issues: 721 None 723 See Also: 724 Next-Best Egress Interface 726 3.22 Next-Best Egress Interface 728 Definition: 729 The outbound interface from the DUT for traffic routed to the 730 second-best next-hop. It is the same media type and link speed 731 as the Preferred Egress Interface 733 Discussion: 734 The Next-Best Egress Interface becomes the egress interface 735 after a Convergence Event. 737 Measurement Units: 738 N/A 740 Issues: 741 None 743 See Also: 744 Preferred Egress Interface 746 3.23 Stale Forwarding 748 Definition: 749 Forwarding of traffic to route entries that no longer exist 750 or to route entries with next-hops that are no longer preferred. 752 Discussion: 753 Stale Forwarding can be caused by a Convergence Event and is 754 also known as a "black-hole" or microloop since it may produce 755 packet loss. Stale Forwarding exists until Network Convergence 756 is achieved. 758 IGP Data Plane Route Convergence 760 Measurement Units: 761 N/A 763 Issues: 764 None 766 See Also: 767 Network Convergence 769 3.24 Nested Convergence Events 771 Definition: 772 The occurrence of a Convergence Event while the route 773 table is converging from a prior Convergence Event. 775 Discussion: 776 The Convergence Events for a Nested Convergence Event 777 MUST occur with different neighbors. A common 778 observation from a Nested Convergence Event will be 779 the withdrawal of routes from one neighbor while the 780 routes of another neighbor are being installed. 782 Measurement Units: 783 N/A 785 Issues: 786 None 788 See Also: 789 Convergence Event 791 4. IANA Considerations 793 This document requires no IANA considerations. 795 5. Security Considerations 797 Documents of this type do not directly affect the security of 798 Internet or corporate networks as long as benchmarking 799 is not performed on devices or systems connected to production 800 networks. 802 6. Acknowledgements 803 Thanks to Sue Hares, Al Morton, Kevin Dubray, Ron Bonica, David Ward, 804 and the BMWG for their contributions to this work. 806 IGP Data Plane Route Convergence 808 7. References 809 7.1 Normative References 811 [Ba91] Bradner, S. "Benchmarking Terminology for Network 812 Interconnection Devices", RFC1242, July 1991. 814 [Ba99] Bradner, S. and McQuaid, J., "Benchmarking 815 Methodology for Network Interconnect Devices", 816 RFC 2544, March 1999. 818 [Br97] Bradner, S., "Key words for use in RFCs to Indicate 819 Requirement Levels", RFC 2119, March 1997 821 [Ca90] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual 822 Environments", RFC 1195, December 1990. 824 [Ma98] Mandeville, R., "Benchmarking Terminology for LAN 825 Switching Devices", RFC 2285, February 1998. 827 [Mo98] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 829 [Mo06] Morton, A., et al, "Packet Reordering Metrics", RFC 4737, 830 November 2006. 832 [Po06] Poretsky, S., et al., "Terminology for Benchmarking 833 Network-layer Traffic Control Mechanisms", RFC 4689, 834 November 2006. 836 [Po07a] Poretsky, S., "Benchmarking Applicability for Link-State 837 IGP Data Plane Route Convergence", 838 draft-ietf-bmwg-igp-dataplane-conv-app-14, work in progress, 839 November 2007. 841 [Po07m] Poretsky, S. and Imhoff, B., "Benchmarking Methodology for 842 Link-State IGP Data Plane Route Convergence", 843 draft-ietf-bmwg-igp-dataplane-conv-meth-14, work in progress, 844 November 2007. 846 7.2 Informative References 848 [Ca01] S. Casner, C. Alaettinoglu, and C. Kuan, "A Fine-Grained View 849 of High Performance Networking", NANOG 22, June 2001. 851 [Ci03] L. Ciavattone, A. Morton, and G. Ramachandran, "Standardized 852 Active Measurements on a Tier 1 IP Backbone", IEEE 853 Communications Magazine, pp90-97, May 2003. 855 IGP Data Plane Route Convergence 857 8. Author's Address 859 Scott Poretsky 860 Reef Point Systems 861 3 Federal Street 862 Billerica, MA 01821 863 USA 864 Phone: + 1 508 439 9008 865 EMail: sporetsky@reefpoint.com 867 Brent Imhoff 868 Juniper Networks 869 1194 North Mathilda Ave 870 Sunnyvale, CA 94089 871 USA 872 Phone: + 1 314 378 2571 873 EMail: bimhoff@planetspork.com 875 Full Copyright Statement 877 Copyright (C) The IETF Trust (2007). 879 This document is subject to the rights, licenses and restrictions 880 contained in BCP 78, and except as set forth therein, the authors 881 retain all their rights. 883 This document and the information contained herein are provided 884 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 885 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 886 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 887 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 888 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 889 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 890 FOR A PARTICULAR PURPOSE. 892 Intellectual Property 893 The IETF takes no position regarding the validity or scope of any 894 Intellectual Property Rights or other rights that might be claimed to 895 pertain to the implementation or use of the technology described in 896 this document or the extent to which any license under such rights 897 might or might not be available; nor does it represent that it has 898 made any independent effort to identify any such rights. Information 899 on the procedures with respect to rights in RFC documents can be 900 found in BCP 78 and BCP 79. 902 Copies of IPR disclosures made to the IETF Secretariat and any 903 assurances of licenses to be made available, or the result of an 904 attempt made to obtain a general license or permission for the use of 905 such proprietary rights by implementers or users of this 906 specification can be obtained from the IETF on-line IPR repository at 907 http://www.ietf.org/ipr. 909 IGP Data Plane Route Convergence 911 The IETF invites any interested party to bring to its attention any 912 copyrights, patents or patent applications, or other proprietary 913 rights that may cover technology that may be required to implement 914 this standard. Please address the information to the IETF at ietf- 915 ipr@ietf.org. 917 Acknowledgement 918 Funding for the RFC Editor function is currently provided by the 919 Internet Society.