idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-app-14.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 284. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 295. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 302. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 308. 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 (May 2008) is 5822 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-14 == Outdated reference: A later version (-23) exists of draft-ietf-bmwg-igp-dataplane-conv-term-14 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: May 2008 4 Intended Status: Informational 6 Scott Poretsky 7 Reef Point Systems 9 November 2007 11 Considerations for Benchmarking 12 Link-State 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....4 60 6. IANA Considerations.........................................4 61 7. Security Considerations.....................................4 62 8. Acknowledgements............................................5 63 9. Normative References........................................5 64 10. Author's Address...........................................6 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/recovery indication time 111 Layer 2 failure/recovery 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 -Increased Forwarding Delay due to Queueing 130 The contribution of each of these factors listed above will vary 131 with each router vendors' architecture and IGP implementation. 132 Routers may have a centralized forwarding architecture, in which 133 one route table is calculated and referenced for all arriving 134 packets, or a distributed forwarding architecture, in which the 135 central route table is calculated and distributed to the 136 interfaces for local look-up as packets arrive. The distributed 137 route tables are typically maintained in hardware. 139 It is therefore necessary to design a convergence test that 140 considers all of these components contributing to convergence time 141 and is independent of the Device Under Test (DUT) architecture, 142 The benefit of designing a test for these considerations is that 143 it enables black-box testing in which knowledge of the routers' 144 internal implementations is not required. It is then possible 145 to make valid use of the convergence benchmarking metrics when 146 comparing routers from different vendors. 148 4. Network Events that Cause Convergence 149 There are different types of network events that can cause IGP 150 convergence. These network events are as follow: 151 * administrative link removal 152 * unplanned link failure 153 * line card failure 154 * route changes such as withdrawal, flap, next-hop change, 155 and cost change. 156 * session loss due to loss of peer or adjancency 157 * link recovery 158 * link insertion 159 IGP Data Plane Route Convergence 161 When benchmarking a router it is important to measure convergence 162 time for local and remote occurrence of these network events. 163 The convergence time measured will vary whether the network event 164 occurred locally or remotely due to varying combinations of 165 factors listed in the previous sections. This behavior makes it 166 possible to design purely black-box tests that isolate 167 measurements for each of the components of convergence time. 169 5. Use of Data Plane for IGP Route Convergence Benchmarking 170 Customers of service providers use packet loss as the metric to 171 calculate convergence time. Packet loss is an externally 172 observable event having direct impact on customers' application 173 performance. For this reason it is important to develop a 174 standard router benchmarking methodology and terminology that is 175 a Direct Measure of Quality (DMOQ) for measuring IGP convergence. 176 Such a methodology uses the data plane as described in [Po07m] 177 using the terminology provided in [Po07t]. 179 An additional benefit of using packet loss for calculation of 180 IGP Route Convergence time is that it enables black-box tests to 181 be designed. Data traffic can be offered to the 182 device under test (DUT), an emulated network event can be forced 183 to occur, and packet loss can be externally measured to calculate 184 the convergence time. Knowledge of the DUT architecture and IGP 185 implementation is not required. There is no need to rely on the 186 DUT to produce the test results. There is no need to build 187 intrusive test harnesses for the DUT. 189 Use of data traffic and measurement of packet loss on the data 190 plane also enables Route Convergence methodology test cases that 191 consider the time for the Route Controller to update the FIB on 192 the forwarding engine of the hardware. A router is not fully 193 converged until all components are updated and traffic is 194 rerouted to the correct egress interface. As long as there is 195 packet loss, routes have not converged. It is possible to send 196 diverse traffic flows to destinations matching every route in 197 the FIB so that the time it takes for the router to converge an 198 entire route table can be benchmarked. 200 6. IANA Considerations 202 This document requires no IANA considerations. 204 7. Security Considerations 206 Documents of this type do not directly effect the security 207 of the Internet or of corporate networks as long as 208 benchmarking is not performed on devices or systems 209 connected to production networks. 211 IGP Data Plane Route Convergence 213 8. Acknowledgements 214 Thanks to Curtis Villamizar for sharing so much of his knowledge 215 and experience through the years. Thanks to Ron Bonica, Al Morton, 216 David Ward, and the BMWG for their reviews and comments. 218 9. References 219 9.1 Normative References 221 [Br97] Bradner, S., "Key words for use in RFCs to Indicate 222 Requirement Levels", RFC 2119, March 1997 224 [Ca90] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP 225 and Dual Environments", RFC 1195, December 1990. 227 [Mo98] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 229 [Po07m] Poretsky, S., "Benchmarking Methodology for 230 Link-State IGP Data Plane Route Convergence", 231 draft-ietf-bmwg-igp-dataplane-conv-meth-14, work in 232 progress, November 2007. 234 [Po07t] Poretsky, S., "Benchmarking Terminology for 235 Link-State IGP Data Plane Route Convergence", 236 draft-ietf-bmwg-igp-dataplane-conv-term-14, work in 237 progress, November 2007. 239 9.2 Informative References 241 [Al00] Alaettinoglu, C., Jacobson, V., and Yu, H., "Towards 242 Millisecond IGP Convergence", NANOG 20, March 2000. 244 [Al02] Alaettinoglu, C. and Casner, S., "ISIS Routing on the 245 Qwest Backbone: a Recipe for Subsecond ISIS Convergence", 246 NANOG 24, March 2002. 248 [Fi02] Filsfils, C., "Deploying Tight-SLA Services on an 249 Internet Backbone: ISIS Fast Convergence and 250 Differentiated Services Design (tutorial)", NANOG 25, 251 March 2002. 253 [Ka02] Katz, D., "Why are we Scared of SPF? IGP Scaling and 254 Stability", NANOG 25, March 2002. 256 [Vi02] Villamizar, C., "Convergence and Restoration Techniques 257 for ISP Interior Routing", NANOG 25, March 2002. 259 IGP Data Plane Route Convergence 261 10. Author's Address 262 Scott Poretsky 263 Reef Point Systems 264 3 Federal Street 265 Billerica, MA 01821 USA 266 Phone: + 1 508 439 9008 267 EMail: sporetsky@reefpoint.com 269 Full Copyright Statement 271 Copyright (C) The IETF Trust (2007). 273 This document is subject to the rights, licenses and restrictions 274 contained in BCP 78, and except as set forth therein, the authors 275 retain all their rights. 277 This document and the information contained herein are provided 278 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 279 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 280 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 281 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 282 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 283 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 284 FOR A PARTICULAR PURPOSE. 286 Intellectual Property 288 The IETF takes no position regarding the validity or scope of any 289 Intellectual Property Rights or other rights that might be claimed to 290 pertain to the implementation or use of the technology described in 291 this document or the extent to which any license under such rights 292 might or might not be available; nor does it represent that it has 293 made any independent effort to identify any such rights. Information 294 on the procedures with respect to rights in RFC documents can be 295 found in BCP 78 and BCP 79. 297 Copies of IPR disclosures made to the IETF Secretariat and any 298 assurances of licenses to be made available, or the result of an 299 attempt made to obtain a general license or permission for the use of 300 such proprietary rights by implementers or users of this 301 specification can be obtained from the IETF on-line IPR repository at 302 http://www.ietf.org/ipr. 304 The IETF invites any interested party to bring to its attention any 305 copyrights, patents or patent applications, or other proprietary 306 rights that may cover technology that may be required to implement 307 this standard. Please address the information to the IETF at ietf- 308 ipr@ietf.org. 310 Acknowledgement 312 Funding for the RFC Editor function is currently provided by the 313 Internet Society.