idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-app-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 5 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: ' 6. 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 39 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [8], [9], [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 (December 2003) is 7438 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 189 looks like a reference -- Missing reference section? '2' on line 193 looks like a reference -- Missing reference section? '3' on line 197 looks like a reference -- Missing reference section? '4' on line 200 looks like a reference -- Missing reference section? '5' on line 202 looks like a reference -- Missing reference section? '6' on line 205 looks like a reference -- Missing reference section? '7' on line 208 looks like a reference -- Missing reference section? '8' on line 214 looks like a reference -- Missing reference section? '9' on line 218 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 11 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 Benchmarking Applicability for 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 ABSTRACT 37 This draft describes the applicability of IGP Route Convergence 38 benchmarking methodology [1] and IGP Route Convergence bechmarking 39 terminology [2]. The methodology and terminology is to be used 40 for benchmarking route convergence and can be applied to any 41 link-state IGP such as ISIS [3] and OSPF [4]. The data plane is 42 measured to obtain the convergence benchmarking metrics described 43 in [1]. 45 Table of Contents 46 1. Introduction ...............................................2 47 2. Existing definitions .......................................2 48 3. Factors for IGP Route Convergence Time......................2 49 4. Network Events that Cause Route Convergence.................3 50 5. Use of Data Traffic for IGP Route Convergence Benchmarking..3 51 6. Security Considerations.....................................4 52 7. Acknowledgements............................................4 53 8. References..................................................4 54 IGP Data Plane Route Convergence 56 9. Author's Address............................................5 57 10. Full Copyright Statement...................................5 59 1. Introduction 60 IGP Convergence is a critical performance parameter. Customers 61 of Service Providers use packet loss due to IGP Convergence as a 62 key metric of their network service quality. Service Providers 63 use IGP Convergence time as a key metric of router design and 64 architecture. Fast network convergence can be optimally achieved 65 through deployment of fast converging routers. The fundamental 66 basis by which customers of service providers benchmark convergence 67 is packet loss, which is an externally observable event having 68 direct impact on their application performance. IGP Route 69 Convergence is a Direct Measure of Quality (DMOQ) when benchmarking 70 the data plane. For this reason it is important to develop a standard 71 router benchmarking methodology and terminology for measuring IGP 72 convergence that uses the data plane as described in [1] and [2]. 73 This document describes all of the factors that influence a 74 convergence measurement and how a purely black box test can be 75 designed to account for all of these factors. This enables accurate 76 benchmarking and evaluation for route convergence time. 78 2. Existing definitions 80 For the sake of clarity and continuity this RFC adopts the template 81 for definitions set out in Section 2 of RFC 1242. Definitions are 82 indexed and grouped together in sections for ease of reference. 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 86 this document are to be interpreted as described in RFC 2119. 88 3. Factors for IGP Route Convergence Time 90 There are four major categories of factors for the measured Router 91 IGP Convergence Time, as described in [5], [6], [7], [8] and [9]. 92 These are Event Detection, SPF Processing, IGP Advertisement, and 93 FIB Update. Each of these factors has numerous components to 94 influence the convergence time. These are listed as follow: 96 -Event Detection- 97 SONET failure indication time 98 PPP failure indication time 99 IGP Hello Dead Interval 101 -SPF Processing- 102 SPF Delay Time 103 SPF Hold time 104 SPF Execution time 105 IGP Data Plane Route Convergence 106 -IGP Advertisement- 107 LSA/LSP Flood Packet Pacing 108 LSA/LSP Retransmission Packet Pacing 109 LSA/LSP Generation time 111 -FIB Update- 112 Tree Build time 113 Hardware Update time 115 Each of the factors listed above will have a varying amount of 116 influence on the convergence result with each router vendors' 117 architecture and IGP implementation. It is necessary to design a 118 convergence test that considers not just one or a few of these 119 components, but instead all of these components. The additional 120 benefit of designing a test for all components is that it enables 121 black-box testing in which knowledge of the routers' internal 122 implementations is not required. It is then possible to make 123 valid use of the benchmarking metrics when comparing routers from 124 different vendors. 126 4. Network Events that Cause Convergence 128 There are different types of network events that can cause IGP 129 convergence. These network events are administrative link 130 removal, unplanned link removal, and route change such as 131 withdrawal, flap, next-hop change, and cost change. When 132 benchmarking a router it is important to measure the convergence 133 time for local and remote occurrence of these network events. 134 The convergence time measured will vary whether the network event 135 occurred locally or remotely due to varying combinations of 136 factors listed in the previous sections. This behavior makes it 137 possible to design purely black-box tests that isolate 138 measurements for each of the components of convergence time. 140 5. Use of Data Plane for IGP Route Convergence Benchmarking 142 Customers of service providers use packet loss as the metric for 143 convergence time. Packet loss is an externally observable event 144 having direct impact on customers' application performance. 145 For this reason it is important to develop a standard router 146 benchmarking methodology and terminology that is a Direct Measure 147 of Quality (DMOQ)for measuring IGP convergence. Such a 148 methodology uses the data plane as described in [1] and [2]. 150 An additional benefit of using packet loss for calculation of 151 IGP Route Convergence time is that it enables black-box tests to 152 be designed. Data traffic can be offered at line-rate to the 153 device under test (DUT), an emulated network event can be forced 154 to occur, and packet loss can be externally 155 observed to measure the convergence time. Knowledge of the DUT 156 architecture and IGP implementation is not required. There is no 157 need to rely on the DUT to produce the test results. There is no 158 need to build intrusive test harnasses for the DUT. 160 IGP Data Plane Route Convergence 162 Use of data traffic and measurement of packet loss on the data 163 plane also enables Route Convergence methodology test cases that 164 consider the time for the Route Controller to update the FIB on 165 the forwarding engine of the hardware. A router is not fully 166 converged until all components are updated and traffic is 167 rerouted along the correct path. As long as there is packet 168 loss, routes have not converged. It is possible to send diverse 169 traffic flows to destinations matching every route in the FIB 170 so that the time it takes for the router to converge an entire 171 route table can be benchmarked. 173 6. Security Considerations 175 Documents of this type do not directly effect the security of 176 the Internet or of corporate networks as long as benchmarking 177 is not performed on devices or systems connected to operating 178 networks. 180 7. Acknowledgements 181 Thanks to Curtis Villamizar for sharing so much of his 182 knowledge and experience through the years. Also, special 183 thanks to the many Network Engineers and Network Architects 184 at the Service Providers who are always eager to discuss 185 Route Convergence. 187 8. References 189 [1] Poretsky, S., "Benchmarking Methodology for IGP Data Plane 190 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-meth-00, 191 work in progress, June 2003. 193 [2] Poretsky, S., "Benchmarking Terminology for IGP Data Plane 194 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-00, 195 work in progress, June 2003. 197 [3] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual 198 Environments", RFC 1195, December 1990. 200 [4] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 202 [5] Villamizar, C., "Convergence and Restoration Techniques for 203 ISP Interior Routing", NANOG 25, June 2002. 205 [6] Katz, D., "Why are we Scared of SPF? IGP Scaling and 206 Stability", NANOG 25, June 2002. 208 [7] Filsfils, C., "Deploying Tight-SLA Services on an Internet 209 Backbone: ISIS Fast Convergence and Differentiated Services 210 Design (tutorial)", NANOG 25, June 2002. 212 IGP Data Plane Route Convergence 214 [8] Alaettinoglu, C. and Casner, S., "ISIS Routing on the Qwest 215 Backbone: a Recipe for Subsecond ISIS Convergence", NANOG 24, 216 June 2002. 218 [9] Alaettinoglu, C., Jacobson, V., and Yu, H., "Towards 219 Millisecond IGP Convergence", NANOG 20, October 2000. 221 9. Author's Address 223 Scott Poretsky 224 Avici Systems, Inc. 225 101 Billerica Avenue 226 N. Billerica, MA 01862 227 USA 229 Phone: + 1 978 964 2287 230 EMail: sporetsky@avici.com 232 10. Full Copyright Statement 234 Copyright (C) The Internet Society (1998). All Rights 235 Reserved. 237 This document and translations of it may be copied and 238 furnished to others, and derivative works that comment on or 239 otherwise explain it or assist in its implementation may be 240 prepared, copied, published and distributed, in whole or in 241 part, without restriction of any kind, provided that the above 242 copyright notice and this paragraph are included on all such 243 copies and derivative works. However, this document itself may 244 not be modified in any way, such as by removing the copyright 245 notice or references to the Internet Society or other Internet 246 organizations, except as needed for the purpose of developing 247 Internet standards in which case the procedures for copyrights 248 defined in the Internet Standards process must be followed, or 249 as required to translate it into languages other than English. 251 The limited permissions granted above are perpetual and will 252 not be revoked by the Internet Society or its successors or 253 assigns. This document and the information contained herein is 254 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 255 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 256 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 257 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 258 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 259 FOR A PARTICULAR PURPOSE.