idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-app-05.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 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 251. ** 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. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 46 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 (October 2005) is 6762 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 193 looks like a reference -- Missing reference section? '2' on line 197 looks like a reference -- Missing reference section? '3' on line 201 looks like a reference -- Missing reference section? '4' on line 204 looks like a reference -- Missing reference section? 'Br97' on line 92 looks like a reference -- Missing reference section? '5' on line 206 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: 14 errors (**), 0 flaws (~~), 4 warnings (==), 14 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: October 2005 4 Scott Poretsky 5 Quarry Technologies 7 February 2005 9 Considerations for Benchmarking 10 IGP Data Plane Route Convergence 12 14 Intellectual Property Rights (IPR) statement: 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, or 17 will be disclosed, and any of which I become aware will be disclosed, 18 in accordance with RFC 3668. 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........................................4 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. 192 8. Normative References 193 [1] Poretsky, S., "Benchmarking Methodology for IGP Data Plane 194 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-meth-04, 195 work in progress, February 2005. 197 [2] Poretsky, S., "Benchmarking Terminology for IGP Data Plane 198 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-04, 199 work in progress, February 2005. 201 [3] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual 202 Environments", RFC 1195, December 1990. 204 [4] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 206 [5] Villamizar, C., "Convergence and Restoration Techniques for 207 ISP Interior Routing", NANOG 25, October 2002. 209 IGP Data Plane Route Convergence 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 Quarry Technologies 229 8 New England Executive Park 230 Burlington, MA 01803 231 USA 233 Phone: + 1 781 395 5090 234 EMail: sporetsky@quarrytech.com 236 Intellectual Property Statement 238 The IETF takes no position regarding the validity or scope of any Intel- 239 lectual Property Rights or other rights that might be claimed to pertain 240 to the implementation or use of the technology described in this docu- 241 ment or the extent to which any license under such rights might or might 242 not be available; nor does it represent that it has made any independent 243 effort to identify any such rights. Information on the procedures with 244 respect to rights in RFC documents can be found in BCP 78 and BCP 79. 246 Copies of IPR disclosures made to the IETF Secretariat and any 247 assurances of licenses to be made available, or the result of an attempt 248 made to obtain a general license or permission for the use of such 249 proprietary rights by implementers or users of this specification can be 250 obtained from the IETF on-line IPR repository at 251 http://www.ietf.org/ipr. 253 The IETF invites any interested party to bring to its attention any 254 copyrights, patents or patent applications, or other proprietary rights 255 that may cover technology that may be required to implement this stan- 256 dard. Please address the information to the IETF at ietf-ipr@ietf.org. 258 Disclaimer of Warranty 260 This document and the information contained herein are provided on an 261 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 262 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 263 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 264 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMA- 265 TION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 266 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 268 Copyright Statement 270 Copyright (C) The Internet Society (2005). This document is subject to 271 the rights, licenses and restrictions contained in BCP 78, and except as 272 set forth therein, the authors retain all their rights.