idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-term-08.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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 707. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 718. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 725. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 731. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 695), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** 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 : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** 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 (April 2006) is 6585 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-08 ** 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-08 ** Downref: Normative reference to an Informational draft: draft-ietf-bmwg-igp-dataplane-conv-meth (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 9 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: April 2006 4 Scott Poretsky 5 Reef Point Systems 7 Brent Imhoff 9 October 2005 11 Terminology for Benchmarking 12 IGP Data Plane Route Convergence 14 16 Intellectual Property Rights (IPR) statement: 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Status of this Memo 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Copyright Notice 41 Copyright (C) The Internet Society (2005). All Rights Reserved. 43 ABSTRACT 44 This draft describes the terminology for benchmarking IGP Route 45 Convergence as described in Applicability document [1] and 46 Methodology document [2]. The methodology and terminology is to 47 be used for benchmarking Route Convergence and can be applied to 48 any link-state IGP such as ISIS [3] and OSPF [4]. The data plane 49 is measured to obtain the convergence benchmarking metrics 50 described in [2]. 52 IGP Data Plane Route Convergence 54 Table of Contents 56 1. Introduction .................................................2 57 2. Existing definitions .........................................3 58 3. Term definitions..............................................3 59 3.1 Convergence Event.........................................3 60 3.2 Route Convergence.........................................4 61 3.3 Network Convergence.......................................4 62 3.4 Full Convergence..........................................5 63 3.5 Convergence Packet Loss...................................5 64 3.6 Convergence Event Instant.................................6 65 3.7 Convergence Recovery Instant..............................6 66 3.8 Rate-Derived Convergence Time.............................7 67 3.9 Convergence Event Transition..............................7 68 3.10 Convergence Recovery Transition..........................8 69 3.11 Loss-Derived Convergence Time............................8 70 3.12 Sustained Forwarding Convergence Time....................9 71 3.13 Restoration Convergence Time.............................9 72 3.14 Packet Sampling Interval.................................10 73 3.15 Local Interface..........................................11 74 3.16 Neighbor Interface.......................................11 75 3.17 Remote Interface.........................................11 76 3.18 Preferred Egress Interface...............................12 77 3.19 Next-Best Egress Interface...............................12 78 3.20 Stale Forwarding.........................................13 79 3.21 Nested Convergence Events................................13 80 4. IANA Considerations...........................................13 81 5. Security Considerations.......................................14 82 6. Normative References..........................................14 83 7. Author's Address..............................................14 85 1. Introduction 86 This draft describes the terminology for benchmarking IGP Route 87 Convergence. The motivation and applicability for this 88 benchmarking is provided in [1]. The methodology to be used for 89 this benchmarking is described in [2]. The methodology and 90 terminology to be used for benchmarking Route Convergence can be 91 applied to any link-state IGP such as ISIS [3] and OSPF [4]. The 92 data plane is measured to obtain black-box (externally observable) 93 convergence benchmarking metrics. The purpose of this document is 94 to introduce new terms required to complete execution of the IGP 95 Route Convergence Methodology [2]. These terms apply to IPv4 and 96 IPv6 traffic as well as IPv4 and IPv6 IGPs. 98 An example of Route Convergence as observed and measured from the 99 data plane is shown in Figure 1. The graph in Figure 1 shows 100 Forwarding Rate versus Time. Time 0 on the X-axis is on the far 101 right of the graph. The components of the graph and metrics are 102 defined in the Term Definitions section. 104 IGP Data Plane Route Convergence 106 Convergence Convergence 107 Recovery Event 108 Instant Instant Time = 0sec 109 Maximum ^ ^ ^ 110 Forwarding Rate--> ------\ Packet /--------------- 111 \ Loss /<----Convergence 112 Convergence------->\ / Event Transition 113 Recovery Transition \ / 114 \_____/<------Maximum Packet Loss 116 X-axis = Time 117 Y-axis = Forwarding Rate 118 Figure 1. Convergence Graph 120 2. Existing definitions 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in BCP 14, RFC 2119. 124 RFC 2119 defines the use of these key words to help make the 125 intent of standards track documents as clear as possible. While this 126 document uses these keywords, this document is not a standards track 127 document. 129 3. Term Definitions 130 3.1 Convergence Event 132 Definition: 133 The occurrence of a planned or unplanned action in the network 134 that results in a change in the egress interface of the DUT for 135 routed packets. 137 Discussion: 138 Convergence Events include link loss, routing protocol session 139 loss, router failure, configuration change, and better next-hop 140 learned via a routing protocol. 142 Measurement Units: 143 N/A 145 Issues: 146 None 148 See Also: 149 Convergence Packet Loss 150 Convergence Event Instant 151 IGP Data Plane Route Convergence 153 3.2 Route Convergence 155 Definition: 156 Recovery from a Convergence Event indicated by the DUT 157 forwarding rate equal to the offered load. 159 Discussion: 160 Route Convergence is the action of all components of the router 161 being updated with the most recent route change(s) including the 162 RIB and FIB, along with software and hardware tables. Route 163 Convergence can be observed externally by the rerouting of data 164 Traffic to a new egress interface. 166 Measurement Units: 167 N/A 169 Issues: 170 None 172 See Also: 173 Network Convergence 174 Full Convergence 175 Convergence Event 177 3.3 Network Convergence 179 Definition: 180 The completion of updating of all routing tables, including the 181 FIB, in all routers throughout the network. 183 Discussion: 184 Network Convergence is bounded by the sum of Route Convergence 185 for all routers in the network. Network Convergence can be 186 determined by recovery of the forwarding rate to equal the offered 187 load, no Stale Forwarding, and no blenders[5][6]. 189 Measurement Units: 190 N/A 192 Issues: 193 None 195 See Also: 196 Route Convergence 197 Stale Forwarding 198 IGP Data Plane Route Convergence 200 3.4 Full Convergence 201 Definition: 202 Route Convergence for an entire FIB. 204 Discussion: 205 When benchmarking convergence it is useful to measure 206 the time to converge an entire FIB. For example, 207 a Convergence Event can be produced for an OSPF table of 208 5000 routes so that the time to converge routes 1 through 209 5000 is measured. Full Convergence is externally observable 210 from the data plane when the forwarding rate of the data 211 plane traffic on the Next-Best Egress Interface equals the 212 offered load. 214 Measurement Units: 215 N/A 217 Issues: 218 None 220 See Also: 221 Network Convergence 222 Route Convergence 223 Convergence Event 225 3.5 Convergence Packet Loss 227 Definition: 228 The amount of packet loss produced by a Convergence Event 229 until Route Convergence occurs. 231 Discussion: 232 Packet loss can be observed as a reduction of forwarded traffic from 233 the maximum forwarding rate. Convergence Packet Loss include packets 234 that were lost and packets that were delayed due to buffering. 235 Convergence Packet Loss may or may not reach 100%. 237 Measurement Units: 238 number of packets 240 Issues: 241 None 243 See Also: 244 Route Convergence 245 Convergence Event 246 Rate-Derived Convergence Time 247 Loss-Derived Convergence Time 248 IGP Data Plane Route Convergence 250 3.6 Convergence Event Instant 252 Definition: 253 The time instant that a Convergence Event becomes observable in the 254 data plane. 256 Discussion: 257 Convergence Event Instant is observable from the data 258 plane as the precise time that the device under test begins 259 to exhibit packet loss. 261 Measurement Units: 262 hh:mm:ss:uuu 264 Issues: 265 None 267 See Also: 268 Convergence Event 269 Convergence Packet Loss 270 Convergence Recovery Instant 272 3.7 Convergence Recovery Instant 274 Definition: 275 The time instant that Full Convergence is measured 276 and then maintained for an interval of duration equal to 277 the Sustained Forwarding Convergence Time 279 Discussion: 280 Convergence Recovery Instant is measurable from the data 281 plane as the precise time that the device under test 282 achieves Full Convergence. 284 Measurement Units: 285 hh:mm:ss:uuu 287 Issues: 288 None 290 See Also: 291 Sustained Forwarding Convergence Time 292 Convergence Packet Loss 293 Convergence Event Instant 294 IGP Data Plane Route Convergence 296 3.8 Rate-Derived Convergence Time 297 Definition: 298 The amount of time for Convergence Packet Loss to persist upon 299 occurrence of a Convergence Event until occurrence of Route 300 Convergence. 302 Rate-Derived Convergence Time can be measured as the time 303 difference from the Convergence Event Instant to the 304 Convergence Recovery Instant, as shown with Equation 1. 306 (eq 1) Rate-Derived Convergence Time = 307 Convergence Recovery Instant - Convergence Event Instant. 309 Discussion: 310 Rate-Derived Convergence Time should be measured at the maximum 311 forwarding rate. Failure to achieve Full Convergence results in 312 a Rate-Derived Convergence Time benchmark of infinity. 314 Measurement Units: 315 seconds/milliseconds 317 Issues: 318 None 320 See Also: 321 Convergence Packet Loss 322 Convergence Recovery Instant 323 Convergence Event Instant 324 Full Convergence 326 3.9 Convergence Event Transition 327 Definition: 328 The characteristic of a router in which forwarding rate 329 gradually reduces to zero after a Convergence Event. 331 Discussion: 332 The Convergence Event Transition is best observed for 333 Full Convergence. The Convergence Event Transition may 334 not be linear. 336 Measurement Units: 337 seconds/milliseconds 339 Issues: 340 None 342 See Also: 343 Convergence Event 344 Rate-Derived Convergence Time 345 Convergence Packet Loss 346 Convergence Recovery Transition 347 IGP Data Plane Route Convergence 349 3.10 Convergence Recovery Transition 351 Definition: 352 The characteristic of a router in which forwarding rate 353 gradually increases to equal the offered load. 355 Discussion: 356 The Convergence Recovery Transition is best observed for 357 Full Convergence. The Convergence Event Transition may 358 not be linear. 360 Measurement Units: 361 seconds/milliseconds 363 Issues: 364 None 366 See Also: 367 Full Convergence 368 Rate-Derived Convergence Time 369 Convergence Packet Loss 370 Convergence Event Transition 372 3.11 Loss-Derived Convergence Time 374 Definition: 375 The amount of time it takes for Route Convergence to 376 to be achieved as calculated from the Convergence Packet 377 Loss. Loss-Derived Convergence Time can be calculated 378 from Convergence Packet Loss that occurs due to a 379 Convergence Event and Route Convergence.as shown with 380 Equation 2. 382 (eq 2) Loss-Derived Convergence Time = 383 Convergence Packets Loss / Offered Load 384 NOTE: Units for this measurement are 385 packets / packets/second = seconds 387 Discussion: 388 Loss-Derived Convergence Time gives a better than 389 actual result when converging many routes simultaneously. 390 Rate-Derived Convergence Time takes the Convergence Recovery 391 Transition into account, but Loss-Derived Convergence Time 392 ignores the Route Convergence Recovery Transition because 393 it is obtained from the measured Convergence Packet Loss. 394 Ideally, the Convergence Event Transition and Convergence 395 Recovery Transition are instantaneous so that the 396 Rate-Derived Convergence Time = Loss-Derived Convergence Time. 397 However, router implementations are less than ideal. 398 For these reasons the preferred reporting benchmark for IGP 399 Route Convergence is the Rate-Derived Convergence Time. 401 IGP Data Plane Route Convergence 403 Guidelines for reporting Loss-Derived Convergence Time are 404 provided in [2]. 406 Measurement Units: 407 seconds/milliseconds 409 Issues: 410 None 412 See Also: 413 Route Convergence 414 Convergence Packet Loss 415 Rate-Derived Convergence Time 416 Convergence Event Transition 417 Convergence Recovery Transition 419 3.12 Sustained Forwarding Convergence Time 421 Definition: 422 The amount of time for which Full Convergence is maintained 423 without additional packet loss. 425 Discussion: 426 The purpose of the Sustained Forwarding Convergence Time is to 427 produce Convergence Time benchmarks protected against fluctuation 428 in Forwarding Rate after Full Convergence is observed. The 429 Sustained Forwarding Convergence Time to be used is calculated 430 as shown in Equation 3. 432 (eq 3) 433 Sustained Forwarding Convergence Time = 434 5 x (# routes in FIB) / (Offered Load) 436 for which at least one packet per destination MUST be received 437 at the DUT. 439 Measurement Units: 440 seconds or milliseconds 442 Issues: None 444 See Also: 445 Full Convergence 446 Convergence Recovery Instant 448 3.13 Restoration Convergence Time 449 Definition: 450 The amount of time for the router under test to restore 451 traffic to the original outbound port after recovery from 452 a Convergence Event. 454 IGP Data Plane Route Convergence 456 Discussion: 457 Restoration Convergence Time is the amount of time to 458 Converge back to the original outbound port. This is achieved 459 by recovering from the Convergence Event, such as restoring 460 the failed link. Restoration Convergence Time is measured 461 using the Rate-Derived Convergence Time calculation technique, 462 as provided in Equation 1. It is possible, but not desired 463 to have the Restoration Convergence Time differ from the 464 Rate-Derived Convergence Time. 466 Measurement Units: 467 seconds or milliseconds 469 Issues: 470 None 472 See Also: 473 Convergence Event 474 Rate-Derived Convergence Time 476 3.14 Packet Sampling Interval 477 Definition: 478 The interval at which the tester (test equipment) polls to make 479 measurements for arriving packet flows. 481 Discussion: 482 Metrics measured at the Packet Sampling Interval may include 483 Forwarding Rate and Convergence Packet Loss. 485 Measurement Units: 486 seconds or milliseconds 488 Issues: 489 Packet Sampling Interval can influence the Convergence Graph. 490 This is particularly true as implementations achieve Full 491 Convergence in less than 1 second. The Convergence Event 492 Transition and Convergence Recovery Transition can become 493 exaggerated when the Packet Sampling Interval is too long. 494 This will produce a larger than actual Rate-Derived 495 Convergence Time. The recommended value for configuration 496 of the Packet Sampling Interval is provided in [2]. 498 See Also: 499 Convergence Packet Loss 500 Convergence Event Transition 501 Convergence Recovery Transition 502 IGP Data Plane Route Convergence 504 3.15 Local Interface 505 Definition: 506 An interface on the DUT. 508 Discussion: 509 None 511 Measurement Units: 512 N/A 514 Issues: 515 None 517 See Also: 518 Neighbor Interface 519 Remote Interface 521 3.16 Neighbor Interface 523 Definition: 524 The interface on the neighbor router or tester that is 525 directly linked to the DUT's Local Interface. 527 Discussion: 528 None 530 Measurement Units: 531 N/A 533 Issues: 534 None 536 See Also: 537 Local Interface 538 Remote Interface 540 3.17 Remote Interface 542 Definition: 543 An interface on a neighboring router that is not directly 544 connected to any interface on the DUT. 546 Discussion: 547 None 549 Measurement Units: 550 N/A 552 Issues: 553 None 554 IGP Data Plane Route Convergence 556 See Also: 557 Local Interface 558 Neighbor Interface 560 3.18 Preferred Egress Interface 562 Definition: 563 The outbound interface from the DUT for traffic routed to the 564 preferred next-hop. 566 Discussion: 567 Preferred Egress Interface is the egress interface prior to 568 a Convergence Event 570 Measurement Units: 571 N/A 573 Issues: 574 None 576 See Also: 577 Next-Best Egress Interface 579 3.19 Next-Best Egress Interface 581 Definition: 582 The outbound interface from the DUT for traffic routed to the 583 second-best next-hop. It is the same media type and link speed 584 as the Preferred Egress Interface 586 Discussion: 587 Next-Best Egress Interface is the egress interface after 588 a Convergence Event. 590 Measurement Units: 591 N/A 593 Issues: 594 None 596 See Also: 597 Preferred Egress Interface 598 IGP Data Plane Route Convergence 600 3.20 Stale Forwarding 602 Definition: 603 Forwarding of traffic to route entries that no longer exist 604 or to route entries with next-hops that are no longer preferred. 606 Discussion: 607 Stale Forwarding can be caused by a Convergence Event and is 608 also known as a "black-hole" since it may produce packet loss. 609 Stale Forwarding exists until Network Convergence is achieved. 611 Measurement Units: 612 N/A 614 Issues: 615 None 617 See Also: 618 Network Convergence 620 3.21 Nested Convergence Events 622 Definition: 623 The occurence of Convergence Event while the route table 624 is converging from a prior Convergence Event. 626 Discussion: 627 The Convergence Events for a Nested Convergence Events 628 MUST occur with different neighbors. A common 629 observation from a Nested Convergence Event will be 630 the withdrawal of routes from one neighbor while the 631 routes of another neighbor are being installed. 633 Measurement Units: 634 N/A 636 Issues: 637 None 639 See Also: 640 Convergence Event 642 4. IANA Considerations 644 This document requires no IANA considerations. 646 IGP Data Plane Route Convergence 648 5. Security Considerations 650 Documents of this type do not directly affect the security of 651 Internet or corporate networks as long as benchmarking 652 is not performed on devices or systems connected to production 653 networks. 655 6. Normative References 657 [1] Poretsky, S., "Benchmarking Applicability for IGP Data Plane 658 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-app-08, 659 work in progress, October 2005. 661 [2] Poretsky, S., "Benchmarking Methodology for IGP Data Plane 662 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-meth-08, 663 work in progress, October 2005. 665 [3] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual 666 Environments", RFC 1195, December 1990. 668 [4] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 670 [5] S. Casner, C. Alaettinoglu, and C. Kuan, "A Fine-Grained View 671 of High Performance Networking", NANOG 22, June 2001. 673 [6] L. Ciavattone, A. Morton, and G. Ramachandran, "Standardized 674 Active Measurements on a Tier 1 IP Backbone", IEEE 675 Communications Magazine, pp90-97, May 2003. 677 7. Author's Address 679 Scott Poretsky 680 Reef Point Systems 681 8 New England Executive Park 682 Burlington, MA 01803 683 USA 685 Phone: + 1 508 439 9008 686 EMail: sporetsky@reefpoint.com 688 Brent Imhoff 689 USA 690 EMail: bimhoff@planetspork.com 691 IGP Data Plane Route Convergence 693 Full Copyright Statement 695 Copyright (C) The Internet Society (2005). 697 This document is subject to the rights, licenses and restrictions 698 contained in BCP 78, and except as set forth therein, the authors 699 retain all their rights. 701 This document and the information contained herein are provided on an 702 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 703 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 704 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 705 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 706 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 707 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 709 Intellectual Property 711 The IETF takes no position regarding the validity or scope of any 712 Intellectual Property Rights or other rights that might be claimed to 713 pertain to the implementation or use of the technology described in 714 this document or the extent to which any license under such rights 715 might or might not be available; nor does it represent that it has 716 made any independent effort to identify any such rights. Information 717 on the procedures with respect to rights in RFC documents can be 718 found in BCP 78 and BCP 79. 720 Copies of IPR disclosures made to the IETF Secretariat and any 721 assurances of licenses to be made available, or the result of an 722 attempt made to obtain a general license or permission for the use of 723 such proprietary rights by implementers or users of this 724 specification can be obtained from the IETF on-line IPR repository at 725 http://www.ietf.org/ipr. 727 The IETF invites any interested party to bring to its attention any 728 copyrights, patents or patent applications, or other proprietary 729 rights that may cover technology that may be required to implement 730 this standard. Please address the information to the IETF at ietf- 731 ipr@ietf.org. 733 Acknowledgement 735 Funding for the RFC Editor function is currently provided by the 736 Internet Society.