idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-term-04.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 3667, Section 5.1 on line 21. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 668. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 11) being 75 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 4. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 7 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], [5], [6], [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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 2005) is 6922 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) -- Missing reference section? '1' on line 618 looks like a reference -- Missing reference section? '2' on line 622 looks like a reference -- Missing reference section? '3' on line 626 looks like a reference -- Missing reference section? '4' on line 629 looks like a reference -- Missing reference section? '5' on line 631 looks like a reference -- Missing reference section? '6' on line 634 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 5 warnings (==), 10 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 2005 4 Scott Poretsky 5 Quarry Technologies 7 Brent Imhoff 8 LightCore 10 October 2004 12 Terminology for Benchmarking 13 IGP Data Plane Route Convergence 15 17 Intellectual Property Rights (IPR) statement: 18 By submitting this Internet-Draft, I certify that any applicable 19 patent or other IPR claims of which I am aware have been disclosed, or 20 will be disclosed, and any of which I become aware will be disclosed, 21 in accordance with RFC 3668. 23 Status of this Memo 25 This document is an Internet-Draft and is in full conformance with 26 all provisions of Section 10 of RFC2026. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other 35 documents at any time. It is inappropriate to use Internet-Drafts 36 as reference material or to cite them other than as "work in 37 progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 ABSTRACT 46 This draft describes the terminology for benchmarking IGP Route 47 Convergence as described in Applicability document [1] and 48 Methodology document [2]. The methodology and terminology is to 49 be used for benchmarking Route Convergence and can be applied to 50 any link-state IGP such as ISIS [3] and OSPF [4]. The data plane 51 is measured to obtain the convergence benchmarking metrics 52 described in [2]. 54 IGP Data Plane Route Convergence 56 Table of Contents 58 1. Introduction .................................................2 59 2. Existing definitions .........................................3 60 3. Term definitions..............................................3 61 3.1 Convergence Event.........................................3 62 3.2 Route Convergence.........................................4 63 3.3 Network Convergence.......................................4 64 3.4 Full Convergence..........................................5 65 3.5 Convergence Packet Loss...................................5 66 3.6 Convergence Event Instant.................................6 67 3.7 Convergence Recovery Instant..............................6 68 3.8 Rate-Derived Convergence Time.............................7 69 3.9 Convergence Event Transition..............................7 70 3.10 Convergence Recovery Transition..........................8 71 3.11 Loss-Derived Convergence Time............................8 72 3.12 Sustained Forwarding Convergence Time....................9 73 3.13 Restoration Convergence Time.............................9 74 3.14 Packet Sampling Interval.................................10 75 3.15 Local Interface..........................................10 76 3.16 Neighbor Interface.......................................11 77 3.17 Remote Interface........................................11 78 3.18 Preferred Egress Interface...............................11 79 3.19 Next-Best Egress Interface..............................12 80 3.20 Stale Forwarding.........................................12 81 4. Security Considerations.......................................13 82 5. References....................................................13 83 6. Author's Address..............................................13 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]. 97 An example of Route Convergence as observed and measured from the 98 data plane is shown in Figure 1. The graph in Figure 1 shows 99 Forwarding Rate versus Time. Time 0 on the X-axis is on the far 100 right of the graph. The components of the graph and metrics are 101 defined in the Term Definitions section. 103 IGP Data Plane Route Convergence 105 Convergence Convergence 106 Recovery Event 107 Instant Instant Time = 0sec 108 Maximum ^ ^ ^ 109 Forwarding Rate--> ----\ Packet /--------------- 110 \ Loss /<----Convergence 111 Convergence------->\ / Event Transition 112 Recovery Transition \ / 113 \_____/<------Packet Loss 115 X-axis = Time 116 Y-axis = Forwarding Rate 117 Figure 1. Convergence Graph 119 2. Existing definitions 120 For the sake of clarity and continuity this RFC adopts the template 121 for definitions set out in Section 2 of RFC 1242. Definitions are 122 indexed and grouped together in sections for ease of reference. 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 125 this document are to be interpreted as described in RFC 2119. 127 3. Term Definitions 129 3.1 Convergence Event 131 Definition: 132 The occurrence of a planned or unplanned action in the network 133 that results in a change in the egress interface of the DUT for 134 routed packets. 136 Discussion: 137 Convergence Events include link loss, routing protocol session 138 loss, router failure, configuration change, and better next-hop 139 learned via a routing protocol. 141 Measurement Units: 142 N/A 144 Issues: 145 None 147 See Also: 148 Convergence Packet Loss 149 Convergence Event Instant 150 IGP Data Plane Route Convergence 152 3.2 Route Convergence 154 Definition: 155 Recovery from a Convergence Event indicated by the DUT 156 forwarding rate equal to the offered load. 158 Discussion: 159 Route Convergence is the action of all components of the router 160 being updated with the most recent route change(s) including the 161 RIB and FIB, along with software and hardware tables. Route 162 Convergence can be observed externally by the rerouting of data 163 Traffic to a new egress interface. 165 Measurement Units: 166 N/A 168 Issues: 169 None 171 See Also: 172 Network Convergence 173 Full Convergence 174 Convergence Event 176 3.3 Network Convergence 178 Definition: 179 The completion of updating of all routing tables, including the 180 FIB, in all routers throughout the network. 182 Discussion: 183 Network Convergence is bounded by the sum of Route Convergence 184 for all routers in the network. Network Convergence can be 185 determined by recovery of the forwarding rate to equal the offered 186 load, no Stale Forwarding, and no blenders[5][6]. 188 Measurement Units: 189 N/A 191 Issues: 192 None 194 See Also: 195 Route Convergence 196 Stale Forwarding 197 IGP Data Plane Route Convergence 199 3.4 Full Convergence 200 Definition: 201 Route Convergence for an entire FIB. 203 Discussion: 204 When benchmarking convergence it is useful to measure 205 the time to converge an entire route table. For example, 207 a Convergence Event can be produced for an OSPF table of 5000 208 routes so that the time to converge routes 1 through 5000 209 is measured. 211 Measurement Units: 212 N/A 214 Issues: 215 None 217 See Also: 218 Network Convergence 219 Route Convergence 220 Convergence Event 222 3.5 Convergence Packet Loss 224 Definition: 225 The amount of packet loss produced by a Convergence Event 226 until Route Convergence occurs. 228 Discussion: 229 Packet loss can be observed as a reduction of forwarded traffic from 230 the maximum forwarding rate. Convergence Packet Loss include packets 231 that were lost and packets that were delayed due to buffering. 232 Convergence Packet Loss may or may not reach 100%. 234 Measurement Units: 235 number of packets 237 Issues: 238 None 240 See Also: 241 Route Convergence 242 Convergence Event 243 Rate-Derived Convergence Time 244 Loss-Derived Convergence Time 245 IGP Data Plane Route Convergence 247 3.6 Convergence Event Instant 249 Definition: 250 The time instant that a Convergence Event becomes observable in the 251 data plane. 253 Discussion: 254 Convergence Event Instant is observable from the data 255 plane as the precise time that the device under test begins 256 to exhibit packet loss. 258 Measurement Units: 259 hh:mm:ss:uuu 261 Issues: 262 None 264 See Also: 265 Convergence Event 266 Convergence Packet Loss 267 Convergence Recovery Instant 269 3.7 Convergence Recovery Instant 271 Definition: 272 The time instant that Full Convergence is measured 273 and maintained for at least an additional five seconds. 275 Discussion: 276 Convergence Recovery Instant is measurable from the data 277 plane as the precise time that the device under test 278 achieves Full Convergence. Convergence Recovery Instant 279 is externally observable from the data plane when the 280 forwarding rate on the Next-Best Egress Interface equals 281 the offered rate. 283 Measurement Units: 284 hh:mm:ss:uuu 286 Issues: 287 None 289 See Also: 290 Convergence Packet Loss 291 Convergence Event Instant 292 IGP Data Plane Route Convergence 294 3.8 Rate-Derived Convergence Time 295 Definition: 296 The amount of time for Convergence Packet Loss to 297 persist upon occurrence of a Convergence Event until 298 occurrence of Route Convergence. 300 Discussion: 301 Rate-Derived Convergence Time can be measured as the time 302 difference from the Convergence Event Instant to the 303 Convergence Recovery Instant, as shown with Equation 1. 305 (eq 1) Rate-Derived Convergence Time = 306 Convergence Recovery Instant - Convergence Event Instant. 308 Rate-Derived Convergence Time should be measured at the maximum 309 forwarding rate. Failure to achieve Full Convergence results in 310 a Rate-Derived Convergence Time benchmark of infinity. 312 Measurement Units: 313 seconds/milliseconds 315 Issues: 316 None 318 See Also: 319 Convergence Packet Loss 320 Convergence Recovery Instant 321 Convergence Event Instant 322 Full Convergence 324 3.9 Convergence Event Transition 325 Definition: 326 The characteristic of a router in which forwarding rate 327 gradually reduces to zero after a Convergence Event. 329 Discussion: 330 The Convergence Event Transition is best observed for 331 Full Convergence. The Convergence Event Transition may 332 not be linear. 334 Measurement Units: 335 seconds/milliseconds 337 Issues: 338 None 340 See Also: 341 Convergence Event 342 Rate-Derived Convergence Time 343 Convergence Packet Loss 344 Convergence Recovery Transition 345 IGP Data Plane Route Convergence 347 3.10 Convergence Recovery Transition 349 Definition: 350 The characteristic of a router in which forwarding rate 351 gradually increases to equal the offered load. 353 Discussion: 354 The Convergence Recovery Transition is best observed for 355 Full Convergence. The Convergence Event Transition may 356 not be linear. 358 Measurement Units: 359 seconds/milliseconds 361 Issues: 362 None 364 See Also: 365 Full Convergence 366 Rate-Derived Convergence Time 367 Convergence Packet Loss 368 Convergence Event Transition 370 3.11 Loss-Derived Convergence Time 372 Definition: 373 The amount of time it takes for Route Convergence to 374 to be achieved as calculated from the Convergence Packet 375 Loss. 377 Discussion: 378 Loss-Derived Convergence Time can be calculated from 379 Convergence Packet Loss that occurs due to a Convergence Event 380 and Route Convergence, as shown with Equation 2. 382 (eq 2) Loss-Derived Convergence Time = 383 Convergence Packets Loss / Forwarding Rate 384 NOTE: Units for this measurement are 385 packets / packets/second = seconds 387 Measurement Units: 388 seconds/milliseconds 390 Issues: 391 Loss-Derived Convergence Time gives a better than 392 actual result when converging many routes simultaneously. 393 Rate-Derived Convergence Time takes the Convergence Recovery 394 Transition into account, but Loss-Derived Convergence Time 395 ignores the Route Convergence Recovery Transition because 396 it is obtained from the measured Convergence Packet Loss. 397 Ideally, the Convergence Event Transition and Convergence 398 IGP Data Plane Route Convergence 400 Recovery Transition are instantaneous so that the 401 Rate-Derived Convergence Time = Loss-Derived Convergence Time. 402 However, router implementations are less than ideal. 403 For these reasons the preferred reporting benchmark for IGP 404 Route Convergence is the Rate-Derived Convergence Time. 405 Guidelines for reporting Loss-Derived Convergence Time are 406 provided in [2]. 408 See Also: 409 Route Convergence 410 Convergence Packet Loss 411 Rate-Derived Convergence Time 412 Convergence Event Transition 413 Convergence Recovery Transition 415 3.12 Sustained Forwarding Convergence Time 417 Definition: 418 The amount of time for Route Convergence to be achieved for 419 cases in which there is no packet loss. 421 Discussion: 422 Sustained Forwarding Convergence Time is the IGP Route Convergence 423 benchmark to be used for Convergence Events that produce 424 a change in next-hop without packet loss. 426 Measurement Units: 427 seconds/milliseconds 429 Issues: 430 None 432 See Also: 433 Route Convergence 434 Rate-Derived Convergence Time 435 Loss-Derived Convergence Time 437 3.13 Restoration Convergence Time 439 Definition: 440 The amount of time for the router under test to restore 441 traffic to the original outbound port after recovery from 442 a Convergence Event. 444 Discussion: 445 Restoration Convergence Time is the amount of time to 446 Converge back to the original outbound port. This is achieved 447 by recovering from the Convergence Event, such as restoring 448 the failed link. Restoration Convergence Time is measured 449 using the Rate-Derived Convergence Time calculation technique, 450 as provided in Equation 1. It is possible, but not desired 451 IGP Data Plane Route Convergence 453 to have the Restoration Convergence Time differ from the 454 Rate-Derived Convergence Time. 456 Measurement Units: 457 seconds or milliseconds 459 Issues: 460 None 462 See Also: 463 Convergence Event 464 Rate-Derived Convergence Time 466 3.14 Packet Sampling Interval 467 Definition: 468 The interval at which the tester (test equipment) polls to make 469 measurements for arriving packet flows. 471 Discussion: 472 Metrics measured at the Packet Sampling Interval may include 473 Forwarding Rate and Convergence Packet Loss. 475 Measurement Units: 476 seconds or milliseconds 478 Issues: 479 Packet Sampling Interval can influence the Convergence Graph. 480 This is particularly true as implementations achieve Full 481 Convergence in less than 1 second. The Convergence Event 482 Transition and Convergence Recovery Transition can become 483 exaggerated when the Packet Sampling Interval is too long. 484 This will produce a larger than actual Rate-Derived 485 Convergence Time. The recommended value for configuration 486 of the Packet Sampling Interval is provided in [2]. 488 See Also: 489 Convergence Packet Loss 490 Convergence Event Transition 491 Convergence Recovery Transition 493 3.15 Local Interface 494 Definition: 495 An interface on the DUT. 497 Discussion: 498 None 500 Measurement Units: 501 N/A 502 IGP Data Plane Route Convergence 504 Issues: 505 None 507 See Also: 508 Neighbor Interface 509 Remote Interface 511 3.16 Neighbor Interface 513 Definition: 514 The interface on the neighbor router or tester that is 515 directly linked to the DUT's Local Interface. 517 Discussion: 518 None 520 Measurement Units: 521 N/A 523 Issues: 524 None 526 See Also: 527 Local Interface 528 Remote Interface 530 3.17 Remote Interface 532 Definition: 533 An interface on a neighboring router that is not directly 534 connected to any interface on the DUT. 536 Discussion: 537 None 539 Measurement Units: 540 N/A 542 Issues: 543 None 545 See Also: 546 Local Interface 547 Neighbor Interface 549 3.18 Preferred Egress Interface 551 Definition: 552 The outbound interface from the DUT for traffic routed to the 553 preferred next-hop. 555 IGP Data Plane Route Convergence 557 Discussion: 558 Preferred Egress Interface is the egress interface prior to 559 a Convergence Event 561 Measurement Units: 562 N/A 564 Issues: 565 None 567 See Also: 568 Next-Best Egress Interface 570 3.19 Next-Best Egress Interface 572 Definition: 573 The outbound interface from the DUT for traffic routed to the 574 second-best next-hop. 576 Discussion: 577 Next-Best Egress Interface is the egress interface after 578 a Convergence Event. 580 Measurement Units: 581 N/A 583 Issues: 584 None 586 See Also: 587 Preferred Egress Interface 589 3.20 Stale Forwarding 590 Definition: 591 Forwarding of traffic to route entries that no longer exist 592 or to route entries with next-hops that are no longer preferred. 594 Discussion: 595 Stale Forwarding can be caused by a Convergence Event and is 596 also known as a "black-hole" since it may produce packet loss. 597 Stale Forwarding exists until Network Convergence is achieved. 599 Measurement Units: 600 N/A 602 Issues: 603 None 605 See Also: 606 Network Convergence 607 IGP Data Plane Route Convergence 609 4. Security Considerations 611 Documents of this type do not directly affect the security of 612 Internet or corporate networks as long as benchmarking 613 is not performed on devices or systems connected to operating 614 networks. 616 5. References 618 [1] Poretsky, S., "Benchmarking Applicability for IGP Data Plane 619 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-app-04, 620 work in progress, October 2004. 622 [2] Poretsky, S., "Benchmarking Methodology for IGP Data Plane 623 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-meth-04, 624 work in progress, October 2004. 626 [3] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual 627 Environments", RFC 1195, December 1990. 629 [4] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 631 [5] S. Casner, C. Alaettinoglu, and C. Kuan, "A Fine-Grained View 632 of High Performance Networking", NANOG 22, May 2001. 634 [6] L. Ciavattone, A. Morton, and G. Ramachandran, "Standardized 635 Active Measurements on a Tier 1 IP Backbone", IEEE Communications 636 Magazine, pp90-97, June, 2003. 638 6. Author's Address 640 Scott Poretsky 641 Quarry Technologies 642 8 New England Executive Park 643 Burlington, MA 01803 644 USA 645 Phone: + 1 781 395 5090 646 EMail: sporetsky@quarrytech.com 648 Brent Imhoff 649 USA 650 EMail: bimhoff@planetspork.com 651 IGP Data Plane Route Convergence 653 Intellectual Property Statement 655 The IETF takes no position regarding the validity or scope of any Intel- 656 lectual Property Rights or other rights that might be claimed to pertain 657 to the implementation or use of the technology described in this docu- 658 ment or the extent to which any license under such rights might or might 659 not be available; nor does it represent that it has made any independent 660 effort to identify any such rights. Information on the procedures with 661 respect to rights in RFC documents can be found in BCP 78 and BCP 79. 663 Copies of IPR disclosures made to the IETF Secretariat and any 664 assurances of licenses to be made available, or the result of an attempt 665 made to obtain a general license or permission for the use of such 666 proprietary rights by implementers or users of this specification can be 667 obtained from the IETF on-line IPR repository at 668 http://www.ietf.org/ipr. 670 The IETF invites any interested party to bring to its attention any 671 copyrights, patents or patent applications, or other proprietary rights 672 that may cover technology that may be required to implement this stan- 673 dard. Please address the information to the IETF at ietf-ipr@ietf.org. 675 Disclaimer of Warranty 677 This document and the information contained herein are provided on an 678 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 679 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 680 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 681 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMA- 682 TION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 683 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 685 Copyright Statement 687 Copyright (C) The Internet Society (2004). This document is subject to 688 the rights, licenses and restrictions contained in BCP 78, and except as 689 set forth therein, the authors retain all their rights.