idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-app-13.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 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 276. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 287. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 294. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 300. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 2008) is 5944 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-23) exists of draft-ietf-bmwg-igp-dataplane-conv-meth-13 == Outdated reference: A later version (-23) exists of draft-ietf-bmwg-igp-dataplane-conv-term-13 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 7 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: January 2008 4 Intended Status: Informational 6 Scott Poretsky 7 Reef Point Systems 9 July 2007 11 Considerations for Benchmarking 12 IGP Data Plane Route Convergence 14 16 Intellectual Property Rights (IPR) statement: 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Status of this Memo 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 ABSTRACT 44 This document discusses considerations for benchmarking Interior 45 Gateway Protocol (IGP) Route Convergence for any link-state IGP, such 46 as Intermediate System-Intermediate System (ISIS) and Open-Shorted 47 Path first (OSPF). A companion methodology document is to 48 be used for benchmarking IGP convergence time through externally 49 observable (black box) data plane measurements. A companion 50 terminology document is to be referenced to support the benchmarking. 52 IGP Data Plane Route Convergence 54 Table of Contents 55 1. Introduction ...............................................2 56 2. Existing definitions .......................................2 57 3. Factors for IGP Route Convergence Time......................2 58 4. Network Events that Cause Route Convergence.................3 59 5. Use of Data Plane for IGP Route Convergence Benchmarking....3 60 6. IANA Considerations.........................................4 61 7. Security Considerations.....................................4 62 8. Acknowledgements............................................4 63 9. Normative References........................................5 64 10. Author's Address...........................................5 66 1. Introduction 67 Convergence Time is a critical performance parameter. Customers 68 of Service Providers use convergence packet loss [Po07t] due to 69 Interior Gateway Protocol (IGP) Convergence as a key metric of 70 their network service quality. Service Providers use IGP 71 Convergence time as a key metric of router design and architecture 72 for any IGP such as Intermediate System - Intermediate System 73 (ISIS) [Ca90] and Open-Shorted Path first (OSPF) [Mo98]. Fast 74 network convergence can be optimally achieved through deployment 75 of fast converging routers. The fundamental basis by which network 76 users and operators benchmark convergence is packet loss, which is 77 an externally observable event having direct impact on their 78 application performance. 80 IGP Route Convergence is a Direct Measure of Quality (DMOQ) when 81 benchmarking the data plane. For this reason it is important to 82 develop a standard router benchmarking methodology and terminology 83 for measuring IGP convergence that uses the data plane as described 84 in [Po07m] and [Po07t]. This document describes all of the factors 85 that influence a convergence measurement and how a purely black box 86 test can be designed to account for all of these factors. This 87 enables accurate benchmarking and evaluation for route convergence 88 time. 90 2. Existing definitions 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 93 this document are to be interpreted as described in BCP 14, RFC 94 2119 [Br97]. RFC 2119 defines the use of these key words to help 95 make the intent of standards track documents as clear as possible. 96 While this document uses these keywords, this document is not a 97 standards track document. 99 3. Factors for IGP Route Convergence Time 100 There are four major categories of factors contributing to the 101 measured Router IGP Convergence Time. As discussed in [Vi02], 102 [Ka02], [Fi02], [Al02] and [Al00], these categories are Event 103 Detection, Shortest Path First (SPF) Processing, IGP Advertisement, 104 and Forwarding Information Base (FIB) Update. These have numerous 105 components that influence the convergence time, as listed below: 107 IGP Data Plane Route Convergence 109 -Event Detection- 110 Physical Layer failure indication time 111 Layer 2 failure indication time 112 IGP Hello Dead Interval 114 -SPF Processing- 115 SPF Delay Time 116 SPF Hold time 117 SPF Execution time 119 -IGP Advertisement- 120 LSA/LSP Flood Packet Pacing 121 LSA/LSP Retransmission Packet Pacing 122 LSA/LSP Generation time 124 -FIB Update- 125 Tree Build time 126 Hardware Update time 128 The contribution of each of these factors listed above will vary 129 with each router vendors' architecture and IGP implementation. 130 It is therefore necessary to design a convergence test that 131 considers all of these components, not just one or a few of these 132 components. The additional benefit of designing a test for all 133 components is that it enables black-box testing in which knowledge 134 of the routers' internal implementations is not required. It is 135 then possible to make valid use of the convergence benchmarking 136 metrics when comparing routers from different vendors. 138 4. Network Events that Cause Convergence 139 There are different types of network events that can cause IGP 140 convergence. These network events are as follow: 141 * administrative link removal 142 * unplanned link failure 143 * line card failure 144 * route changes such as withdrawal, flap, next-hop change, 145 and cost change. 147 When benchmarking a router it is important to measure convergence 148 time for local and remote occurrence of these network events. 149 The convergence time measured will vary whether the network event 150 occurred locally or remotely due to varying combinations of 151 factors listed in the previous sections. This behavior makes it 152 possible to design purely black-box tests that isolate 153 measurements for each of the components of convergence time. 155 IGP Data Plane Route Convergence 157 5. Use of Data Plane for IGP Route Convergence Benchmarking 158 Customers of service providers use packet loss as the metric to 159 calculate convergence time. Packet loss is an externally 160 observable event having direct impact on customers' application 161 performance. For this reason it is important to develop a 162 standard router benchmarking methodology and terminology that is 163 a Direct Measure of Quality (DMOQ) for measuring IGP convergence. 164 Such a methodology uses the data plane as described in [Po07m] 165 using the terminology provided in [Po07t]. 167 An additional benefit of using packet loss for calculation of 168 IGP Route Convergence time is that it enables black-box tests to 169 be designed. Data traffic can be offered to the 170 device under test (DUT), an emulated network event can be forced 171 to occur, and packet loss can be externally measured to calculate 172 the convergence time. Knowledge of the DUT architecture and IGP 173 implementation is not required. There is no need to rely on the 174 DUT to produce the test results. There is no need to build 175 intrusive test harnesses for the DUT. 177 Use of data traffic and measurement of packet loss on the data 178 plane also enables Route Convergence methodology test cases that 179 consider the time for the Route Controller to update the FIB on 180 the forwarding engine of the hardware. A router is not fully 181 converged until all components are updated and traffic is 182 rerouted to the correct egress interface. As long as there is 183 packet loss, routes have not converged. It is possible to send 184 diverse traffic flows to destinations matching every route in 185 the FIB so that the time it takes for the router to converge an 186 entire route table can be benchmarked. 188 6. IANA Considerations 190 This document requires no IANA considerations. 192 7. Security Considerations 194 Documents of this type do not directly effect the security 195 of the Internet or of corporate networks as long as 196 benchmarking is not performed on devices or systems 197 connected to production networks. 199 8. Acknowledgements 200 Thanks to Curtis Villamizar for sharing so much of his 201 knowledge and experience through the years. Also, special 202 thanks to the many Network Engineers and Network Architects 203 at the Service Providers who are always eager to discuss 204 Route Convergence benchmarking. 206 IGP Data Plane Route Convergence 208 9. References 209 9.1 Normative References 211 [Br97] Bradner, S., "Key words for use in RFCs to Indicate 212 Requirement Levels", RFC 2119, March 1997 214 [Ca90] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP 215 and Dual Environments", RFC 1195, December 1990. 217 [Mo98] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 219 [Po07m] Poretsky, S., "Benchmarking Methodology for IGP Data 220 Plane Route Convergence", 221 draft-ietf-bmwg-igp-dataplane-conv-meth-13, work in 222 progress, July 2007. 224 [Po07t] Poretsky, S., "Benchmarking Terminology for IGP Data 225 Plane Route Convergence", 226 draft-ietf-bmwg-igp-dataplane-conv-term-13, work in 227 progress, July 2007. 229 9.2 Informative References 231 [Al00] Alaettinoglu, C., Jacobson, V., and Yu, H., "Towards 232 Millisecond IGP Convergence", NANOG 20, March 2000. 234 [Al02] Alaettinoglu, C. and Casner, S., "ISIS Routing on the 235 Qwest Backbone: a Recipe for Subsecond ISIS Convergence", 236 NANOG 24, March 2002. 238 [Fi02] Filsfils, C., "Deploying Tight-SLA Services on an 239 Internet Backbone: ISIS Fast Convergence and 240 Differentiated Services Design (tutorial)", NANOG 25, 241 March 2002. 243 [Ka02] Katz, D., "Why are we Scared of SPF? IGP Scaling and 244 Stability", NANOG 25, March 2002. 246 [Vi02] Villamizar, C., "Convergence and Restoration Techniques 247 for ISP Interior Routing", NANOG 25, March 2002. 249 10. Author's Address 251 Scott Poretsky 252 Reef Point Systems 253 8 New England Executive Park 254 Burlington, MA 01803 255 USA 257 Phone: + 1 508 439 9008 258 EMail: sporetsky@reefpoint.com 259 IGP Data Plane Route Convergence 261 Full Copyright Statement 263 Copyright (C) The IETF Trust (2007). 265 This document is subject to the rights, licenses and restrictions 266 contained in BCP 78, and except as set forth therein, the authors 267 retain all their rights. 269 This document and the information contained herein are provided 270 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 271 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 272 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 273 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 274 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 275 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 276 FOR A PARTICULAR PURPOSE. 278 Intellectual Property 280 The IETF takes no position regarding the validity or scope of any 281 Intellectual Property Rights or other rights that might be claimed to 282 pertain to the implementation or use of the technology described in 283 this document or the extent to which any license under such rights 284 might or might not be available; nor does it represent that it has 285 made any independent effort to identify any such rights. Information 286 on the procedures with respect to rights in RFC documents can be 287 found in BCP 78 and BCP 79. 289 Copies of IPR disclosures made to the IETF Secretariat and any 290 assurances of licenses to be made available, or the result of an 291 attempt made to obtain a general license or permission for the use of 292 such proprietary rights by implementers or users of this 293 specification can be obtained from the IETF on-line IPR repository at 294 http://www.ietf.org/ipr. 296 The IETF invites any interested party to bring to its attention any 297 copyrights, patents or patent applications, or other proprietary 298 rights that may cover technology that may be required to implement 299 this standard. Please address the information to the IETF at ietf- 300 ipr@ietf.org. 302 Acknowledgement 304 Funding for the RFC Editor function is currently provided by the 305 Internet Society.