idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-app-07.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 251. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 262. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 269. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 275. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 20 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [8], [Br97], [9], [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 (January 2006) is 6669 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) -- Missing reference section? '1' on line 195 looks like a reference -- Missing reference section? '2' on line 199 looks like a reference -- Missing reference section? '3' on line 203 looks like a reference -- Missing reference section? '4' on line 206 looks like a reference -- Missing reference section? 'Br97' on line 92 looks like a reference -- Missing reference section? '5' on line 208 looks like a reference -- Missing reference section? '6' on line 211 looks like a reference -- Missing reference section? '7' on line 214 looks like a reference -- Missing reference section? '8' on line 218 looks like a reference -- Missing reference section? '9' on line 222 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 17 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: January 2006 4 Scott Poretsky 5 Reef Point Systems 7 July 2005 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 This document is an Internet-Draft and is in full conformance with 23 all provisions of Section 10 of RFC2026. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other 32 documents at any time. It is inappropriate to use Internet-Drafts 33 as reference material or to cite them other than as "work in 34 progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 ABSTRACT 43 This draft provides considerations for IGP Route Convergence 44 benchmarking methodology [1] and IGP Route Convergence benchmarking 45 terminology [2]. The methodology and terminology is to be used 46 for benchmarking route convergence and can be applied to any 47 link-state IGP such as ISIS [3] and OSPF [4]. The data plane is 48 measured to obtain the convergence benchmarking metrics described 49 in [1]. 51 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....3 59 6. Security Considerations.....................................4 60 7. Acknowledgements............................................4 61 8. Normative References........................................5 62 9. Author's Address............................................5 64 1. Introduction 65 IGP Convergence 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 this 87 document are to be interpreted as described in BCP 14, RFC 2119 88 [Br97]. RFC 2119 defines the use of these key words to help make the 89 intent of standards track documents as clear as possible. While this 90 document uses these keywords, this document is not a standards track 91 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 numerous 99 components that influence the convergence time. These are listed 100 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 change. 138 When benchmarking a router it is important to measure the 139 convergence time for local and remote occurrence of these network 140 events. The convergence time measured will vary whether the network 141 event occurred locally or remotely due to varying combinations of 142 factors listed in the previous sections. This behavior makes it 143 possible to design purely black-box tests that isolate 144 measurements for each of the components of convergence time. 146 5. Use of Data Plane for IGP Route Convergence Benchmarking 147 Customers of service providers use packet loss as the metric to 148 calculate convergence time. Packet loss is an externally observable 149 event having direct impact on customers' application performance. 150 For this reason it is important to develop a standard router 151 benchmarking methodology and terminology that is a Direct Measure 152 of Quality (DMOQ) for measuring IGP convergence. Such a 153 methodology uses the data plane as described in [1] and [2]. 155 IGP Data Plane Route Convergence 157 An additional benefit of using packet loss for calculation of 158 IGP Route Convergence time is that it enables black-box tests to 159 be designed. Data traffic can be offered to the 160 device under test (DUT), an emulated network event can be forced 161 to occur, and packet loss can be externally measured to calculate 162 the convergence time. Knowledge of the DUT architecture and IGP 163 implementation is not required. There is no need to rely on the 164 DUT to produce the test results. There is no need to build 165 intrusive test harnesses for the DUT. 167 Use of data traffic and measurement of packet loss on the data 168 plane also enables Route Convergence methodology test cases that 169 consider the time for the Route Controller to update the FIB on 170 the forwarding engine of the hardware. A router is not fully 171 converged until all components are updated and traffic is 172 rerouted to the correct egress interface. As long as there is 173 packet loss, routes have not converged. It is possible to send 174 diverse traffic flows to destinations matching every route in the 175 FIB so that the time it takes for the router to converge an entire 176 route table can be benchmarked. 178 6. Security Considerations 180 Documents of this type do not directly effect the security of 181 the Internet or of corporate networks as long as benchmarking 182 is not performed on devices or systems connected to operating 183 networks. 185 7. Acknowledgements 186 Thanks to Curtis Villamizar for sharing so much of his 187 knowledge and experience through the years. Also, special 188 thanks to the many Network Engineers and Network Architects 189 at the Service Providers who are always eager to discuss 190 Route Convergence benchmarking. 192 IGP Data Plane Route Convergence 194 8. Normative References 195 [1] Poretsky, S., "Benchmarking Methodology for IGP Data Plane 196 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-meth-07, 197 work in progress, July 2005. 199 [2] Poretsky, S., "Benchmarking Terminology for IGP Data Plane 200 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-07, 201 work in progress, July 2005. 203 [3] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual 204 Environments", RFC 1195, December 1990. 206 [4] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 208 [5] Villamizar, C., "Convergence and Restoration Techniques for 209 ISP Interior Routing", NANOG 25, October 2002. 211 [6] Katz, D., "Why are we Scared of SPF? IGP Scaling and 212 Stability", NANOG 25, October 2002. 214 [7] Filsfils, C., "Deploying Tight-SLA Services on an Internet 215 Backbone: ISIS Fast Convergence and Differentiated Services 216 Design (tutorial)", NANOG 25, October 2002. 218 [8] Alaettinoglu, C. and Casner, S., "ISIS Routing on the Qwest 219 Backbone: a Recipe for Subsecond ISIS Convergence", NANOG 24, 220 October 2002. 222 [9] Alaettinoglu, C., Jacobson, V., and Yu, H., "Towards 223 Millisecond IGP Convergence", NANOG 20, October 2000. 225 9. Author's Address 227 Scott Poretsky 228 Reef Point Systems 229 8 New England Executive Park 230 Burlington, MA 01803 231 USA 233 Phone: + 1 781 395 5090 234 EMail: sporetsky@quarrytech.com 235 IGP Data Plane Route Convergence 237 Full Copyright Statement 239 Copyright (C) The Internet Society (2005). 241 This document is subject to the rights, licenses and restrictions 242 contained in BCP 78, and except as set forth therein, the authors 243 retain all their rights. 245 This document and the information contained herein are provided on an 246 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 247 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 248 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 249 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 250 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 251 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 253 Intellectual Property 255 The IETF takes no position regarding the validity or scope of any 256 Intellectual Property Rights or other rights that might be claimed to 257 pertain to the implementation or use of the technology described in 258 this document or the extent to which any license under such rights 259 might or might not be available; nor does it represent that it has 260 made any independent effort to identify any such rights. Information 261 on the procedures with respect to rights in RFC documents can be 262 found in BCP 78 and BCP 79. 264 Copies of IPR disclosures made to the IETF Secretariat and any 265 assurances of licenses to be made available, or the result of an 266 attempt made to obtain a general license or permission for the use of 267 such proprietary rights by implementers or users of this 268 specification can be obtained from the IETF on-line IPR repository at 269 http://www.ietf.org/ipr. 271 The IETF invites any interested party to bring to its attention any 272 copyrights, patents or patent applications, or other proprietary 273 rights that may cover technology that may be required to implement 274 this standard. Please address the information to the IETF at ietf- 275 ipr@ietf.org. 277 Acknowledgement 279 Funding for the RFC Editor function is currently provided by the 280 Internet Society.