idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-app-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors 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 (March 08, 2009) is 5527 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-17 == Outdated reference: A later version (-23) exists of draft-ietf-bmwg-igp-dataplane-conv-term-17 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Poretsky 2 Internet Draft Allot Communications 3 Expires: September 08, 2009 4 Intended Status: Informational March 08, 2009 6 Considerations for Benchmarking 7 Link-State IGP Data Plane Route Convergence 9 11 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on September 8, 2009. 32 Copyright Notice 33 Copyright (c) 2009 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents in effect on the date of 38 publication of this document (http://trustee.ietf.org/license-info). 39 Please review these documents carefully, as they describe your rights 40 and restrictions with respect to this document. 42 ABSTRACT 43 This document discusses considerations for benchmarking Interior 44 Gateway Protocol (IGP) Route Convergence for any link-state IGP, such 45 as Intermediate System-Intermediate System (ISIS) and Open-Shorted 46 Path first (OSPF). A companion methodology document is to 47 be used for benchmarking IGP convergence time through externally 48 observable (black box) data plane measurements. A companion 49 terminology document is to be referenced to support the benchmarking. 51 Link-State IGP Data Plane Route Convergence 53 Table of Contents 54 1. Introduction ...............................................2 55 2. Existing definitions .......................................2 56 3. Factors for IGP Route Convergence Time......................2 57 4. Network Events that Cause Route Convergence.................3 58 5. Use of Data Plane for IGP Route Convergence Benchmarking....4 59 6. IANA Considerations.........................................4 60 7. Security Considerations.....................................4 61 8. Acknowledgements............................................5 62 9. Normative References........................................5 63 10. Author's Address...........................................6 65 1. Introduction 66 Convergence Time is a critical performance parameter. Customers 67 of Service Providers use convergence packet loss [Po07t] due to 68 Interior Gateway Protocol (IGP) convergence as a key metric of 69 their network service quality. Service Providers use IGP 70 Convergence time as a key metric of router design and architecture 71 for any IGP such as Intermediate System - Intermediate System 72 (ISIS) [Ca90] and Open-Shorted Path first (OSPF) [Mo98]. Fast 73 network convergence can be optimally achieved through deployment 74 of fast converging routers. The fundamental basis by which network 75 users and operators benchmark convergence is packet loss, which is 76 an externally observable event having direct impact on their 77 application performance. 79 IGP Route Convergence is a Direct Measure of Quality (DMOQ) when 80 benchmarking the data plane. For this reason it is important to 81 develop a standard router benchmarking methodology and terminology 82 for measuring IGP convergence that uses the data plane as described 83 in [Po07m] and [Po07t]. This document describes all of the factors 84 that influence a convergence measurement and how a purely black box 85 test can be designed to account for all of these factors. This 86 enables accurate benchmarking and evaluation for route convergence 87 time. 89 2. Existing definitions 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 92 this document are to be interpreted as described in BCP 14, RFC 93 2119 [Br97]. RFC 2119 defines the use of these key words to help 94 make the intent of standards track documents as clear as possible. 95 While this document uses these keywords, this document is not a 96 standards track document. 98 3. Factors for IGP Route Convergence Time 99 There are four major categories of factors contributing to the 100 measured Router IGP Convergence Time. As discussed in [Vi02], 101 [Ka02], [Fi02], [Al02] and [Al00], these categories are Event 102 Detection, Shortest Path First (SPF) Processing, IGP Advertisement, 103 and Forwarding Information Base (FIB) Update. These have numerous 104 components that influence the convergence time, as listed below: 106 Link-State IGP Data Plane Route Convergence 108 -Event Detection- 109 Physical Layer failure/recovery indication time 110 Layer 2 failure/recovery indication time 111 IGP Hello Dead Interval 113 -SPF Processing- 114 SPF Delay Time 115 SPF Hold time 116 SPF Execution time 118 -IGP Advertisement- 119 LSA/LSP Flood Packet Pacing 120 LSA/LSP Retransmission Packet Pacing 121 LSA/LSP Generation time 123 -FIB Update- 124 Tree Build time 125 Hardware Update time 127 -Increased Forwarding Delay due to Queueing 129 The contribution of each of these factors listed above will vary 130 with each router vendors' architecture and IGP implementation. 131 Routers may have a centralized forwarding architecture, in which 132 one route table is calculated and referenced for all arriving 133 packets, or a distributed forwarding architecture, in which the 134 central route table is calculated and distributed to the 135 interfaces for local look-up as packets arrive. The distributed 136 route tables are typically maintained in hardware. 138 It is therefore necessary to design a convergence test that 139 considers all of these components contributing to convergence time 140 and is independent of the Device Under Test (DUT) architecture, 141 The benefit of designing a test for these considerations is that 142 it enables black-box testing in which knowledge of the routers' 143 internal implementations is not required. It is then possible 144 to make valid use of the convergence benchmarking metrics when 145 comparing routers from different vendors. 147 4. Network Events that Cause Convergence 148 There are different types of network events that can cause IGP 149 convergence. These network events are as follow: 150 * administrative link removal 151 * unplanned link failure 152 * line card failure 153 * route changes such as withdrawal, flap, next-hop change, 154 and cost change. 155 * session loss due to loss of peer or adjacency 156 * link recovery 157 * link insertion 158 Link-State IGP Data Plane Route Convergence 160 When benchmarking a router it is important to measure convergence 161 time for local and remote occurrence of these network events. 162 The convergence time measured will vary whether the network event 163 occurred locally or remotely due to varying combinations of 164 factors listed in the previous sections. This behavior makes it 165 possible to design purely black-box tests that isolate 166 measurements for each of the components of convergence time. 168 5. Use of Data Plane for IGP Route Convergence Benchmarking 169 Customers of service providers use packet loss as the metric to 170 calculate convergence time. Packet loss is an externally 171 observable event having direct impact on customers' application 172 performance. For this reason it is important to develop a 173 standard router benchmarking methodology and terminology that is 174 a Direct Measure of Quality (DMOQ) for measuring IGP convergence. 175 Such a methodology uses the data plane as described in [Po07m] 176 using the terminology provided in [Po07t]. 178 An additional benefit of using packet loss for calculation of 179 IGP Route Convergence time is that it enables black-box tests to 180 be designed. Data traffic can be offered to the 181 device under test (DUT), an emulated network event can be forced 182 to occur, and packet loss can be externally measured to calculate 183 the convergence time. Knowledge of the DUT architecture and IGP 184 implementation is not required. There is no need to rely on the 185 DUT to produce the test results. There is no need to build 186 intrusive test harnesses for the DUT. 188 Use of data traffic and measurement of packet loss on the data 189 plane also enables Route Convergence methodology test cases that 190 consider the time for the Route Controller to update the FIB on 191 the forwarding engine of the hardware. A router is not fully 192 converged until all components are updated and traffic is 193 rerouted to the correct egress interface. As long as there is 194 packet loss, routes have not converged. It is possible to send 195 diverse traffic flows to destinations matching every route in 196 the FIB so that the time it takes for the router to converge an 197 entire route table can be benchmarked. 199 6. IANA Considerations 201 This document requires no IANA considerations. 203 7. Security Considerations 205 Documents of this type do not directly affect the security of 206 Internet or corporate networks as long as benchmarking is not 207 performed on devices or systems connected to production networks. 208 Security threats and how to counter these in SIP and the media 209 layer is discussed in RFC3261, RFC3550, and RFC3711 and various 210 other drafts. This document attempts to formalize a set of 211 common methodology for benchmarking IGP convergence performance 212 in a lab environment. 214 Link-State IGP Data Plane Route Convergence 216 8. Acknowledgements 217 Thanks to Curtis Villamizar for sharing so much of his knowledge 218 and experience through the years. Thanks to Ron Bonica, Al Morton, 219 David Ward, and the BMWG for their reviews and comments. 221 9. References 222 9.1 Normative References 224 [Br97] Bradner, S., "Key words for use in RFCs to Indicate 225 Requirement Levels", RFC 2119, March 1997 227 [Ca90] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP 228 and Dual Environments", RFC 1195, December 1990. 230 [Mo98] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 232 [Po07m] Poretsky, S., "Benchmarking Methodology for 233 Link-State IGP Data Plane Route Convergence", 234 draft-ietf-bmwg-igp-dataplane-conv-meth-17, work in 235 progress, March 2009. 237 [Po07t] Poretsky, S., "Benchmarking Terminology for 238 Link-State IGP Data Plane Route Convergence", 239 draft-ietf-bmwg-igp-dataplane-conv-term-17, work in 240 progress, March 2009. 242 9.2 Informative References 244 [Al00] Alaettinoglu, C., Jacobson, V., and Yu, H., "Towards 245 Millisecond IGP Convergence", NANOG 20, March 2000. 247 [Al02] Alaettinoglu, C. and Casner, S., "ISIS Routing on the 248 Qwest Backbone: a Recipe for Subsecond ISIS Convergence", 249 NANOG 24, March 2002. 251 [Fi02] Filsfils, C., "Deploying Tight-SLA Services on an 252 Internet Backbone: ISIS Fast Convergence and 253 Differentiated Services Design (tutorial)", NANOG 25, 254 March 2002. 256 [Ka02] Katz, D., "Why are we Scared of SPF? IGP Scaling and 257 Stability", NANOG 25, March 2002. 259 [Vi02] Villamizar, C., "Convergence and Restoration Techniques 260 for ISP Interior Routing", NANOG 25, March 2002. 262 Link-State IGP Data Plane Route Convergence 264 10. Author's Address 266 Scott Poretsky 267 Allot Communications 268 67 South Bedford Street, Suite 400 269 Burlington, MA 01803 270 USA 271 Phone: + 1 508 309 2179 272 Email: sporetsky@allot.com