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