idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-app-01.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 are 45 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 (April 2004) is 7315 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 190 looks like a reference -- Missing reference section? '2' on line 194 looks like a reference -- Missing reference section? '3' on line 198 looks like a reference -- Missing reference section? '4' on line 201 looks like a reference -- Missing reference section? '5' on line 203 looks like a reference -- Missing reference section? '6' on line 206 looks like a reference -- Missing reference section? '7' on line 209 looks like a reference -- Missing reference section? '8' on line 215 looks like a reference -- Missing reference section? '9' on line 219 looks like a reference Summary: 7 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: April 2004 4 Scott Poretsky 5 Quarry Technologies 7 October 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 benchmarking 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 network users and operators benchmark convergence 67 is packet loss, which is an externally observable event having 68 direct impact on their application performance. 70 IGP Route Convergence is a Direct Measure of Quality (DMOQ) when 71 benchmarking the data plane. For this reason it is important to 72 develop a standard router benchmarking methodology and terminology 73 for measuring IGP convergence that uses the data plane as described 74 in [1] and [2]. This document describes all of the factors that 75 influence a convergence measurement and how a purely black box test 76 can be designed to account for all of these factors. This enables 77 accurate benchmarking and evaluation for route convergence time. 79 2. Existing definitions 81 For the sake of clarity and continuity this RFC adopts the template 82 for definitions set out in Section 2 of RFC 1242. Definitions are 83 indexed and grouped together in sections for ease of reference. 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 87 this document are to be interpreted as described in RFC 2119. 89 3. Factors for IGP Route Convergence Time 91 There are four major categories of factors contributing to the 92 measured Router IGP Convergence Time. As discussed in [5], [6], 93 [7], [8] and [9], these categories are Event Detection, SPF 94 Processing, IGP Advertisement, and FIB Update. These have numerous 95 components that influence the convergence time. These are listed 96 as follow: 98 -Event Detection- 99 SONET failure indication time 100 PPP failure indication time 101 IGP Hello Dead Interval 103 -SPF Processing- 104 SPF Delay Time 105 SPF Hold time 106 SPF Execution time 107 IGP Data Plane Route Convergence 108 -IGP Advertisement- 109 LSA/LSP Flood Packet Pacing 110 LSA/LSP Retransmission Packet Pacing 111 LSA/LSP Generation time 113 -FIB Update- 114 Tree Build time 115 Hardware Update time 117 The contribution of each of these factors listed above will vary 118 with each router vendors' architecture and IGP implementation. 119 It is therefore necessary to design a convergence test that 120 considers all of these components, not just one or a few of these 121 components. The additional benefit of designing a test for all 122 components is that it enables black-box testing in which knowledge 123 of the routers' internal implementations is not required. It is 124 then possible to make valid use of the convergence benchmarking 125 metrics when comparing routers from different vendors. 127 4. Network Events that Cause Convergence 129 There are different types of network events that can cause IGP 130 convergence. These network events are administrative link 131 removal, unplanned link failure, line card failure, and route 132 changes such as withdrawal, flap, next-hop change, and cost change. 133 When benchmarking a router it is important to measure the 134 convergence time for local and remote occurrence of these network 135 events. The convergence time measured will vary whether the network 136 event occurred locally or remotely due to varying combinations of 137 factors listed in the previous sections. This behavior makes it 138 possible to design purely black-box tests that isolate 139 measurements for each of the components of convergence time. 141 5. Use of Data Plane for IGP Route Convergence Benchmarking 143 Customers of service providers use packet loss as the metric to 144 calculate convergence time. Packet loss is an externally observable 145 event having direct impact on customers' application performance. 146 For this reason it is important to develop a standard router 147 benchmarking methodology and terminology that is a Direct Measure 148 of Quality (DMOQ)for measuring IGP convergence. Such a 149 methodology uses the data plane as described in [1] and [2]. 151 An additional benefit of using packet loss for calculation of 152 IGP Route Convergence time is that it enables black-box tests to 153 be designed. Data traffic can be offered to the 154 device under test (DUT), an emulated network event can be forced 155 to occur, and packet loss can be externally measured to calculate 156 the convergence time. Knowledge of the DUT architecture and IGP 157 implementation is not required. There is no need to rely on the 158 DUT to produce the test results. There is no need to build 159 intrusive test harnesses for the DUT. 161 IGP Data Plane Route Convergence 163 Use of data traffic and measurement of packet loss on the data 164 plane also enables Route Convergence methodology test cases that 165 consider the time for the Route Controller to update the FIB on 166 the forwarding engine of the hardware. A router is not fully 167 converged until all components are updated and traffic is 168 rerouted to the correct egress interface. As long as there is 169 packet loss, routes have not converged. It is possible to send 170 diverse traffic flows to destinations matching every route in the 171 FIB so that the time it takes for the router to converge an entire 172 route table can be benchmarked. 174 6. Security Considerations 176 Documents of this type do not directly effect the security of 177 the Internet or of corporate networks as long as benchmarking 178 is not performed on devices or systems connected to operating 179 networks. 181 7. Acknowledgements 182 Thanks to Curtis Villamizar for sharing so much of his 183 knowledge and experience through the years. Also, special 184 thanks to the many Network Engineers and Network Architects 185 at the Service Providers who are always eager to discuss 186 Route Convergence. 188 8. References 190 [1] Poretsky, S., "Benchmarking Methodology for IGP Data Plane 191 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-meth-01, 192 work in progress, October 2003. 194 [2] Poretsky, S., "Benchmarking Terminology for IGP Data Plane 195 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-01, 196 work in progress, October 2003. 198 [3] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual 199 Environments", RFC 1195, December 1990. 201 [4] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 203 [5] Villamizar, C., "Convergence and Restoration Techniques for 204 ISP Interior Routing", NANOG 25, October 2002. 206 [6] Katz, D., "Why are we Scared of SPF? IGP Scaling and 207 Stability", NANOG 25, October 2002. 209 [7] Filsfils, C., "Deploying Tight-SLA Services on an Internet 210 Backbone: ISIS Fast Convergence and Differentiated Services 211 Design (tutorial)", NANOG 25, October 2002. 213 IGP Data Plane Route Convergence 215 [8] Alaettinoglu, C. and Casner, S., "ISIS Routing on the Qwest 216 Backbone: a Recipe for Subsecond ISIS Convergence", NANOG 24, 217 October 2002. 219 [9] Alaettinoglu, C., Jacobson, V., and Yu, H., "Towards 220 Millisecond IGP Convergence", NANOG 20, October 2000. 222 9. Author's Address 224 Scott Poretsky 225 Quarry Technologies 226 8 New England Executive Park 227 Burlington, MA 01803 228 USA 230 Phone: + 1 781 395 5090 231 EMail: sporetsky@quarrytech.com 233 10. Full Copyright Statement 235 Copyright (C) The Internet Society (1998). All Rights 236 Reserved. 238 This document and translations of it may be copied and 239 furnished to others, and derivative works that comment on or 240 otherwise explain it or assist in its implementation may be 241 prepared, copied, published and distributed, in whole or in 242 part, without restriction of any kind, provided that the above 243 copyright notice and this paragraph are included on all such 244 copies and derivative works. However, this document itself may 245 not be modified in any way, such as by removing the copyright 246 notice or references to the Internet Society or other Internet 247 organizations, except as needed for the purpose of developing 248 Internet standards in which case the procedures for copyrights 249 defined in the Internet Standards process must be followed, or 250 as required to translate it into languages other than English. 252 The limited permissions granted above are perpetual and will 253 not be revoked by the Internet Society or its successors or 254 assigns. This document and the information contained herein is 255 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 256 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 257 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 258 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 259 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 260 FOR A PARTICULAR PURPOSE.