idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-term-03.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 667. ** 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 == 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 390 instances of lines with control characters in the document. ** 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 (January 2005) is 7041 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 617 looks like a reference -- Missing reference section? '2' on line 621 looks like a reference -- Missing reference section? '3' on line 625 looks like a reference -- Missing reference section? '4' on line 628 looks like a reference -- Missing reference section? '5' on line 630 looks like a reference -- Missing reference section? '6' on line 633 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group 3 INTERNET-DRAFT 4 Expires in: January 2005 5 Scott Poretsky 6 Quarry Technologies 8 Brent Imhoff 10 July 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 \_____/<------100% 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. 233 Measurement Units: 234 number of packets 236 Issues: 237 None 239 See Also: 240 Route Convergence 241 Convergence Event 242 Rate-Derived Convergence Time 243 Loss-Derived Convergence Time 244 IGP Data Plane Route Convergence 246 3.6 Convergence Event Instant 248 Definition: 249 The time instant that a Convergence Event becomes observable in the 250 data plane. 252 Discussion: 253 Convergence Event Instant is observable from the data 254 plane as the precise time that the device under test begins 255 to exhibit packet loss. 257 Measurement Units: 258 hh:mm:ss:uuu 260 Issues: 261 None 263 See Also: 264 Convergence Event 265 Convergence Packet Loss 266 Convergence Recovery Instant 268 3.7 Convergence Recovery Instant 270 Definition: 271 The time instant that Full Convergence is measured 272 and maintained for at least an additional five seconds. 274 Discussion: 275 Convergence Recovery Instant is measurable from the data 276 plane as the precise time that the device under test 277 achieves Full Convergence. Convergence Recovery Instant 278 is externally observable from the data plane when the 279 forwarding rate on the Next-Best Egress Interface equals 280 the offered rate. 282 Measurement Units: 283 hh:mm:ss:uuu 285 Issues: 286 None 288 See Also: 289 Convergence Packet Loss 290 Convergence Event Instant 291 IGP Data Plane Route Convergence 293 3.8 Rate-Derived Convergence Time 294 Definition: 295 The amount of time for Convergence Packet Loss to 296 persist upon occurrence of a Convergence Event until 297 occurrence of Route Convergence. 299 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. 333 Measurement Units: 334 seconds/milliseconds 336 Issues: 337 None 339 See Also: 340 Convergence Event 341 Rate-Derived Convergence Time 342 Convergence Packet Loss 343 Convergence Recovery Transition 344 IGP Data Plane Route Convergence 346 3.10 Convergence Recovery Transition 348 Definition: 349 The characteristic of a router in which forwarding rate 350 gradually increases to equal the offered load. 352 Discussion: 353 The Convergence Recovery Transition is best observed for 354 Full Convergence. 356 Measurement Units: 357 seconds/milliseconds 359 Issues: 360 None 362 See Also: 363 Full Convergence 364 Rate-Derived Convergence Time 365 Convergence Packet Loss 366 Convergence Event Transition 368 3.11 Loss-Derived Convergence Time 370 Definition: 371 The amount of time it takes for Route Convergence to 372 to be achieved as calculated from the Convergence Packet 373 Loss. 375 Discussion: 376 Loss-Derived Convergence Time can be calculated from 377 Convergence Packet Loss that occurs due to a Convergence Event 378 and Route Convergence, as shown with Equation 2. 380 (eq 2) Loss-Derived Convergence Time = 381 Convergence Packets Loss / Forwarding Rate 383 NOTE: Units for this measurement are 384 packets / packets/second = seconds 386 Measurement Units: 387 seconds/milliseconds 389 Issues: 390 Loss-Derived Convergence Time gives a better than 391 actual result when converging many routes simultaneously. 392 Rate-Derived Convergence Time takes the Convergence Recovery 393 Transition into account, but Loss-Derived Convergence Time 394 ignores the Route Convergence Recovery Transition because 395 it is obtained from the measured Convergence Packet Loss. 396 Ideally, the Convergence Event Transition and Convergence 397 IGP Data Plane Route 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. 404 Guidelines for reporting Loss-Derived Convergence Time are 405 provided in [2]. 407 See Also: 408 Route Convergence 409 Convergence Packet Loss 410 Rate-Derived Convergence Time 411 Convergence Event Transition 412 Convergence Recovery Transition 414 3.12 Sustained Forwarding Convergence Time 416 Definition: 417 The amount of time for Route Convergence to be achieved for 418 cases in which there is no packet loss. 420 Discussion: 421 Sustained Forwarding Convergence Time is the IGP Route Convergence 422 benchmark to be used for Convergence Events that produce 423 a change in next-hop without packet loss. 425 Measurement Units: 426 seconds/milliseconds 428 Issues: 429 None 431 See Also: 432 Route Convergence 433 Rate-Derived Convergence Time 434 Loss-Derived Convergence Time 436 3.13 Restoration Convergence Time 438 Definition: 439 The amount of time for the router under test to restore 440 traffic to the original outbound port after recovery from 441 a Convergence Event. 443 Discussion: 444 Restoration Convergence Time is the amount of time to 445 Converge back to the original outbound port. This is achieved 446 by recovering from the Convergence Event, such as restoring 447 the failed link. Restoration Convergence Time is measured 448 using the Rate-Derived Convergence Time calculation technique, 449 as provided in Equation 1. It is possible, but not desired 450 IGP Data Plane Route Convergence 452 to have the Restoration Convergence Time differ from the 453 Rate-Derived Convergence Time. 455 Measurement Units: 456 seconds or milliseconds 458 Issues: 459 None 461 See Also: 462 Convergence Event 463 Rate-Derived Convergence Time 465 3.14 Packet Sampling Interval 466 Definition: 467 The interval at which the tester (test equipment) polls to make 468 measurements for arriving packet flows. 470 Discussion: 471 Metrics measured at the Packet Sampling Interval may include 472 Forwarding Rate and Convergence Packet Loss. 474 Measurement Units: 475 seconds or milliseconds 477 Issues: 478 Packet Sampling Interval can influence the Convergence Graph. 479 This is particularly true as implementations achieve Full 480 Convergence in less than 1 second. The Convergence Event 481 Transition and Convergence Recovery Transition can become 482 exaggerated when the Packet Sampling Interval is too long. 483 This will produce a larger than actual Rate-Derived 484 Convergence Time. The recommended value for configuration 485 of the Packet Sampling Interval is provided in [2]. 487 See Also: 488 Convergence Packet Loss 489 Convergence Event Transition 490 Convergence Recovery Transition 492 3.15 Local Interface 493 Definition: 494 An interface on the DUT. 496 Discussion: 497 None 499 Measurement Units: 500 N/A 501 IGP Data Plane Route Convergence 503 Issues: 504 None 506 See Also: 507 Neighbor Interface 508 Remote Interface 510 3.16 Neighbor Interface 512 Definition: 513 The interface on the neighbor router or tester that is 514 directly linked to the DUT's Local Interface. 516 Discussion: 517 None 519 Measurement Units: 520 N/A 522 Issues: 523 None 525 See Also: 526 Local Interface 527 Remote Interface 529 3.17 Remote Interface 531 Definition: 532 An interface on a neighboring router that is not directly 533 connected to any interface on the DUT. 535 Discussion: 536 None 538 Measurement Units: 539 N/A 541 Issues: 542 None 544 See Also: 545 Local Interface 546 Neighbor Interface 548 3.18 Preferred Egress Interface 550 Definition: 551 The outbound interface from the DUT for traffic routed to the 552 preferred next-hop. 554 IGP Data Plane Route Convergence 556 Discussion: 557 Preferred Egress Interface is the egress interface prior to 558 a Convergence Event 560 Measurement Units: 561 N/A 563 Issues: 564 None 566 See Also: 567 Next-Best Egress Interface 569 3.19 Next-Best Egress Interface 571 Definition: 572 The outbound interface from the DUT for traffic routed to the 573 second-best next-hop. 575 Discussion: 576 Next-Best Egress Interface is the egress interface after 577 a Convergence Event. 579 Measurement Units: 580 N/A 582 Issues: 583 None 585 See Also: 586 Preferred Egress Interface 588 3.20 Stale Forwarding 589 Definition: 590 Forwarding of traffic to route entries that no longer exist 591 or to route entries with next-hops that are no longer preferred. 593 Discussion: 594 Stale Forwarding can be caused by a Convergence Event and is 595 also known as a "black-hole" since it may produce packet loss. 596 Stale Forwarding exists until Network Convergence is achieved. 598 Measurement Units: 599 N/A 601 Issues: 602 None 604 See Also: 605 Network Convergence 606 IGP Data Plane Route Convergence 608 4. Security Considerations 610 Documents of this type do not directly affect the security of 611 Internet or corporate networks as long as benchmarking 612 is not performed on devices or systems connected to operating 613 networks. 615 5. References 617 [1] Poretsky, S., "Benchmarking Applicability for IGP Data Plane 618 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-app-03, 619 work in progress, July 2004. 621 [2] Poretsky, S., "Benchmarking Methodology for IGP Data Plane 622 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-meth-03, 623 work in progress, July 2004. 625 [3] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual 626 Environments", RFC 1195, December 1990. 628 [4] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 630 [5] S. Casner, C. Alaettinoglu, and C. Kuan, "A Fine-Grained View 631 of High Performance Networking", NANOG 22, May 2001. 633 [6] L. Ciavattone, A. Morton, and G. Ramachandran, "Standardized 634 Active Measurements on a Tier 1 IP Backbone", IEEE Communications 635 Magazine, pp90-97, June, 2003. 637 6. Author's Address 639 Scott Poretsky 640 Quarry Technologies 641 8 New England Executive Park 642 Burlington, MA 01803 643 USA 644 Phone: + 1 781 395 5090 645 EMail: sporetsky@quarrytech.com 647 Brent Imhoff 648 USA 649 EMail: bimhoff@planetspork.com 650 IGP Data Plane Route Convergence 652 Intellectual Property Statement 654 The IETF takes no position regarding the validity or scope of any Intel- 655 lectual Property Rights or other rights that might be claimed to pertain 656 to the implementation or use of the technology described in this docu- 657 ment or the extent to which any license under such rights might or might 658 not be available; nor does it represent that it has made any independent 659 effort to identify any such rights. Information on the procedures with 660 respect to rights in RFC documents can be found in BCP 78 and BCP 79. 662 Copies of IPR disclosures made to the IETF Secretariat and any 663 assurances of licenses to be made available, or the result of an attempt 664 made to obtain a general license or permission for the use of such 665 proprietary rights by implementers or users of this specification can be 666 obtained from the IETF on-line IPR repository at 667 http://www.ietf.org/ipr. 669 The IETF invites any interested party to bring to its attention any 670 copyrights, patents or patent applications, or other proprietary rights 671 that may cover technology that may be required to implement this stan- 672 dard. Please address the information to the IETF at ietf-ipr@ietf.org. 674 Disclaimer of Warranty 676 This document and the information contained herein are provided on an 677 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 678 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 679 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 680 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMA- 681 TION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 682 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 684 Copyright Statement 686 Copyright (C) The Internet Society (2004). This document is subject to 687 the rights, licenses and restrictions contained in BCP 78, and except as 688 set forth therein, the authors retain all their rights.