idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-app-11.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 263. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 274. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 281. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 287. ** 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 (November 2006) is 6371 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-11 ** 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-11 ** 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: November 2006 4 Scott Poretsky 5 Reef Point Systems 7 May 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 as follow: 136 * administrative link removal 137 * unplanned link failure 138 * line card failure 139 * route changes such as withdrawal, flap, next-hop change, 140 and cost change. 142 When benchmarking a router it is important to measure convergence 143 time for local and remote occurrence of these network events. 144 The convergence time measured will vary whether the network event 145 occurred locally or remotely due to varying combinations of 146 factors listed in the previous sections. This behavior makes it 147 possible to design purely black-box tests that isolate 148 measurements for each of the components of convergence time. 150 IGP Data Plane Route Convergence 152 5. Use of Data Plane for IGP Route Convergence Benchmarking 153 Customers of service providers use packet loss as the metric to 154 calculate convergence time. Packet loss is an externally 155 observable event having direct impact on customers' application 156 performance. For this reason it is important to develop a 157 standard router benchmarking methodology and terminology that is 158 a Direct Measure of Quality (DMOQ) for measuring IGP convergence. 159 Such a methodology uses the data plane as described in [1] and [2]. 161 An additional benefit of using packet loss for calculation of 162 IGP Route Convergence time is that it enables black-box tests to 163 be designed. Data traffic can be offered to the 164 device under test (DUT), an emulated network event can be forced 165 to occur, and packet loss can be externally measured to calculate 166 the convergence time. Knowledge of the DUT architecture and IGP 167 implementation is not required. There is no need to rely on the 168 DUT to produce the test results. There is no need to build 169 intrusive test harnesses for the DUT. 171 Use of data traffic and measurement of packet loss on the data 172 plane also enables Route Convergence methodology test cases that 173 consider the time for the Route Controller to update the FIB on 174 the forwarding engine of the hardware. A router is not fully 175 converged until all components are updated and traffic is 176 rerouted to the correct egress interface. As long as there is 177 packet loss, routes have not converged. It is possible to send 178 diverse traffic flows to destinations matching every route in 179 the FIB so that the time it takes for the router to converge an 180 entire route table can be benchmarked. 182 6. IANA Considerations 184 This document requires no IANA considerations. 186 7. Security Considerations 188 Documents of this type do not directly effect the security 189 of the Internet or of corporate networks as long as 190 benchmarking is not performed on devices or systems 191 connected to production networks. 193 8. Acknowledgements 194 Thanks to Curtis Villamizar for sharing so much of his 195 knowledge and experience through the years. Also, special 196 thanks to the many Network Engineers and Network Architects 197 at the Service Providers who are always eager to discuss 198 Route Convergence benchmarking. 200 IGP Data Plane Route Convergence 202 9. References 203 9.1 Normative References 204 [1] Poretsky, S., "Benchmarking Methodology for IGP Data Plane 205 Route Convergence", 206 draft-ietf-bmwg-igp-dataplane-conv-meth-11, work in progress, 207 May 2006. 209 [2] Poretsky, S., "Benchmarking Terminology for IGP Data Plane 210 Route Convergence", 211 draft-ietf-bmwg-igp-dataplane-conv-term-11, work in progress, 212 May 2006. 214 [3] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual 215 Environments", RFC 1195, December 1990. 217 [4] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 219 9.2 Informative References 220 [5] Villamizar, C., "Convergence and Restoration Techniques for 221 ISP Interior Routing", NANOG 25, March 2002. 223 [6] Katz, D., "Why are we Scared of SPF? IGP Scaling and 224 Stability", NANOG 25, March 2002. 226 [7] Filsfils, C., "Deploying Tight-SLA Services on an Internet 227 Backbone: ISIS Fast Convergence and Differentiated Services 228 Design (tutorial)", NANOG 25, March 2002. 230 [8] Alaettinoglu, C. and Casner, S., "ISIS Routing on the Qwest 231 Backbone: a Recipe for Subsecond ISIS Convergence", NANOG 24, 232 March 2002. 234 [9] Alaettinoglu, C., Jacobson, V., and Yu, H., "Towards 235 Millisecond IGP Convergence", NANOG 20, March 2000. 237 10. Author's Address 239 Scott Poretsky 240 Reef Point Systems 241 8 New England Executive Park 242 Burlington, MA 01803 243 USA 245 Phone: + 1 508 439 9008 246 EMail: sporetsky@reefpoint.com 247 IGP Data Plane Route Convergence 249 Full Copyright Statement 251 Copyright (C) The Internet Society (2006). 253 This document is subject to the rights, licenses and restrictions 254 contained in BCP 78, and except as set forth therein, the authors 255 retain all their rights. 257 This document and the information contained herein are provided on an 258 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 259 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 260 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 261 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 262 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 263 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 265 Intellectual Property 267 The IETF takes no position regarding the validity or scope of any 268 Intellectual Property Rights or other rights that might be claimed to 269 pertain to the implementation or use of the technology described in 270 this document or the extent to which any license under such rights 271 might or might not be available; nor does it represent that it has 272 made any independent effort to identify any such rights. Information 273 on the procedures with respect to rights in RFC documents can be 274 found in BCP 78 and BCP 79. 276 Copies of IPR disclosures made to the IETF Secretariat and any 277 assurances of licenses to be made available, or the result of an 278 attempt made to obtain a general license or permission for the use of 279 such proprietary rights by implementers or users of this 280 specification can be obtained from the IETF on-line IPR repository at 281 http://www.ietf.org/ipr. 283 The IETF invites any interested party to bring to its attention any 284 copyrights, patents or patent applications, or other proprietary 285 rights that may cover technology that may be required to implement 286 this standard. Please address the information to the IETF at ietf- 287 ipr@ietf.org. 289 Acknowledgement 291 Funding for the RFC Editor function is currently provided by the 292 Internet Society.