idnits 2.17.1 draft-ietf-bmwg-fib-meth-03.txt: -(251): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(254): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(281): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(289): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 17. -- Found old boilerplate from RFC 3978, Section 5.3 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 520. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 494. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 501. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 510. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 526), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** 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? -- The document has an RFC 3978 Section 5.3 Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. ** 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. ** 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: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-', but the file name used is 'draft-ietf-bmwg-fib-meth-03' == There are 5 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 63 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 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: ' 4. 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 160 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 12 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 45 has weird spacing: '...pendent on...' == Line 47 has weird spacing: '...y to be used ...' == Line 48 has weird spacing: '...ormance of a...' == Line 104 has weird spacing: '...ocument cover...' == Line 105 has weird spacing: '...ormance of I...' == (14 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (February 14, 2005) is 7004 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) == Unused Reference: 'IPROC' is defined on line 436, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3222 (ref. 'FIB-TERM') ** Downref: Normative reference to an Informational RFC: RFC 2544 (ref. 'METHOD') ** Obsolete normative reference: RFC 1657 (ref. 'MIB-BGP') (Obsoleted by RFC 4273) ** Obsolete normative reference: RFC 1850 (ref. 'MIB-OSPF') (Obsoleted by RFC 4750) ** Downref: Normative reference to an Informational RFC: RFC 2519 (ref. 'IDR') -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO9646' ** Downref: Normative reference to an Informational RFC: RFC 1242 Summary: 17 errors (**), 1 flaw (~~), 15 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft 3 Benchmarking Working Group J. Dunn 4 C. Martin 5 SI International 6 Expires: August 2005 February 14, 2005 8 Methodology for Forwarding Information Base (FIB) based Router 9 Performance 10 draft- -ietf-bmwg-fib-meth-03.txt 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance with 17 RFC 3668. 19 This document may only be posted in an Internet-Draft. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on August 14, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). All Rights Reserved. 43 Abstract 45 The forwarding performance of an IP router is highly dependent on 46 the information in its forwarding information base. This document 47 describes the methodology to be used to determine the IP packet 48 forwarding performance of an IP router as a function of the routers 49 ability to properly form and optimize its forwarding information base. 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC-2119 Error! Reference 54 source not found.. 56 Table of Contents 58 Introduction......................................................3 59 Terms of Reference................................................3 60 1. Overview.......................................................4 61 1.1. Interface Identifier......................................4 62 1.2. Route Optimization........................................4 63 1.3. Routing Policies..........................................5 64 2. Base Methodology...............................................5 65 2.1. Verdict Definitions.......................................6 66 2.2. Basic Test Types..........................................6 67 2.2.1. Route Addition.......................................6 68 2.2.2. Route Deletion.......................................7 69 2.2.3. Route Addition.......................................7 70 2.3. Baseline Tests............................................7 71 3. Test Suite Definition..........................................8 72 3.1. Control Plane Test Group..................................8 73 3.1.1. Interface Identifier Test Group......................8 74 3.1.2. Route Optimization Test Group........................8 75 3.1.2.1. Route Aggregation Test Sub-Group................8 76 3.1.2.2. Route Flap Damping Test Sub-Group...............8 77 3.1.2.3. Route Metrics Test Sub-Group....................8 78 3.1.3. Routing Policies Test Group..........................9 79 3.1.3.1. Access Control Lists Test Sub-Group.............9 80 3.1.3.2. Route Filters Test Sub-Group....................9 81 3.1.3.3. Static Routes Test Sub-Group....................9 82 3.2. Data Plane Test Group....................................10 83 3.2.1. Interface Identifier Test Group.....................10 84 3.2.2. Route Optimization Test Sub-Group...................10 85 3.2.2.1. Route Aggregation Test Sub-Group...............10 86 3.2.2.2. Route Flap Damping Test Sub-Group..............10 87 3.2.2.3. Route Metrics Test Sub-Group...................10 88 3.2.3. Routing Policies Test Group.........................10 89 3.2.3.1. Access Control Lists Test Sub-Group............10 90 3.2.3.2. Route Filters Test Sub-Group...................11 91 3.2.3.3. Static Routes Test Sub-Group...................11 92 4. Security Considerations.......................................11 93 5. Acknowledgments...............................................11 94 6. References....................................................11 95 6.1. Normative References.....................................11 96 7. Author's Addresses............................................12 97 Intellectual Property Statement..................................12 98 Disclaimer of Validity...........................................13 99 Copyright Statement..............................................13 100 Acknowledgment...................................................13 102 Introduction 104 This document covers the measurement of the IP packet 105 forwarding performance of IP routers on the basis of the 106 routers ability to properly form and optimize its forwarding 107 information base (FIB). [FIB-TERM] describes the terminology 108 associated with this document. 110 This version of the document describes a more general approach to 111 the determination of router performance than previous versions. As 112 a result, it is the intent of the authors that this document serves 113 as a catalyst for further discussions concerning the approach outline 114 in this draft. The purpose of this document is to describe a 115 methodology for measuring the impact of FIB generation from a given 116 routing information base (RIB) on the forwarding performance of a 117 router. The objective is to determine whether a router can maintain 118 performance levels as the RIB grows in size and complexity. 120 This document utilizes the methodology described in 121 [METHOD] for measuring the FIB-dependent throughput, FIB-dependent 122 latency and FIB-dependent frame loss rate of IP packets as 123 they traverse the router under test. The forwarding performance of a 124 router should be observed under different RIB sizes and compositions. 126 Terms of Reference 128 This document utilizes the methodologies for packet throughput, 129 latency and loss measurements described in [METHOD]. 131 Definitions unique to this test methodology are covered in [FIB- 132 TERM]. 134 The application of methodologies described in this document 135 is not limited to IP forwarding; however, it is beyond the 136 scope of this document to explicitly describe their application. In 137 this document, use of the term IP is protocol version independent. 138 Traffic, RIB and FIB may be IPv4, IPv6 or both. 140 1. Overview 142 The methodology described in this document is based on the precept 143 that the FIB is formed from information in the RIB and, possibly, 144 other configured variables. The methodology is independent of the 145 particulars associated with populating the RIB or setting these 146 variables; however, this SHOULD be done using routing protocols, 147 e.g., OSPF [OSPF]. RIB and FIB contents MAY be determined either 148 through observing traffic forwarding or management information base 149 (MIB) queries. For completeness, this determination SHOULD be made 150 using both. Generation of the FIB from the RIB based on three major 151 components: 153 o Interface Identifier 155 o Route Optimization 157 o Routing Policies 159 The following three sub-sections describe these components and 160 their effect on FIB generation. 162 1.1. Interface Identifier 164 The interface identifier entry in the FIB establishes the physical 165 path for datagram forwarding. If the interface not active or down, 166 the path is no longer available and the entry SHOULD be removed from 167 the FIB. Descriptions of interface identifiers are contained in 168 [MIB-BGP] and [MIB-OSPF]. 170 1.2. Route Optimization 172 Route optimization seeks to minimize the overall effort on the 173 part of the router to forward datagrams. Optimization has 174 three basic components: 176 o Route Aggregation 178 o Route Flap Damping 180 o Route Metrics 182 Route aggregation seeks to minimize the number of entries in 183 the FIB corresponding to a set of reachable address prefixes. These 184 prefixes could be contiguous or overlapping. Methods for route 185 aggregation are described in [IDR]. 187 Route flap damping seeks to minimize unnecessary re-generation 188 of the FIB based on unstable routing information. Methods for 189 route flap damping are described in [BGP-FLAP]. 191 Route metrics assign a relative weight or merit to a particular 192 routed path. Descriptions of these metrics are found in [MIB-BGP] 193 and [MIB-OSPF]. 195 1.3. Routing Policies 197 Routing policies are administrative restrictions or requirements 198 on the FIB. The take three major forms: 200 o Access Control Lists 202 o Route Filters 204 o Static Routes 206 Access control lists can be used to explicitly allow or deny 207 access to physical interfaces of network prefixes. This can be done 208 either on the basis of individual protocol addresses or entire 209 prefixes. 211 Route filters are a set of protocol addresses or prefixes against 212 which a given route will be matched. The resulting action of a match 213 will depend on the use of the route filter; however, it is usually an 214 allow or deny action. 216 Static routes are lists of protocol addresses explicitly associated 217 with a given interface. All datagrams with protocol addresses in 218 these lists are automatically routed to the specified address. 220 2. Base Methodology 222 The test methodologies described in this document are grouped 223 according to a hierarchy based on the effects of routing updates. 224 This test hierarchy and nomenclature follow the ISO 9646 [ISO9646] 225 formalism. The basic test hierarchy is: 227 1. Control Plane Group 228 a. Interface Identifier Group 230 b. Route Optimization Group 232 c. Routing Policies Group 234 2. Data Plane Group 236 a. Interface Identifier Group 238 b. Route Optimization Group 240 c. Routing Policies Group 242 Each test group or case MUST contain a test purpose. Test cases MUST 243 specify the SUT state, series of stimuli to bring it to that state, 244 stimulating datagram and expected datagram. All required field in 245 all datagrams MUST be specified. Verdicts are PASS, FAIL and 246 INCONCLUSIVE. All verdicts MUST have the associated responses 247 explicitly specified. The entirety constitutes a test suite. 249 2.1. Verdict Definitions 251 o PASS � The required datagram was detected within the required time 252 period. 254 o FAIL � The required datagram was not detected within the required 255 time period. 257 o INCONCLUSIVE _ The SUT could not be brought into the specified 258 state. 260 2.2. Basic Test Types 262 This methodology employees three basic test types: 264 o Route Addition 266 o Route Deletion 268 o Route Change 270 2.2.1. Route Addition 272 A route addition test case involves advertising a route to the SIT 273 not contained in the RIB or FIB. The test case produces a PASS 274 verdict when the advertised route is reflected in the SUT�s 275 processing of data and control plane datagrams. 277 2.2.2. Route Deletion 279 A route addition test case involves ceasing to advertise a route to 280 the SIT contained in the RIB or FIB. The test case produces a PASS 281 verdict when the deleted route is reflected in the SUT�s processing 282 of data and control plane datagrams. 284 2.2.3. Route Addition 286 A route addition test case involves advertising a route to the SIT 287 contained in the RIB or FIB and associated with a different 288 interface. The test case produces a PASS verdict when the advertised 289 route is reflected in the SUT�s processing of data and control plane 290 datagrams. 292 2.3. Baseline Tests 294 Given a FIB in a steady state and populated to a specified percentage 295 of its maximum size, a measure of the maximum throughput [RFC 1242] 296 constitutes a baseline for all additional measurements. 298 3. Test Suite Definition 300 Test Suite Purpose: Determine the effect of route advertisements on 301 the data and control plane responses of the SUT. 303 3.1. Control Plane Test Group 305 Test Group Purpose: Determine whether the SUT responds to route 306 updates with the appropriate control plane messages. 308 3.1.1. Interface Identifier Test Group 310 Test Group Purpose: Determine whether the SUT responds to route 311 updates with the appropriate control plane messages to the 312 appropriate interface. 314 3.1.2. Route Optimization Test Group 316 Test Group Purpose: Determine whether the SUT responds to route 317 updates with the appropriate control plane messages indicating route 318 optimization. 320 3.1.2.1. Route Aggregation Test Sub-Group 322 Test Group Purpose: Determine whether the SUT responds to route 323 updates with the appropriate control plane messages indicating route 324 aggregation has been applied to FIB. 326 3.1.2.2. Route Flap Damping Test Sub-Group 328 Test Group Purpose: Determine whether the SUT responds to route 329 updates with the appropriate control plane messages indicating route 330 flap damping has been applied to FIB. 332 3.1.2.3. Route Metrics Test Sub-Group 334 Test Group Purpose: Determine whether the SUT responds to route 335 updates with the appropriate control plane messages indicating route 336 metrics have been applied to FIB. 338 3.1.3. Routing Policies Test Group 340 Test Group Purpose: Determine whether the SUT responds to route 341 updates with the appropriate control plane messages based on routing 342 policies. 344 3.1.3.1. Access Control Lists Test Sub-Group 346 Test Group Purpose: Determine whether the SUT responds to route 347 updates with the appropriate control plane messages indicating access 348 control lists have been applied to FIB. 350 3.1.3.2. Route Filters Test Sub-Group 352 Test Group Purpose: Determine whether the SUT responds to route 353 updates with the appropriate control plane messages indicating route 354 filters have been applied to FIB. 356 3.1.3.3. Static Routes Test Sub-Group 358 Test Group Purpose: Determine whether the SUT responds to route 359 updates with the appropriate control plane messages static routes 360 have been applied to FIB. 362 3.2. Data Plane Test Group 364 Test Group Purpose: Determine whether the SUT responds to route 365 updates by appropriately handling IP datagrams. 367 3.2.1. Interface Identifier Test Group 369 Test Group Purpose: Determine whether the SUT responds to route 370 updates by routing data to the appropriate interface. 372 3.2.2. Route Optimization Test Sub-Group 374 Test Group Purpose: Determine whether the SUT responds to route 375 updates by routing data to the appropriate interface after the 376 specified period of time. 378 3.2.2.1. Route Aggregation Test Sub-Group 380 Test Group Purpose: Determine whether the SUT responds to route 381 updates by routing data to the aggregated appropriate interface. 383 3.2.2.2. Route Flap Damping Test Sub-Group 385 Test Group Purpose: Determine whether the SUT responds to route 386 updates by routing data to the appropriate interface based on the 387 damping period. 389 3.2.2.3. Route Metrics Test Sub-Group 391 Test Group Purpose: Determine whether the SUT responds to route 392 updates by routing data to the appropriate interface. 394 3.2.3. Routing Policies Test Group 396 Test Group Purpose: Determine whether the SUT responds to route 397 updates by routing data to the appropriate interface based on routing 398 policies. 400 3.2.3.1. Access Control Lists Test Sub-Group 402 Test Group Purpose: Determine whether the SUT responds to route 403 updates by routing data to the appropriate interface based on routing 404 policies. 406 3.2.3.2. Route Filters Test Sub-Group 408 Test Group Purpose: Determine whether the SUT responds to route 409 updates by routing data to the appropriate interface based on routing 410 policies. 412 3.2.3.3. Static Routes Test Sub-Group 414 Test Group Purpose: Determine whether the SUT responds to route 415 updates by routing data to the appropriate interface based on routing 416 policies. 418 4. Security Considerations 420 As this document is solely for the purpose of providing 421 performance methodologies and describes neither a protocol nor 422 a protocol's implementation; therefore, there are no 423 security considerations associated with this document. 425 5. Acknowledgments 427 The current authors would like to acknowledge Guy Trotter of 428 Agilent Technologies for his work on the first edition of this draft. 429 His work has spurred the current authors to consider a broader set of 430 performance criteria for FIB generation. 432 6. References 434 6.1. Normative References 436 [IPROC] Bradner, S., "The Internet Standards Process -- Revision 3", 437 BCP 9, RFC 2026, October 1996. 439 [FIB-TERM] Trotter, G., "Terminology for Forwarding Information Base 440 (FIB) based Router Performance", RFC 3222, December, 2001. 442 [METHOD] Bradner, S., McQuaid, J., "Benchmarking Methodology for 443 Network Interconnect Devices", RFC 2544, March 1999 445 [OSPF] Moy, J, "OSPF Version 2," RFC 2328, April 1998. 447 [MIB-BGP] Willis, S., Burrus, J., Chu, J., "Definitions of Managed 448 Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) 449 using SMIv2," RFC 1657, July 1994. 451 [MIB-OSPF] Baker, F.,Colton, R., "OSPF Version 2 Management 452 Information Base," RFC 1850, November 1995. 454 [IDR] Chen, E., Stewart, J., "A Framework for Inter-Domain Route 455 Aggregation," RFC 2519, February 1999. 457 [BGP-FLAP] Villamizar, C., Chandra, R., Govindan, R., "BGP Route 458 Flap Damping," RFC 2439, November 1998. 460 [ISO9646] Conformance testing methodology and framework, ISO, 1994. 462 [RFC 1242] Bradner, S., "Benchmarking Terminology for Network 463 Interconnection Devices," RFC 1242, July 1991. 465 7. Author's Addresses 467 Jeffrey Dunn 468 SI International 469 12012 Sunset Hills Road 470 Suite 800 471 Reston, VA 20190-5869 USA 473 Phone: _1 703 234 6959 474 Email: Jeffrey.Dunn@si-intl.com 476 Cynthia Martin 477 SI International 478 12012 Sunset Hills Road 479 Suite 800 480 Reston, VA 20190-5869 USA 482 Phone: +1 703 234 6962 483 Email: Cynthia.Martin@si-intl.com 485 Intellectual Property Statement 487 The IETF takes no position regarding the validity or scope of any 488 Intellectual Property Rights or other rights that might be claimed to 489 pertain to the implementation or use of the technology described in 490 this document or the extent to which any license under such rights 491 might or might not be available; nor does it represent that it has 492 made any independent effort to identify any such rights. Information 493 on the procedures with respect to rights in RFC documents can be 494 found in BCP 78 and BCP 79. 496 Copies of IPR disclosures made to the IETF Secretariat and any 497 assurances of licenses to be made available, or the result of an 498 attempt made to obtain a general license or permission for the use of 499 such proprietary rights by implementers or users of this 500 specification can be obtained from the IETF on-line IPR repository at 501 http://www.ietf.org/ipr. 503 The IETF invites any interested party to bring to its attention any 504 copyrights, patents or patent applications, or other proprietary 505 rights that may cover technology that may be required to implement 506 this standard. Please address the information to the IETF at 507 ietf-ipr@ietf.org. By submitting this Internet-Draft, I certify that 508 any applicable patent or other IPR claims of which I am aware have 509 been disclosed, and any of which I become aware will be disclosed, in 510 accordance with RFC 3668. 512 Disclaimer of Validity 514 This document and the information contained herein are provided on an 515 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 516 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 517 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 518 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 519 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 520 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 522 Copyright Statement 524 Copyright (C) The Internet Society (2004). This document is subject 525 to the rights, licenses and restrictions contained in BCP 78, and 526 except as set forth therein, the authors retain all their rights. 528 Acknowledgment 530 Funding for the RFC Editor function is currently provided by the 531 Internet Society.