idnits 2.17.1 draft-ietf-bmwg-igp-dataplane-conv-app-04.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 252. ** 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 == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 5) being 70 lines == 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 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [8], [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 (April 2005) is 6950 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 194 looks like a reference -- Missing reference section? '2' on line 198 looks like a reference -- Missing reference section? '3' on line 202 looks like a reference -- Missing reference section? '4' on line 205 looks like a reference -- Missing reference section? '5' on line 207 looks like a reference -- Missing reference section? '6' on line 212 looks like a reference -- Missing reference section? '7' on line 215 looks like a reference -- Missing reference section? '8' on line 219 looks like a reference -- Missing reference section? '9' on line 223 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 5 warnings (==), 13 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: April 2005 4 Scott Poretsky 5 Quarry Technologies 7 October 2004 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. 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 86 For the sake of clarity and continuity this RFC adopts the template 87 for definitions set out in Section 2 of RFC 1242. Definitions are 88 indexed and grouped together in sections for ease of reference. 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 RFC 2119. 94 3. Factors for IGP Route Convergence Time 96 There are four major categories of factors contributing to the 97 measured Router IGP Convergence Time. As discussed in [5], [6], 98 [7], [8] and [9], these categories are Event Detection, SPF 99 Processing, IGP Advertisement, and FIB Update. These have numerous 100 components that influence the convergence time. These are listed 101 as follow: 103 IGP Data Plane Route Convergence 105 -Event Detection- 106 SONET failure indication time 107 PPP failure indication time 108 IGP Hello Dead Interval 110 -SPF Processing- 111 SPF Delay Time 112 SPF Hold time 113 SPF Execution time 115 -IGP Advertisement- 116 LSA/LSP Flood Packet Pacing 117 LSA/LSP Retransmission Packet Pacing 118 LSA/LSP Generation time 120 -FIB Update- 121 Tree Build time 122 Hardware Update time 124 The contribution of each of these factors listed above will vary 125 with each router vendors' architecture and IGP implementation. 126 It is therefore necessary to design a convergence test that 127 considers all of these components, not just one or a few of these 128 components. The additional benefit of designing a test for all 129 components is that it enables black-box testing in which knowledge 130 of the routers' internal implementations is not required. It is 131 then possible to make valid use of the convergence benchmarking 132 metrics when comparing routers from different vendors. 134 4. Network Events that Cause Convergence 135 There are different types of network events that can cause IGP 136 convergence. These network events are administrative link 137 removal, unplanned link failure, line card failure, and route 138 changes such as withdrawal, flap, next-hop change, and cost change. 139 When benchmarking a router it is important to measure the 140 convergence time for local and remote occurrence of these network 141 events. The convergence time measured will vary whether the network 142 event occurred locally or remotely due to varying combinations of 143 factors listed in the previous sections. This behavior makes it 144 possible to design purely black-box tests that isolate 145 measurements for each of the components of convergence 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 observable 150 event having direct impact on customers' application performance. 151 For this reason it is important to develop a standard router 152 benchmarking methodology and terminology that is a Direct Measure 153 of Quality (DMOQ) for measuring IGP convergence. Such a 154 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 the 176 FIB so that the time it takes for the router to converge an entire 177 route table can be benchmarked. 179 6. Security Considerations 181 Documents of this type do not directly effect the security of 182 the Internet or of corporate networks as long as benchmarking 183 is not performed on devices or systems connected to operating 184 networks. 186 7. Acknowledgements 187 Thanks to Curtis Villamizar for sharing so much of his 188 knowledge and experience through the years. Also, special 189 thanks to the many Network Engineers and Network Architects 190 at the Service Providers who are always eager to discuss 191 Route Convergence. 193 8. References 194 [1] Poretsky, S., "Benchmarking Methodology for IGP Data Plane 195 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-meth-04, 196 work in progress, October 2004. 198 [2] Poretsky, S., "Benchmarking Terminology for IGP Data Plane 199 Route Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-04, 200 work in progress, October 2004. 202 [3] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual 203 Environments", RFC 1195, December 1990. 205 [4] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998. 207 [5] Villamizar, C., "Convergence and Restoration Techniques for 208 ISP Interior Routing", NANOG 25, October 2002. 210 IGP Data Plane Route Convergence 212 [6] Katz, D., "Why are we Scared of SPF? IGP Scaling and 213 Stability", NANOG 25, October 2002. 215 [7] Filsfils, C., "Deploying Tight-SLA Services on an Internet 216 Backbone: ISIS Fast Convergence and Differentiated Services 217 Design (tutorial)", NANOG 25, October 2002. 219 [8] Alaettinoglu, C. and Casner, S., "ISIS Routing on the Qwest 220 Backbone: a Recipe for Subsecond ISIS Convergence", NANOG 24, 221 October 2002. 223 [9] Alaettinoglu, C., Jacobson, V., and Yu, H., "Towards 224 Millisecond IGP Convergence", NANOG 20, October 2000. 226 9. Author's Address 228 Scott Poretsky 229 Quarry Technologies 230 8 New England Executive Park 231 Burlington, MA 01803 232 USA 234 Phone: + 1 781 395 5090 235 EMail: sporetsky@quarrytech.com 237 Intellectual Property Statement 239 The IETF takes no position regarding the validity or scope of any Intel- 240 lectual Property Rights or other rights that might be claimed to pertain 241 to the implementation or use of the technology described in this docu- 242 ment or the extent to which any license under such rights might or might 243 not be available; nor does it represent that it has made any independent 244 effort to identify any such rights. Information on the procedures with 245 respect to rights in RFC documents can be found in BCP 78 and BCP 79. 247 Copies of IPR disclosures made to the IETF Secretariat and any 248 assurances of licenses to be made available, or the result of an attempt 249 made to obtain a general license or permission for the use of such 250 proprietary rights by implementers or users of this specification can be 251 obtained from the IETF on-line IPR repository at 252 http://www.ietf.org/ipr. 254 The IETF invites any interested party to bring to its attention any 255 copyrights, patents or patent applications, or other proprietary rights 256 that may cover technology that may be required to implement this stan- 257 dard. Please address the information to the IETF at ietf-ipr@ietf.org. 259 Disclaimer of Warranty 261 This document and the information contained herein are provided on an 262 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 263 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 264 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 265 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMA- 266 TION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 267 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 269 Copyright Statement 271 Copyright (C) The Internet Society (2004). This document is subject to 272 the rights, licenses and restrictions contained in BCP 78, and except as 273 set forth therein, the authors retain all their rights.