idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-term-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 243 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 123 has weird spacing: '...pdating of th...' == 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 (December 2003) is 7435 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 401 looks like a reference -- Missing reference section? '2' on line 405 looks like a reference -- Missing reference section? '3' on line 409 looks like a reference -- Missing reference section? '4' on line 412 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 6 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: December 2003 4 Scott Poretsky 5 Avici Systems 7 June 2003 9 Terminology for Benchmarking 10 IGP Data Plane Route Convergence 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet-Drafts 27 as reference material or to cite them other than as "work in 28 progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Table of Contents 38 1. Introduction ...............................................2 39 2. Existing definitions .......................................2 40 3. Term definitions............................................2 41 3.1 Network Convergence.....................................2 42 3.2 Protocol Convergence....................................3 43 3.3 Route Convergence.......................................3 44 3.4 Full Route Convergence Time.............................4 45 3.5 Route Convergence Packet Loss...........................5 46 3.6 Average Route Convergence Time..........................5 47 3.7 Route Convergence Event Slope...........................6 48 3.8 Route Convergence Recovery Slope........................6 49 3.9 Reroute Convergence Time...............................7 50 3.10 Local Interface........................................7 51 3.11 Neighbor Interface.....................................8 52 3.12 Remote Interface.......................................8 53 4. Security Considerations.....................................8 54 5. References..................................................9 55 IGP Route Convergence 57 7. Author's Address............................................9 58 8. Full Copyright Statement....................................9 60 1. Introduction 61 This draft describes the terminology for benchmarking IGP Route 62 Convergence. The motivation and applicability for this 63 benchmarking is provided in [1]. The methodology to be used for 64 this benchmarking is described in [2]. The methodology and 65 terminology to be used for benchmarking route convergence can be 66 applied to any link-state IGP such as ISIS [3] and OSPF [4]. The 67 data plane is measured to obtain the convergence benchmarking metrics. 68 The purpose of this document is to introduce new terms required to 69 complete execution of the IGP Route Convergence Methodology [2]. 71 2. Existing definitions 73 For the sake of clarity and continuity this RFC adopts the template 74 for definitions set out in Section 2 of RFC 1242. Definitions are 75 indexed and grouped together in sections for ease of reference. 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 79 this document are to be interpreted as described in RFC 2119. 81 3. Term definitions 83 3.1 Network Convergence 85 Definition: 86 The completion of updating of all routing tables, including the 87 FIB, in all routers throughout the network. 89 Discussion: 90 Network Convergence can be approximated to the sum of Route 91 Convergence for all routers in the network. Network Convergence 92 can only be determined by the occurrence of packet loss or stale 93 forwarding due to an out-of-date FIB. 95 Measurement Units: 96 Converged or Not Converged 98 Issues: 99 None 101 See Also: 102 Protocol Convergence 103 Route Convergence 104 IGP Data Plane Route Convergence 106 3.2 Protocol Convergence 108 Definition: 109 The completion of updating a router's RIB and the forwarding of 110 an route update message (LSA for OSPF/LSP for ISIS) to a 111 neighboring peer. 113 Discussion: 114 Protocol Convergence considers only the Control Plane. IGP 115 messaging is used to verify and measure convergence. Updating 116 of the FIB, hardware updating, rerouting of traffic, and packet 117 loss are not considered. 119 Measurement Units: 120 LSA/LSP Transmitted or LSA/LSP Not Transmitted. 122 Issues: 123 Protocol Convergence does not consider updating of the FIB, 124 hardware updating, rerouting of traffic, and resultant packet 125 loss. Protocol Convergence is only a partial measurement of 126 Route Convergence. 128 See Also: 129 Network Convergence 130 Route Convergence 132 3.3 Route Convergence 134 Definition: 135 The completion of the router's FIB becoming fully converged. 137 Discussion: 138 All components of the router have been updated with the most 139 recent route change(s) including the RIB and FIB, along with 140 software and hardware tables. Route Convergence can be observed 141 externally by the rerouting of data traffic. 143 Measurement Units: 144 Converged or Not Converged 146 Issues: 147 None 149 See Also: 150 Route Convergence Time 151 Network Convergence 152 Protocol Convergence 153 IGP Data Plane Route Convergence 155 3.4 Full Route Convergence Time 157 Definition: 158 The amount of time it takes for Route Convergence to 159 complete as measured by the time to drop from maximum 160 forwarding rate and return to maximum forwarding rate 161 after occurrence of a network event. 163 Discussion: 164 Full Route Convergence Time is a metric applied 165 to a single router. Convergence Time could be calculated 166 from packet loss. However, this will give a better than 167 actual result when converging many routes simultaneously. 168 The preferred method to obtain Route Convergence Time is 169 to measure the time to drop from maximum forwarding rate 170 and return to maximum forwarding rate. 172 Figure 1 shows a graph model of Convergence Time as measured 173 from the data plane. IGP Route Convergence Time is the 174 amount of time for the Forwarding Rate to begin its downward 175 slope upon occurrence of a network event and then fully recover 176 to the Maximum Forwarding Rate. This is calculated as 178 (eq 1) Time(Convergence) = Time(Recovery) - Time(Network Event). 180 Forwarding Rate versus Time 182 Time=Recovery Time=Network Event Time = 0sec 183 Maximum ^ ^ ^ 184 Forwarding Rate--> ----\ /----------- 185 \ /<----Route Convergence 186 Route Convergence------->\ / Event Slope 187 Recovery Slope \_______/<------100% Packet Loss 189 X-axis = Time 190 Y-axis = Forwarding Rate 192 Figure 1. Convergence Graph 194 Measurement Units: 195 seconds/milliseconds 197 Issues: 198 None 200 See Also: 201 Route Convergence 202 Route Convergence Packet Loss 203 Average Route Convergence Time 204 IGP Data Plane Route Convergence 206 3.5 Route Convergence Packet Loss 208 Definition: 209 The amount of packet loss until Route Convergence completes. 211 Discussion: 212 Route Convergence Packet Loss is used to calculate the 213 Route Convergence Time. Packet loss is an externally 214 measurable metric. 216 Measurement Units: 217 number of packets 219 Issues: 220 None 222 See Also: 223 Route Convergence 224 Full Route Convergence Time 225 Route Convergence Event Slope 226 Route Convergence Recovery Slope 228 3.6 Average Route Convergence Time 230 Definition: 231 The amount of time it takes for Route Convergence to 232 complete as calculated from the amount of packet loss 233 and known forwarding rate. 235 Discussion: 236 Average Route Convergence Time is a metric applied to a 237 single router. It can be calculated from packet loss that 238 occurs due to a network event and subsequent Route 239 Convergence. 241 Measurement Units: 242 seconds/milliseconds 244 Issues: 245 Use of Packet loss to calculate Route Convergence Time will 246 give a better than actual result when converging many routes 247 simultaneously. Full Route Convergence Time is 248 the preferred benchmark for IGP Route Convergence. 250 See Also: 251 Route Convergence 252 Route Convergence Packet Loss 253 Full Route Convergence Time 254 Route Convergence Event Slope 255 Route Convergence Recovery Slope 256 IGP Data Plane Route Convergence 258 3.7 Route Convergence Event Slope 260 Definition: 261 The characteristic of routers in which forwarding rate 262 gradually reaches zero as output queues drain after a 263 network event. 265 Discussion: 266 Route Convergence Event Slope is externally observable. 267 Full Route Convergence Time ignores the Route 268 Convergence Event Slope. Average Route Convergence 269 Time based upon the amount of packet loss takes the 270 Route Convergence Event Slope into account. 272 Measurement Units: 273 seconds/milliseconds 275 Issues: 276 None 278 See Also: 279 Route Convergence 280 Full Route Convergence Time 281 Average Route Convergence Time 282 Route Convergence Packet Loss 283 Route Convergence Recovery Slope 285 3.8 Route Convergence Recovery Slope 286 Definition: 287 The characteristic of routers in which forwarding rate 288 gradually rises to the maximum value as many routes 289 converge to recover from a network event. 291 Discussion: 292 Route Convergence Recovery Slope is externally observable. 293 Full Route Convergence Time ignores the Route 294 Convergence Recovery Slope. Average Route Convergence 295 Time based upon the amount of packet loss takes the 296 Route Convergence Recovery Slope into account. 298 Measurement Units: 299 seconds/milliseconds 301 Issues: 302 None 304 See Also: 305 Route Convergence 306 Full Route Convergence Time 307 Average Route Convergence Time 308 Route Convergence Packet Loss 309 Route Convergence Event Slope 310 IGP Data Plane Route Convergence 312 3.9 Reroute Convergence Time 313 Definition: 314 The amount of time it takes for Route Convergence to 315 complete as observed from rerouting of traffic to a 316 new egress interface. 318 Discussion: 319 Reroute Convergence Time is the IGP Route Convergence 320 benchmark to be used for network events that produce 321 a change in next-hop without packet loss. An example 322 of this is a cost change in which an backup path becomes 323 the preferred path. 325 Measurement Units: 326 seconds/milliseconds 328 Issues: 329 None 331 See Also: 332 Route Convergence 333 Full Route Convergence Time 334 Average Route Convergence Time 336 3.10 Local Interface 337 Definition: 338 An interface on the DUT. 340 Discussion: 341 None 343 Measurement Units: 344 N/A 346 Issues: 347 None 349 See Also: 350 Neighbor Interface 351 Remote interface 353 3.11 Neighbor Interface 355 Definition: 356 The interface on the neighbor router or tester that is 357 directly linked to the DUT's Local Interface. 359 Discussion: 360 None 362 Measurement Units: 363 N/A 364 IGP Data Plane Route Convergence 366 Issues: 367 None 369 See Also: 370 Local Interface 371 Remote interface 373 3.12 Remote Interface 375 Definition: 376 An interface on a neighboring router that is not directly 377 linked to any interface on the DUT. 379 Discussion: 380 None 382 Measurement Units: 383 N/A 385 Issues: 386 None 388 See Also: 389 Local interface 390 Neighbor Interface 392 4. Security Considerations 394 Documents of this type do not directly effect the security of 395 the Internet or of corporate networks as long as benchmarking 396 is not performed on devices or systems connected to operating 397 networks. 399 5. References 401 [1] Poretsky, S., "Benchmarking Applicability for IGP Data Plane 402 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-app-00, 403 work in progress, June 2003. 405 [2] Poretsky, S., "Benchmarking Terminology for IGP Data Plane 406 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-00, 407 work in progress, June 2003. 409 [3] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual 410 Environments", RFC 1195, December 1990. 412 [4] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 414 IGP Data Plane Route Convergence 416 6. Author's Address 418 Scott Poretsky 419 Avici Systems 420 101 Billerica Avenue 421 N. Billerica, MA 01862 422 USA 424 Phone: + 1 978 964 2287 425 EMail: sporetsky@avici.com 427 7. Full Copyright Statement 429 Copyright (C) The Internet Society (1998). All Rights 430 Reserved. 432 This document and translations of it may be copied and 433 furnished to others, and derivative works that comment on or 434 otherwise explain it or assist in its implementation may be 435 prepared, copied, published and distributed, in whole or in 436 part, without restriction of any kind, provided that the above 437 copyright notice and this paragraph are included on all such 438 copies and derivative works. However, this document itself may 439 not be modified in any way, such as by removing the copyright 440 notice or references to the Internet Society or other Internet 441 organizations, except as needed for the purpose of developing 442 Internet standards in which case the procedures for copyrights 443 defined in the Internet Standards process must be followed, or 444 as required to translate it into languages other than English. 446 The limited permissions granted above are perpetual and will 447 not be revoked by the Internet Society or its successors or 448 assigns. This document and the information contained herein is 449 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 450 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 451 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 452 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 453 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 454 FOR A PARTICULAR PURPOSE.