idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-term-09.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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 719. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 729. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 736. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 742. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document 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 (June 2006) is 6524 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-17) exists of draft-ietf-bmwg-igp-dataplane-conv-app-09 ** Downref: Normative reference to an Informational draft: draft-ietf-bmwg-igp-dataplane-conv-app (ref. '1') == Outdated reference: A later version (-23) exists of draft-ietf-bmwg-igp-dataplane-conv-meth-09 ** Downref: Normative reference to an Informational draft: draft-ietf-bmwg-igp-dataplane-conv-meth (ref. '2') Summary: 6 errors (**), 0 flaws (~~), 4 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: June 2006 4 Scott Poretsky 5 Reef Point Systems 7 Brent Imhoff 8 Juniper Networks 10 January 2006 12 Terminology for Benchmarking 13 IGP Data Plane Route Convergence 15 17 Intellectual Property Rights (IPR) statement: 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Status of this Memo 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 ABSTRACT 45 This document describes the terminology for benchmarking IGP 46 Route Convergence as described in Applicability document [1] and 47 Methodology document [2]. The methodology and terminology are to 48 be used for benchmarking Convergence Time and can be applied to 49 any link-state IGP such as ISIS [3] and OSPF [4]. The data plane 50 is measured to obtain the convergence benchmarking metrics 51 described in [2]. 53 IGP Data Plane Route Convergence 55 Table of Contents 57 1. Introduction .................................................2 58 2. Existing definitions .........................................3 59 3. Term definitions..............................................3 60 3.1 Convergence Event.........................................3 61 3.2 Route Convergence.........................................4 62 3.3 Network Convergence.......................................4 63 3.4 Full Convergence..........................................5 64 3.5 Convergence Packet Loss...................................5 65 3.6 Convergence Event Instant.................................6 66 3.7 Convergence Recovery Instant..............................6 67 3.8 Rate-Derived Convergence Time.............................7 68 3.9 Convergence Event Transition..............................7 69 3.10 Convergence Recovery Transition..........................8 70 3.11 Loss-Derived Convergence Time............................8 71 3.12 Sustained Forwarding Convergence Time....................9 72 3.13 Restoration Convergence Time.............................9 73 3.14 Packet Sampling Interval.................................10 74 3.15 Local Interface..........................................11 75 3.16 Neighbor Interface.......................................11 76 3.17 Remote Interface.........................................11 77 3.18 Preferred Egress Interface...............................12 78 3.19 Next-Best Egress Interface...............................12 79 3.20 Stale Forwarding.........................................13 80 3.21 Nested Convergence Events................................13 81 4. IANA Considerations...........................................13 82 5. Security Considerations.......................................14 83 6. Normative References..........................................14 84 7. Author's Address..............................................14 86 1. Introduction 87 This draft describes the terminology for benchmarking IGP Route 88 Convergence. The motivation and applicability for this 89 benchmarking is provided in [1]. The methodology to be used for 90 this benchmarking is described in [2]. The methodology and 91 terminology to be used for benchmarking Route Convergence can be 92 applied to any link-state IGP such as ISIS [3] and OSPF [4]. The 93 data plane is measured to obtain black-box (externally observable) 94 convergence benchmarking metrics. The purpose of this document is 95 to introduce new terms required to complete execution of the IGP 96 Route Convergence Methodology [2]. These terms apply to IPv4 and 97 IPv6 traffic as well as IPv4 and IPv6 IGPs. 99 An example of Route Convergence as observed and measured from the 100 data plane is shown in Figure 1. The graph in Figure 1 shows 101 Throughput versus Time. Time 0 on the X-axis is on the far 102 right of the graph. The components of the graph and metrics are 103 defined in the Term Definitions section. 105 IGP Data Plane Route Convergence 107 Convergence Convergence 108 Recovery Event 109 Instant Instant Time = 0sec 110 Maximum ^ ^ ^ 111 Throughput--> ------\ Packet /--------------- 112 \ Loss /<----Convergence 113 Convergence------->\ / Event Transition 114 Recovery Transition \ / 115 \_____/<------Maximum Packet Loss 117 X-axis = Time 118 Y-axis = Throughput 119 Figure 1. Convergence Graph 121 2. Existing definitions 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in BCP 14, RFC 2119. 125 RFC 2119 defines the use of these key words to help make the 126 intent of standards track documents as clear as possible. While this 127 document uses these keywords, this document is not a standards track 128 document. The term Throughput is defined in RFC 2544. 130 3. Term Definitions 131 3.1 Convergence Event 133 Definition: 134 The occurrence of a planned or unplanned action in the network 135 that results in a change in the egress interface of the Device 136 Under Test (DUT) for 137 routed packets. 139 Discussion: 140 Convergence Events include link loss, routing protocol session 141 loss, router failure, configuration change, and better next-hop 142 learned via a routing protocol. 144 Measurement Units: 145 N/A 147 Issues: 148 None 150 See Also: 151 Convergence Packet Loss 152 Convergence Event Instant 153 IGP Data Plane Route Convergence 155 3.2 Route Convergence 157 Definition: 158 Recovery from a Convergence Event indicated by the DUT 159 Throughput equal to the offered load. 161 Discussion: 162 Route Convergence is the action of all components of the router 163 being updated with the most recent route change(s) including the 164 Routing Information Base (RIB) and Forwaridng Information Base 165 (FIB), along with software and hardware tables. Route 166 Convergence can be observed externally by the rerouting of data 167 Traffic to a new egress interface. 169 Measurement Units: 170 N/A 172 Issues: 173 None 175 See Also: 176 Network Convergence 177 Full Convergence 178 Convergence Event 180 3.3 Network Convergence 182 Definition: 183 The completion of updating of all routing tables, including the 184 FIB, in all routers throughout the network. 186 Discussion: 187 Network Convergence is bounded by the sum of Route Convergence 188 for all routers in the network. Network Convergence can be 189 determined by recovery of the Throughput to equal the 190 offered load, with no Stale Forwarding, and no blenders[5][6]. 192 Measurement Units: 193 N/A 195 Issues: 196 None 198 See Also: 199 Route Convergence 200 Stale Forwarding 201 IGP Data Plane Route Convergence 203 3.4 Full Convergence 204 Definition: 205 Route Convergence for an entire FIB. 207 Discussion: 208 When benchmarking convergence, it is useful to measure 209 the time to converge an entire FIB. For example, 210 a Convergence Event can be produced for an OSPF table of 211 5000 routes so that the time to converge routes 1 through 212 5000 is measured. Full Convergence is externally observable 213 from the data plane when the Throughput of the data 214 plane traffic on the Next-Best Egress Interface equals the 215 offered load. 217 Measurement Units: 218 N/A 220 Issues: None 222 See Also: 223 Network Convergence 224 Route Convergence 225 Convergence Event 227 3.5 Convergence Packet Loss 229 Definition: 230 The amount of packet loss produced by a Convergence Event 231 until Route Convergence occurs. 233 Discussion: 234 Packet loss can be observed as a reduction of forwarded traffic 235 from the maximum Throughput. Convergence Packet Loss 236 includes packets that were lost and packets that were delayed 237 due to buffering. The maximum Convergence Packet Loss observed 238 in a Packet Sampling Interval may or may not reach 100% during 239 Route Convergence (see Figure 1). 241 Measurement Units: 242 number of packets 244 Issues: None 246 See Also: 247 Route Convergence 248 Convergence Event 249 Rate-Derived Convergence Time 250 Loss-Derived Convergence Time 251 Packet Sampling Interval 252 IGP Data Plane Route Convergence 254 3.6 Convergence Event Instant 256 Definition: 257 The time instant that a Convergence Event becomes observable in 258 the data plane. 260 Discussion: 261 Convergence Event Instant is observable from the data 262 plane as the precise time that the device under test begins 263 to exhibit packet loss. 265 Measurement Units: 266 hh:mm:ss:nnn, where 'nnn' is milliseconds 268 Issues: 269 None 271 See Also: 272 Convergence Event 273 Convergence Packet Loss 274 Convergence Recovery Instant 276 3.7 Convergence Recovery Instant 278 Definition: 279 The time instant that Full Convergence is measured 280 and then maintained for an interval of duration equal to 281 the Sustained Forwarding Convergence Time 283 Discussion: 284 Convergence Recovery Instant is measurable from the data 285 plane as the precise time that the device under test 286 achieves Full Convergence. 288 Measurement Units: 289 hh:mm:ss:uuu 291 Issues: 292 None 294 See Also: 295 Sustained Forwarding Convergence Time 296 Convergence Packet Loss 297 Convergence Event Instant 298 IGP Data Plane Route Convergence 300 3.8 Rate-Derived Convergence Time 301 Definition: 302 The amount of time for Convergence Packet Loss to persist upon 303 occurrence of a Convergence Event until occurrence of Route 304 Convergence. 306 Rate-Derived Convergence Time can be measured as the time 307 difference from the Convergence Event Instant to the 308 Convergence Recovery Instant, as shown with Equation 1. 310 (eq 1) Rate-Derived Convergence Time = 311 Convergence Recovery Instant - Convergence Event Instant. 313 Discussion: 314 Rate-Derived Convergence Time should be measured at the maximum 315 Throughput. Failure to achieve Full Convergence results in 316 a Rate-Derived Convergence Time benchmark of infinity. 318 Measurement Units: 319 seconds/milliseconds 321 Issues: 322 None 324 See Also: 325 Convergence Packet Loss 326 Convergence Recovery Instant 327 Convergence Event Instant 328 Full Convergence 330 3.9 Convergence Event Transition 331 Definition: 332 The characteristic of a router in which Throughput 333 gradually reduces to zero after a Convergence Event. 335 Discussion: 336 The Convergence Event Transition is best observed for 337 Full Convergence. The Convergence Event Transition may 338 not be linear. 340 Measurement Units: 341 seconds/milliseconds 343 Issues: 344 None 346 See Also: 347 Convergence Event 348 Rate-Derived Convergence Time 349 Convergence Packet Loss 350 Convergence Recovery Transition 351 IGP Data Plane Route Convergence 353 3.10 Convergence Recovery Transition 355 Definition: 356 The characteristic of a router in which Throughput 357 gradually increases to equal the offered load. 359 Discussion: 360 The Convergence Recovery Transition is best observed for 361 Full Convergence. The Convergence Event Transition may 362 not be linear. 364 Measurement Units: 365 seconds/milliseconds 367 Issues: 368 None 370 See Also: 371 Full Convergence 372 Rate-Derived Convergence Time 373 Convergence Packet Loss 374 Convergence Event Transition 376 3.11 Loss-Derived Convergence Time 378 Definition: 379 The amount of time it takes for Route Convergence to 380 to be achieved as calculated from the Convergence Packet 381 Loss. Loss-Derived Convergence Time can be calculated 382 from Convergence Packet Loss that occurs due to a 383 Convergence Event and Route Convergence.as shown with 384 Equation 2. 386 (eq 2) Loss-Derived Convergence Time = 387 Convergence Packets Loss / Offered Load 388 NOTE: Units for this measurement are 389 packets / packets/second = seconds 391 Discussion: 392 Loss-Derived Convergence Time gives a better than 393 actual result when converging many routes simultaneously. 394 Rate-Derived Convergence Time takes the Convergence Recovery 395 Transition into account, but Loss-Derived Convergence Time 396 ignores the Route Convergence Recovery Transition because 397 it is obtained from the measured Convergence Packet Loss. 398 Ideally, the Convergence Event Transition and Convergence 399 Recovery Transition are instantaneous so that the 400 Rate-Derived Convergence Time = Loss-Derived Convergence Time. 401 However, router implementations are less than ideal. 402 For these reasons the preferred reporting benchmark for IGP 403 Route Convergence is the Rate-Derived Convergence Time. 405 IGP Data Plane Route Convergence 407 Guidelines for reporting Loss-Derived Convergence Time are 408 provided in [2]. 410 Measurement Units: 411 seconds/milliseconds 413 Issues: 414 None 416 See Also: 417 Route Convergence 418 Convergence Packet Loss 419 Rate-Derived Convergence Time 420 Convergence Event Transition 421 Convergence Recovery Transition 423 3.12 Sustained Forwarding Convergence Time 425 Definition: 426 The amount of time for which Full Convergence is maintained 427 without additional packet loss. 429 Discussion: 430 The purpose of the Sustained Forwarding Convergence Time is to 431 produce Convergence benchmarks protected against fluctuation 432 in Throughput after Full Convergence is observed. The 433 Sustained Forwarding Convergence Time to be used is calculated 434 as shown in Equation 3. 436 (eq 3) 437 Sustained Forwarding Convergence Time = 5 packets/Offered Load 438 units are packets/pps = sec 440 for which at least one packet per route in the FIB for all 441 routes in the FIB MUST be offered to the DUT per second. 443 Measurement Units: 444 seconds or milliseconds 446 Issues: None 448 See Also: 449 Full Convergence 450 Convergence Recovery Instant 452 3.13 Restoration Convergence Time 453 Definition: 454 The amount of time for the router under test to restore 455 traffic to the original outbound port after recovery from 456 a Convergence Event. 458 IGP Data Plane Route Convergence 460 Discussion: 461 Restoration Convergence Time is the amount of time for routes 462 to converge to the original outbound port. This is achieved 463 by recovering from the Convergence Event, such as restoring 464 the failed link. Restoration Convergence Time is measured 465 using the Rate-Derived Convergence Time calculation technique, 466 as provided in Equation 1. It is possible to have the 467 Restoration Convergence Time differ from the Rate-Derived 468 Convergence Time. 470 Measurement Units: 471 seconds or milliseconds 473 Issues: 474 None 476 See Also: 477 Convergence Event 478 Rate-Derived Convergence Time 480 3.14 Packet Sampling Interval 481 Definition: 482 The interval at which the tester (test equipment) polls to make 483 measurements for arriving packet flows. 485 Discussion: 486 Metrics measured at the Packet Sampling Interval may include 487 Throughput and Convergence Packet Loss. 489 Measurement Units: 490 seconds or milliseconds 492 Issues: 493 Packet Sampling Interval can influence the Convergence Graph. 494 This is particularly true when implementations achieve Full 495 Convergence in less than 1 second. The Convergence Event 496 Transition and Convergence Recovery Transition can become 497 exaggerated when the Packet Sampling Interval is too long. 498 This will produce a larger than actual Rate-Derived 499 Convergence Time. The recommended value for configuration 500 of the Packet Sampling Interval is provided in [2]. 502 See Also: 503 Convergence Packet Loss 504 Convergence Event Transition 505 Convergence Recovery Transition 506 IGP Data Plane Route Convergence 508 3.15 Local Interface 509 Definition: 510 An interface on the DUT. 512 Discussion: 513 None 515 Measurement Units: 516 N/A 518 Issues: 519 None 521 See Also: 522 Neighbor Interface 523 Remote Interface 525 3.16 Neighbor Interface 527 Definition: 528 The interface on the neighbor router or tester that is 529 directly linked to the DUT's Local Interface. 531 Discussion: 532 None 534 Measurement Units: 535 N/A 537 Issues: 538 None 540 See Also: 541 Local Interface 542 Remote Interface 544 3.17 Remote Interface 546 Definition: 547 An interface on a neighboring router that is not directly 548 connected to any interface on the DUT. 550 Discussion: 551 None 553 Measurement Units: 554 N/A 556 Issues: 557 None 558 IGP Data Plane Route Convergence 560 See Also: 561 Local Interface 562 Neighbor Interface 564 3.18 Preferred Egress Interface 566 Definition: 567 The outbound interface from the DUT for traffic routed to the 568 preferred next-hop. 570 Discussion: 571 The Preferred Egress Interface is the egress interface prior 572 to a Convergence Event. 574 Measurement Units: 575 N/A 577 Issues: 578 None 580 See Also: 581 Next-Best Egress Interface 583 3.19 Next-Best Egress Interface 585 Definition: 586 The outbound interface from the DUT for traffic routed to the 587 second-best next-hop. It is the same media type and link speed 588 as the Preferred Egress Interface 590 Discussion: 591 The Next-Best Egress Interface becomes the egress interface 592 after a Convergence Event. 594 Measurement Units: 595 N/A 597 Issues: 598 None 600 See Also: 601 Preferred Egress Interface 602 IGP Data Plane Route Convergence 604 3.20 Stale Forwarding 606 Definition: 607 Forwarding of traffic to route entries that no longer exist 608 or to route entries with next-hops that are no longer preferred. 610 Discussion: 611 Stale Forwarding can be caused by a Convergence Event and is 612 also known as a "black-hole" since it may produce packet loss. 613 Stale Forwarding exists until Network Convergence is achieved. 615 Measurement Units: 616 N/A 618 Issues: 619 None 621 See Also: 622 Network Convergence 624 3.21 Nested Convergence Events 626 Definition: 627 The occurence of Convergence Event while the route table 628 is converging from a prior Convergence Event. 630 Discussion: 631 The Convergence Events for a Nested Convergence Events 632 MUST occur with different neighbors. A common 633 observation from a Nested Convergence Event will be 634 the withdrawal of routes from one neighbor while the 635 routes of another neighbor are being installed. 637 Measurement Units: 638 N/A 640 Issues: 641 None 643 See Also: 644 Convergence Event 646 4. IANA Considerations 648 This document requires no IANA considerations. 650 IGP Data Plane Route Convergence 652 5. Security Considerations 654 Documents of this type do not directly affect the security of 655 Internet or corporate networks as long as benchmarking 656 is not performed on devices or systems connected to production 657 networks. 659 6. References 660 6.1 Normative References 662 [1] Poretsky, S., "Benchmarking Applicability for IGP Data Plane 663 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-app-09, 664 work in progress, January 2006. 666 [2] Poretsky, S., "Benchmarking Methodology for IGP Data Plane 667 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-meth-09, 668 work in progress, January 2006. 670 [3] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual 671 Environments", RFC 1195, December 1990. 673 [4] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 675 6.2 Informative References 677 [5] S. Casner, C. Alaettinoglu, and C. Kuan, "A Fine-Grained View 678 of High Performance Networking", NANOG 22, June 2001. 680 [6] L. Ciavattone, A. Morton, and G. Ramachandran, "Standardized 681 Active Measurements on a Tier 1 IP Backbone", IEEE 682 Communications Magazine, pp90-97, May 2003. 684 7. Author's Address 686 Scott Poretsky 687 Reef Point Systems 688 8 New England Executive Park 689 Burlington, MA 01803 690 USA 692 Phone: + 1 508 439 9008 693 EMail: sporetsky@reefpoint.com 694 IGP Data Plane Route Convergence 696 Brent Imhoff 697 Juniper Networks 698 1194 North Mathilda Ave 699 Sunnyvale, CA 94089 700 USA 702 Phone: + 1 314 378 2571 703 EMail: bimhoff@planetspork.com 705 Full Copyright Statement 707 Copyright (C) The Internet Society (2006). 709 This document is subject to the rights, licenses and restrictions 710 contained in BCP 78, and except as set forth therein, the authors 711 retain all their rights. 713 This document and the information contained herein are provided on an 714 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 715 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 716 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 717 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 718 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 719 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 721 Intellectual Property 722 The IETF takes no position regarding the validity or scope of any 723 Intellectual Property Rights or other rights that might be claimed to 724 pertain to the implementation or use of the technology described in 725 this document or the extent to which any license under such rights 726 might or might not be available; nor does it represent that it has 727 made any independent effort to identify any such rights. Information 728 on the procedures with respect to rights in RFC documents can be 729 found in BCP 78 and BCP 79. 731 Copies of IPR disclosures made to the IETF Secretariat and any 732 assurances of licenses to be made available, or the result of an 733 attempt made to obtain a general license or permission for the use of 734 such proprietary rights by implementers or users of this 735 specification can be obtained from the IETF on-line IPR repository at 736 http://www.ietf.org/ipr. 738 The IETF invites any interested party to bring to its attention any 739 copyrights, patents or patent applications, or other proprietary 740 rights that may cover technology that may be required to implement 741 this standard. Please address the information to the IETF at ietf- 742 ipr@ietf.org. 744 Acknowledgement 745 Funding for the RFC Editor function is currently provided by the 746 Internet Society.