idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-app-09.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 260. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 271. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 278. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 284. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3], [4], [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 (June 2006) is 6525 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) == Outdated reference: A later version (-23) exists of draft-ietf-bmwg-igp-dataplane-conv-meth-09 ** Downref: Normative reference to an Informational draft: draft-ietf-bmwg-igp-dataplane-conv-meth (ref. '1') == Outdated reference: A later version (-23) exists of draft-ietf-bmwg-igp-dataplane-conv-term-09 ** Downref: Normative reference to an Informational draft: draft-ietf-bmwg-igp-dataplane-conv-term (ref. '2') Summary: 6 errors (**), 0 flaws (~~), 5 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: June 2006 4 Scott Poretsky 5 Reef Point Systems 7 January 2006 9 Considerations for Benchmarking 10 IGP Data Plane Route Convergence 12 14 Intellectual Property Rights (IPR) statement: 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Status of this Memo 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 ABSTRACT 42 This document provides considerations for IGP Route Convergence 43 benchmarking methodology [1] and IGP Route Convergence benchmarking 44 terminology [2]. The methodology and terminology are to be used 45 for benchmarking route convergence and can be applied to any 46 link-state IGP such as ISIS [3] and OSPF [4]. The data plane is 47 measured to obtain the convergence benchmarking metrics described 48 in [1]. 50 IGP Data Plane Route Convergence 52 Table of Contents 53 1. Introduction ...............................................2 54 2. Existing definitions .......................................2 55 3. Factors for IGP Route Convergence Time......................2 56 4. Network Events that Cause Route Convergence.................3 57 5. Use of Data Plane for IGP Route Convergence Benchmarking....3 58 6. IANA Considerations.........................................4 59 7. Security Considerations.....................................4 60 8. Acknowledgements............................................4 61 9. Normative References........................................5 62 10. Author's Address...........................................5 64 1. Introduction 65 Convergence Time is a critical performance parameter. Customers 66 of Service Providers use packet loss due to IGP Convergence as a 67 key metric of their network service quality. Service Providers 68 use IGP Convergence time as a key metric of router design and 69 architecture. Fast network convergence can be optimally achieved 70 through deployment of fast converging routers. The fundamental 71 basis by which network users and operators benchmark convergence 72 is packet loss, which is an externally observable event having 73 direct impact on their 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 [1] and [2]. This document describes all of the factors that 80 influence a convergence measurement and how a purely black box test 81 can be designed to account for all of these factors. This enables 82 accurate benchmarking and evaluation for route convergence time. 84 2. Existing definitions 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 BCP 14, RFC 88 2119. RFC 2119 defines the use of these key words to help make the 89 intent of standards track documents as clear as possible. While 90 this document uses these keywords, this document is not a standards 91 track document. 93 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 [5], [6], 97 [7], [8] and [9], these categories are Event Detection, SPF 98 Processing, IGP Advertisement, and FIB Update. These have 99 numerous components that influence the convergence time. These 100 are listed as follow: 102 IGP Data Plane Route Convergence 104 -Event Detection- 105 SONET failure indication time 106 PPP failure 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 The contribution of each of these factors listed above will vary 124 with each router vendors' architecture and IGP implementation. 125 It is therefore necessary to design a convergence test that 126 considers all of these components, not just one or a few of these 127 components. The additional benefit of designing a test for all 128 components is that it enables black-box testing in which knowledge 129 of the routers' internal implementations is not required. It is 130 then possible to make valid use of the convergence benchmarking 131 metrics when comparing routers from different vendors. 133 4. Network Events that Cause Convergence 134 There are different types of network events that can cause IGP 135 convergence. These network events are administrative link 136 removal, unplanned link failure, line card failure, and route 137 changes such as withdrawal, flap, next-hop change, and cost 138 change. When benchmarking a router it is important to measure 139 convergence time for local and remote occurrence of these network 140 events. The convergence time measured will vary whether the 141 network event occurred locally or remotely due to varying 142 combinations of factors listed in the previous sections. This 143 behavior makes it possible to design purely black-box tests that 144 isolate measurements for each of the components of convergence 145 time. 147 5. Use of Data Plane for IGP Route Convergence Benchmarking 148 Customers of service providers use packet loss as the metric to 149 calculate convergence time. Packet loss is an externally 150 observable event having direct impact on customers' application 151 performance. For this reason it is important to develop a 152 standard router benchmarking methodology and terminology that is 153 a Direct Measure of Quality (DMOQ) for measuring IGP convergence. 154 Such a methodology uses the data plane as described in [1] and [2]. 156 IGP Data Plane Route Convergence 158 An additional benefit of using packet loss for calculation of 159 IGP Route Convergence time is that it enables black-box tests to 160 be designed. Data traffic can be offered to the 161 device under test (DUT), an emulated network event can be forced 162 to occur, and packet loss can be externally measured to calculate 163 the convergence time. Knowledge of the DUT architecture and IGP 164 implementation is not required. There is no need to rely on the 165 DUT to produce the test results. There is no need to build 166 intrusive test harnesses for the DUT. 168 Use of data traffic and measurement of packet loss on the data 169 plane also enables Route Convergence methodology test cases that 170 consider the time for the Route Controller to update the FIB on 171 the forwarding engine of the hardware. A router is not fully 172 converged until all components are updated and traffic is 173 rerouted to the correct egress interface. As long as there is 174 packet loss, routes have not converged. It is possible to send 175 diverse traffic flows to destinations matching every route in 176 the FIB so that the time it takes for the router to converge an 177 entire route table can be benchmarked. 179 6. IANA Considerations 181 This document requires no IANA considerations. 183 7. Security Considerations 185 Documents of this type do not directly effect the security 186 of the Internet or of corporate networks as long as 187 benchmarking is not performed on devices or systems 188 connected to production networks. 190 8. Acknowledgements 191 Thanks to Curtis Villamizar for sharing so much of his 192 knowledge and experience through the years. Also, special 193 thanks to the many Network Engineers and Network Architects 194 at the Service Providers who are always eager to discuss 195 Route Convergence benchmarking. 197 IGP Data Plane Route Convergence 199 9. References 200 9.1 Normative References 201 [1] Poretsky, S., "Benchmarking Methodology for IGP Data Plane 202 Route Convergence", 203 draft-ietf-bmwg-igp-dataplane-conv-meth-09, work in progress, 204 January 2006. 206 [2] Poretsky, S., "Benchmarking Terminology for IGP Data Plane 207 Route Convergence", 208 draft-ietf-bmwg-igp-dataplane-conv-term-09, work in progress, 209 January 2006. 211 [3] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual 212 Environments", RFC 1195, December 1990. 214 [4] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 216 9.2 Informative References 217 [5] Villamizar, C., "Convergence and Restoration Techniques for 218 ISP Interior Routing", NANOG 25, January 2002. 220 [6] Katz, D., "Why are we Scared of SPF? IGP Scaling and 221 Stability", NANOG 25, January 2002. 223 [7] Filsfils, C., "Deploying Tight-SLA Services on an Internet 224 Backbone: ISIS Fast Convergence and Differentiated Services 225 Design (tutorial)", NANOG 25, January 2002. 227 [8] Alaettinoglu, C. and Casner, S., "ISIS Routing on the Qwest 228 Backbone: a Recipe for Subsecond ISIS Convergence", NANOG 24, 229 January 2002. 231 [9] Alaettinoglu, C., Jacobson, V., and Yu, H., "Towards 232 Millisecond IGP Convergence", NANOG 20, January 2000. 234 10. Author's Address 236 Scott Poretsky 237 Reef Point Systems 238 8 New England Executive Park 239 Burlington, MA 01803 240 USA 242 Phone: + 1 508 439 9008 243 EMail: sporetsky@reefpoint.com 244 IGP Data Plane Route Convergence 246 Full Copyright Statement 248 Copyright (C) The Internet Society (2006). 250 This document is subject to the rights, licenses and restrictions 251 contained in BCP 78, and except as set forth therein, the authors 252 retain all their rights. 254 This document and the information contained herein are provided on an 255 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 256 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 257 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 258 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 259 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 260 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 262 Intellectual Property 264 The IETF takes no position regarding the validity or scope of any 265 Intellectual Property Rights or other rights that might be claimed to 266 pertain to the implementation or use of the technology described in 267 this document or the extent to which any license under such rights 268 might or might not be available; nor does it represent that it has 269 made any independent effort to identify any such rights. Information 270 on the procedures with respect to rights in RFC documents can be 271 found in BCP 78 and BCP 79. 273 Copies of IPR disclosures made to the IETF Secretariat and any 274 assurances of licenses to be made available, or the result of an 275 attempt made to obtain a general license or permission for the use of 276 such proprietary rights by implementers or users of this 277 specification can be obtained from the IETF on-line IPR repository at 278 http://www.ietf.org/ipr. 280 The IETF invites any interested party to bring to its attention any 281 copyrights, patents or patent applications, or other proprietary 282 rights that may cover technology that may be required to implement 283 this standard. Please address the information to the IETF at ietf- 284 ipr@ietf.org. 286 Acknowledgement 288 Funding for the RFC Editor function is currently provided by the 289 Internet Society.