idnits 2.17.1 draft-ietf-bmwg-fib-meth-02.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 223. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 201. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 217. ** 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. 2 IPR Disclosure Acknowledgement. ** 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 5 longer pages, the longest (page 1) being 73 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 5. 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.) ** There are 70 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 116 instances of too long lines in the document, the longest one being 4 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 89: '... this SHOULD be done using routing protocols, e.g., OSPF [OSPF]. RIB and...' RFC 2119 keyword, line 90: '... FIB contents MAY be determined ...' RFC 2119 keyword, line 92: '...is determination SHOULD be made using ...' RFC 2119 keyword, line 104: '...e and the entry SHOULD be removed fro...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 14 has weird spacing: '...or will be...' == Line 15 has weird spacing: '...d, and any ...' == Line 18 has weird spacing: '...ormance with ...' == Line 26 has weird spacing: '...eted by other...' == Line 27 has weird spacing: '...me. It is in...' == (65 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.) -- The document date (October 2004) is 7123 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: 'FIB-TERM' is mentioned on line 163, but not defined == Missing Reference: 'METHOD' is mentioned on line 165, but not defined == Missing Reference: 'MIB-BGP' is mentioned on line 127, but not defined == Missing Reference: 'MIB-OSPF' is mentioned on line 170, but not defined == Missing Reference: 'IDR' is mentioned on line 171, but not defined == Missing Reference: 'BGP-FLAP' is mentioned on line 173, but not defined Summary: 12 errors (**), 0 flaws (~~), 16 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT J. Dunn 3 Benchmarking Methodology Working Group C. Martin 4 Expires: May 2005 SI International 5 October 2004 7 Methodology for Forwarding Information Base (FIB) based Router Performance 9 draft-ietf-bmwg-fib-meth-02.txt 11 Status of this Memo 13 "By submitting this Internet-Draft, I certify that any applicable patent 14 or other IPR claims of which I am aware have been disclosed, or will be 15 disclosed, and any of which I become aware will be disclosed, in 16 accordance with RFC 3668." 18 This document is an Internet-Draft and is in full conformance with all 19 provisions of Section 10 of RFC2026 [IPROC]. 21 Internet-Drafts are working documents of the Internet Engineering Task 22 Force (IETF), its areas, and its working groups. Note that other groups 23 may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference material 28 or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 The forwarding performance of an IP router is highly dependent on the 39 information in its forwarding information base. This document describes 40 the methodology to be used to determine the IP packet forwarding 41 performance of an IP router as a function of the routers ability to 42 properly form and optimize its forwarding information base. 44 1. Introduction 46 This document covers the measurement of the IP packet forwarding 47 performance of IP routers on the basis of the routers ability to 48 properly form and optimize its forwarding information base (FIB). [FIB- 49 TERM] describes the terminology associated with this document. 51 This version of the document describes a more general approach to the 52 determination of router performance than previous versions. As a 53 result, it is the intent of the authors that this document serves as a 54 catalyst for further discussions concerning the approach outline in this 56 draft-ietf-bmwg-fib-meth-02.txt October 2004 58 draft. The purpose of this document is to describe a methodology for 59 measuring the impact of FIB generation from a given routing information 60 base (RIB) on the forwarding performance of a router. The objective is 61 to determine whether a router can maintain performance levels as the RIB 62 grows in size and complexity. 64 This document utilizes the methodology described in [METHOD] for 65 measuring the FIB-dependent throughput, FIB-dependent latency and FIB- 66 dependent frame loss rate of IP packets as they traverse the router 67 under test. The forwarding performance of a router should be observed 68 under different RIB sizes and compositions. 70 2. Terms Of Reference 72 This document utilizes the methodologies for packet throughput, latency 73 and loss measurements described in [METHOD]. 75 Definitions unique to this test methodology are covered in [FIB-TERM]. 77 The application of methodologies described in this document is not 78 limited to IP forwarding; however, it is beyond the scope of this 79 document to explicitly describe their application. In this document, use 80 of the term IP is protocol version independent. Traffic, RIB and FIB 81 may be IPv4, IPv6 or both. 83 3. Overview 85 The methodology described in this document is based on the precept that 86 the FIB is formed from information in the RIB and, possibly, other 87 configured variables. The methodology is independent of the particulars 88 associated with populating the RIB or setting these variables; however, 89 this SHOULD be done using routing protocols, e.g., OSPF [OSPF]. RIB and 90 FIB contents MAY be determined either through observing traffic 91 forwarding or management information base (MIB) queries. For 92 completeness, this determination SHOULD be made using both. Generation 93 of the FIB from the RIB based on three major components: 95 - Interface Identifier - Route Optimization - Routing Policies 97 The following three sub-sections describe these components and their 98 effect on FIB generation. 100 3.1 Interface Identifier 102 The interface identifier entry in the FIB establishes the physical path 103 for datagram forwarding. If the interface not active or down, the path 104 is no longer available and the entry SHOULD be removed from the FIB. 105 Descriptions of interface identifiers are contained in [MIB-BGP] and 106 [MIB-OSPF]. 3.2 Route Optimization 108 Route optimization seeks to minimize the overall effort on the part of 110 draft-ietf-bmwg-fib-meth-02.txt October 2004 112 the router to forward datagrams. Optimization has three basic 113 components: 115 - Route Aggregation - Route Flap Damping - Route Metrics 117 Route aggregation seeks to minimize the number of entries in the FIB 118 corresponding to a set of reachable address prefixes. These prefixes 119 could be contiguous or overlapping. Methods for route aggregation are 120 described in [IDR]. 122 Route flap damping seeks to minimize unnecessary re-generation of the 123 FIB based on unstable routing information. Methods for route flap 124 damping are described in [BGP-FLAP]. 126 Route metrics assign a relative weight or merit to a particular routed 127 path. Descriptions of these metrics are found in [MIB-BGP] and [MIB- 128 OSPF]. 130 3.3 Routing Policies 132 Routing policies are administrative restrictions or requirements on the 133 FIB. The take two major forms: 135 - Access Control Lists - Route Filters 137 Access control lists can be used to explicitly allow or deny access to 138 physical interfaces of network prefixes. This can be done either on the 139 basis of individual protocol addresses or entire prefixes. 141 Route filters are a set of protocol addresses or prefixes against which 142 a given route will be matched. The resulting action of a match will 143 depend on the use of the route filter. 145 4.0 Methodology 147 The methodologies for determining the effects of the three components of 148 FIB generation are still under investigation. The authors look to the 149 BMWG for guidance, suggestions and constructive input. 151 draft-ietf-bmwg-fib-meth-02.txt October 2004 153 5. Security Considerations 155 As this document is solely for the purpose of providing performance 156 methodologies and describes neither a protocol nor a protocol's 157 implementation; therefore, there are no security considerations 158 associated with this document. 160 6. Informative References 162 [IPROC] Bradner, S., "The Internet Standards Process -- Revision 3", 163 BCP 9, RFC 2026, October 1996. [FIB-TERM] Trotter, G., " Terminology 164 for Forwarding Information Base (FIB) based Router Performance", RFC 165 3222, December, 2001. [METHOD] Bradner, S., McQuaid, J., "Benchmarking 166 Methodology for Network Interconnect Devices", RFC 2544, March 1999 167 [OSPF] Moy, J, "OSPF Version 2," RFC 2328, April 1998. [MIB-BGP] 168 Willis, S., Burrus, J., Chu, J. "Definitions of Managed Objects for the 169 Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2," RFC 170 1657, July 1994. [MIB-OSPF] Baker, F., Colton, R., "OSPF Version 2 171 Management Information Base," RFC 1850, November 1995. [IDR] Chen, E., 172 Stewart, J., "A Framework for Inter-Domain Route Aggregation," RFC 2519, 173 February 1999. [BGP-FLAP] Villamizar, C., Chandra, R., Govindan, R., 174 "BGP Route Flap Damping," RFC 2439, November 1998. 176 7. Acknowledgements 178 The current authors would like to acknowledge Guy Trotter of Agilent 179 Technologies for his work on the first edition of this draft. His work 180 has spurred the current authors to consider a broader set of performance 181 criteria for FIB generation. 183 8. Author's Addresses 185 Jeffrey Dunn SI International 12012 Sunset Hills Road Suite 800 Reston, 186 VA 20190-5869 USA Ph: +1 703 234 6959 e-mail: jeffrey.dunn@si-intl.com 188 Cynthia Martin SI International 12012 Sunset Hills Road Suite 800 189 Reston, VA 20190-5869 USA Ph: +1 703 234 6962 e-mail: Cynthia.martin@si- 190 intl.com 192 9.0 Intellectual Property Considerations 194 The IETF takes no position regarding the validity or scope of any 195 Intellectual Property Rights or other rights that might be claimed to 196 pertain to the implementation or use of the technology described in this 197 document or the extent to which any license under such rights might or 198 might not be available; nor does it represent that it has made any 199 independent effort to identify any such rights. Information on the 200 procedures with respect to rights in RFC documents can be found in BCP 201 78 and BCP 79. 203 Copies of IPR disclosures made to the IETF Secretariat and any 204 assurances of licenses to be made available, or the result of an attempt 205 made to obtain a general license or permission for the use of such 207 draft-ietf-bmwg-fib-meth-02.txt October 2004 209 proprietary rights by implementers or users of this specification 210 can be obtained from the IETF on-line IPR repository at 211 http://www.ietf.org/ipr. 213 The IETF invites any interested party to bring to its attention any 214 copyrights, patents or patent applications, or other proprietary rights 215 that may cover technology that may be required to implement this 216 standard. Please address the information to the IETF at ietf- 217 ipr@ietf.org. 219 9.1 IPR Disclosure Acknowledgement 221 By submitting this Internet-Draft, I certify that any applicable patent 222 or other IPR claims of which I am aware have been disclosed, and any of 223 which I become aware will be disclosed, in accordance with RFC 3668. 225 10. Full Copyright Statement 227 Copyright (C) The Internet Society (2004). This document is subject to 228 the rights, licenses and restrictions contained in BCP 78, and except as 229 set forth therein, the authors retain all their rights. 231 This document and the information contained herein are provided on an 232 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 233 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 234 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 235 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE Of THE 236 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 237 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.