idnits 2.17.1 draft-ietf-bmwg-rtr-framework-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == 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 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 109 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 156 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 123: '... the MUST requirements for t...' RFC 2119 keyword, line 124: '...sfies all the MUST and all the ...' RFC 2119 keyword, line 126: '...atisfies all the MUST requirements but...' RFC 2119 keyword, line 127: '... SHOULD requirements for its pro...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 11 has weird spacing: '... This docum...' == Line 12 has weird spacing: '...-Drafts are ...' == Line 13 has weird spacing: '...cuments of th...' == Line 14 has weird spacing: '...tribute worki...' == Line 15 has weird spacing: '...cuments as In...' == (104 more instances...) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'IPv4-Router' is defined on line 308, but no explicit reference was found in the text Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. H. Dunn 2 INTERNET-DRAFT C. E. Martin 3 Expires: February, 2001 ANC, Inc. 5 July, 2000 6 Framework for Router Benchmarking 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also distribute working 15 documents as Internet-Drafts. Internet-Drafts are draft documents valid 16 for a maximum of six months and may be updated, replaced, or obsoleted 17 by other documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as "work in 19 progress." To view the entire list of current Internet-Drafts, please 20 check the "1id-abstracts.txt" listing contained in the Internet-Drafts 21 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 22 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 23 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (1999). All Rights Reserved. 35 Abstract 37 This memo discusses and proposes a framework for the development of IP 38 performance benchmarking methodologies in the case of systems under test 39 (SUT) running IETF routing protocols. The intent of this document is to 40 facilitate the use of existing metrics developed by the BMWG and other 41 working groups. This will be accomplished by specifying router 42 configuration and state parameters and characterizing their effect on IP 43 packet forwarding in terms of these existing metrics. The terms defined 44 in this memo will be used in addition to terms defined in RFCs 1242, 45 2285, and 2544 and 2761. This memo is a product of the Benchmarking 46 Methodology Working Group (BMWG) of the Internet Engineering Task Force 47 (IETF). 49 I. Background. 51 1. Introduction. 53 The purpose of this document is to define a general framework for 54 particular methodologies to be developed by the Benchmarking Methodology 55 Working Group (BMWG) of the Operational Requirements Area. This memo 56 extends existing work, specifically RFC 2330 "Framework for IP 57 Performance Metrics", May 1998. The goal of this effort is to produce a 58 set of metrics and methodologies, based on existing metrics, to 59 characterize the effects of a router's configuration and state on IP 60 packet forwarding performance as defined in RFC 2544 "Benchmarking 61 Methodology for Network Interconnect Devices". Metrics will be defined 62 in accordance with the framework specified in RFC 1242 "Benchmarking 63 Terminology for Network Interconnect Devices". Methodologies will be 64 defined in accordance with the framework specified in RFC 2544. This 65 effort will focus on the effects of the following configuration and 66 states parameter sets on IP packet forwarding performance: 68 1. Static configuration parameters, e.g., route cache vs. total 69 available memory size 71 2. Dynamic configuration parameters, e.g., BGP4 72 MinRouteAdvertisementInterval 74 3. Static states, e.g., response to BGP4 NLRI updates 76 4. Dynamics states, e.g., response to conflicting BGP4 NLRI updates 77 (route flapping) 79 Metrics will be defined which characterize both the impact on IP packet 80 forwarding performance and router response to route updates based on 81 these states. Packet forwarding performance assessment will be based on 82 metrics described in RFCs 1242, 2285 and 2761. The assessment of router 83 response will be based on the values of MIB objects described in RFC 84 1850 and the upcoming BGP MIB document. This document will reference 85 Internet vocabulary, clearly describing Internet components such as 86 routers, routing protocols, and router MIB element definitions. Any 87 additional router related vocabulary necessary to develop router metrics 88 will be defined in this document. Measurement uncertainties and errors 89 will be described, including how they relate to the analytical framework 90 shared by many aspects of the Internet engineering discipline. 92 2. Existing Definitions. 94 RFC 1242 "Benchmarking Terminology for Network Interconnect Devices" and 95 RFC 2330 "Framework for IP Performance Metrics" should be consulted 96 before attempting to make use of this document. RFC 2544 "Benchmarking 97 Methodology for Network Interconnect Devices" contains discussions of a 98 number of terms relevant to the benchmarking of switching devices and 99 should be consulted. RFC 2285 "Benchmarking Terminology for LAN 100 Switching Devices" contains a number of terms pertaining to traffic 101 distributions and datagram interarrival. RFC 2761 "Terminology for ATM 102 Benchmarking" contains a number terms pertaining to traffic management 103 [TM4.0, TM4.1]. RFC 1812 "Requirements for IP Version 4 Routers" 104 contains an excellent glossary with which it is assumed that the reader 105 is familiar. For the sake of clarity and continuity, this RFC adopts 106 the template for definitions set out in Section 2 of RFC 1242. 108 3. Requirements 110 In this document, the words that are used to define the significance of 111 each particular requirement are capitalized. These words are: * "MUST" 112 This word, or the words "REQUIRED" and "SHALL" mean that the item is an 113 absolute requirement of the specification. * "SHOULD" This word or the 114 adjective "RECOMMENDED" means that there may exist valid reasons in 115 particular circumstances to ignore this item, but the full implications 116 should be understood and the case carefully weighed before choosing a 117 different course. * "MAY" This word or the adjective "OPTIONAL" means 118 that this item is truly optional. One vendor may choose to include the 119 item because a particular marketplace requires it or because it enhances 120 the product, for example; another vendor may omit the same item. 122 An implementation is not compliant if it fails to satisfy one or more of 123 the MUST requirements for the protocols it implements. An 124 implementation that satisfies all the MUST and all the SHOULD 125 requirements for its protocols is said to be "unconditionally 126 compliant"; one that satisfies all the MUST requirements but not all the 127 SHOULD requirements for its protocols is said to be "conditionally 128 compliant". 130 4. Criteria for Router Metrics 132 RFC 2330 "Framework for IP Performance Metrics" contains a number of 133 relevant criteria for performance metrics. In addition, router 134 performance metrics should be independent of router architecture and 135 routing protocol. As with IP performance metrics, router metrics will 136 be dependent on the parameter sets mentioned in section I.1 of this 137 document. Since all metrics must produce reproducible and self- 138 consistent results, router metrics are only meaningful in the case where 139 these parameter sets are stable enough for measurements to be performed. 140 As a result, auxiliary observations may be required to determine whether 141 the router is in a stable state. 143 II. Definitions 145 The definitions presented in this section have been divided into two 146 groups. The first group is formal definitions, which are required in 147 the definitions of the performance metrics but are not themselves 148 strictly metrics. These definitions are subsumed from other work done 149 in other working groups both inside and outside the IETF. They are 150 provided as a courtesy to the reader. 151 1. Formal Definitions 153 1.1. Definition Format (from RFC 1242) 155 Term to be defined. 157 Definition: The specific definition for the term. 159 Discussion: A brief discussion of the term, its application and any 160 restrictions on measurement procedures. 162 Specification: The working group and document in which the terms are 163 specified and are listed in the references section. 165 1.2. Generic Definitions. 167 1.2.1. Forwarding Decision 169 Definition: The process by which a router determines, based on information 170 in the FIB, what the disposition of a packet will be. 172 Discussion: The forwarding decision is made by the router's forwarder and 173 is used by the forwarder to correctly forward the packet. 175 Specification: N/A 177 1.2.2. Routing Information Entry 179 Definition: A single entry in the FIB that provides all information 180 required for the forwarder to make a forwarding decision. 182 Discussion: A routing information entry may provide forwarding information 183 mapping a single network, a class of networks, a specific data link layer 184 type or other datagram attribute to a unique egress port on the router. 186 Specification: N/A 188 1.2.2. Router Port 190 Definition: A single point of datagram entry and exit, characterized by a 191 single data link layer connection to other network equipment, access speed 192 and, perhaps, access controls. 194 Discussion: A router port is the primary source of datagrams to the 195 forwarder and destination of datagrams from the forwarder. 197 Specification: N/A 199 1.3. Static Configuration Parameters. 201 Definition: Static Configuration Parameters are those attributes of a 202 router, which are not altered by information gathered during the operation 203 of a routing protocol. 205 1.3.1. Forwarding Information Base Cache 207 Definition: A dedicated portion of the FIB, which contains the most current 208 or most often accessed routing information. 210 Discussion: The cache provides a method for rapidly accessing routing 211 information without resorting to a full scale search of the FIB. 213 Specification: N/A 215 1.3.2. Forwarding Information Base Cache Size 216 Definition: The number of routing information entries allocated to the FIB 217 cache. 219 Discussion: The size of the cache allocation significantly effects router 220 performance. If the cache allocation is not large enough, a full scale 221 search of the FIB is required in order to make forwarding decisions. If 222 the cache allocation is a significant percentage of the FIB size, the cache 223 search differs very little from a full scale FIB search. 225 1.3.3. Forwarding Information Base Size 227 Definition: The maximum number of routing information entries the FIB can 228 contain. 230 Discussion: This parameter impacts the maximum number of reachable 231 networks supported by the router; however, the relationship between the two 232 parameter is not always linear. 234 Specification: N/A 236 1.4. Dynamic Configuration Parameters. 238 Definition: Dynamic Configuration Parameters are those attributes of a 239 router, which are altered by information gathered during the operation of a 240 routing protocol. 242 1.3.2. Number of Reachable Networks 244 Definition: The current number of networks that the routing information in 245 the FIB allows the router to reach. 247 Discussion: The number of reachable networks will depend on static 248 parameters, such as the maximum number of routing entries in the FIB, and 249 dynamic parmeters, such as whether the FIB accurately reflects the state of 250 the network and route aggregation. 252 Specification: N/A 254 3. Security Considerations. 256 As this document is solely for providing terminology and describes 257 neither a protocol nor an implementation, there are no security 258 considerations associated with this document. 260 4. Notices 262 Internet Engineering Task Force 264 The IETF takes no position regarding the validity or scope of any 265 intellectual property or other rights that might be claimed to pertain 266 to the implementation or use of the technology described in this 267 document or the extent to which any license under such rights might or 268 might not be available; neither does it represent that it has made any 269 effort to identify any such rights. Information on the IETFs procedures 270 with respect to rights in standards-track and standards-related 271 documentation can be found in BCP-11. Copies of claims of rights made 272 available for publication and any assurances of licenses to be made 273 available, or the result of an attempt made to obtain a general license 274 or permission for the use of such proprietary rights by implementors or 275 users of this specification can be obtained from the IETF Secretariat. 276 The IETF invites any interested party to bring to its attention any 277 copyrights, patents or patent applications, or other proprietary rights, 278 which may cover technology that may be required to practice this 279 standard. Please address the information to the IETF Executive 280 Director. 282 5. Disclaimer 284 Copyright (C) The Internet Society (1999). All Rights Reserved. 286 This document and translations of it may be copied and furnished to 287 others, and derivative works that comment on or otherwise explain it or 288 assist in its implementation may be prepared, copied, published and 289 distributed, in whole or in part, without restriction of any kind, 290 provided that the above copyright notice and this paragraph are included 291 on all such copies and derivative works. However, this document itself 292 may not be modified in any way, such as by removing the copyright notice 293 or references to the Internet Society or other Internet organizations, 294 except as needed for the purpose of developing Internet standards in 295 which case the procedures for copyrights defined in the Internet 296 Standards process must be followed, or as required to translate it into 297 languages other than English. The limited permissions granted above are 298 perpetual and will not be revoked by the Internet Society or its 299 successors or assigns. This document and the information contained 300 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 301 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 302 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 303 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 304 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 306 6. References 308 [IPv4-Router] Baker, F., "Requirements for IP Version 4 Routers", RFC 309 1812, June 1995 311 7. Editors Addresses 313 Jeffrey Dunn 314 Advanced Network Consultants, Inc. 315 4214 Crest Place, Ellicott City, MD 21043 USA 316 Phone: +1 (410) 750-1700, E-mail: Jeffrey.Dunn@worldnet.att.net 318 Cynthia Martin 319 Advanced Network Consultants, Inc. 320 4214 Crest Place, Ellicott City, MD 21043 USA 321 Phone: +1 (410) 750-1700, E-mail: Cynthia.E.Martin@worldnet.att.net