idnits 2.17.1 draft-mcpherson-bgp4-expereince-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: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-mcpherson-bgp4-experience-00', but the file name used is 'draft-mcpherson-bgp4-expereince-00' == No 'Intended status' indicated for this document; assuming Proposed Standard 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. ** 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 218: '...cates the use of OPTIONAL PARAMETER Ty...' RFC 2119 keyword, line 344: '...by a BGP speaker MUST NOT be sent to o...' RFC 2119 keyword, line 349: '...n implementation MUST provide a mechan...' RFC 2119 keyword, line 378: '... LOCAL_PREF MUST be sent to IBGP Pee...' RFC 2119 keyword, line 380: '...L_PREF Attribute MUST NOT be sent to E...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 457 has weird spacing: '...sistent peer ...' == 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 (April 2003) is 7680 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: 'RFC 1518' is mentioned on line 163, but not defined -- Looks like a reference, but probably isn't: '9' on line 164 == Missing Reference: 'BGP-MIB' is mentioned on line 240, but not defined == Missing Reference: 'RFC 1269' is mentioned on line 242, but not defined ** Obsolete undefined reference: RFC 1269 (Obsoleted by RFC 4273) == Missing Reference: 'BGP-IMPL' is mentioned on line 264, but not defined == Unused Reference: 'RFC 1264' is defined on line 613, but no explicit reference was found in the text == Unused Reference: 'RFC 1772' is defined on line 629, but no explicit reference was found in the text == Unused Reference: 'RFC 1773' is defined on line 633, but no explicit reference was found in the text == Unused Reference: 'RFC 3345' is defined on line 642, but no explicit reference was found in the text == Unused Reference: 'BGP4-IMPL' is defined on line 648, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1105 (Obsoleted by RFC 1163) -- Duplicate reference: RFC1105, mentioned in 'RFC 1163', was also mentioned in 'RFC 1105'. ** Obsolete normative reference: RFC 1105 (ref. 'RFC 1163') (Obsoleted by RFC 1163) ** Obsolete normative reference: RFC 1264 (Obsoleted by RFC 4794) -- Duplicate reference: RFC1105, mentioned in 'RFC 1267', was also mentioned in 'RFC 1163'. ** Obsolete normative reference: RFC 1105 (ref. 'RFC 1267') (Obsoleted by RFC 1163) ** Obsolete normative reference: RFC 1519 (Obsoleted by RFC 4632) ** Obsolete normative reference: RFC 1656 (Obsoleted by RFC 1773) ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) ** Downref: Normative reference to an Informational RFC: RFC 1773 ** Obsolete normative reference: RFC 2796 (Obsoleted by RFC 4456) ** Obsolete normative reference: RFC 3065 (Obsoleted by RFC 5065) ** Downref: Normative reference to an Informational RFC: RFC 3345 -- Possible downref: Non-RFC (?) normative reference: ref. 'BGP4-ANALYSIS' -- Possible downref: Non-RFC (?) normative reference: ref. 'BGP4-IMPL' -- Possible downref: Non-RFC (?) normative reference: ref. 'BGP4' Summary: 16 errors (**), 0 flaws (~~), 14 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Danny McPherson 2 draft-mcpherson-bgp4-experience-00.txt Keyur Patel 3 Category Informational 4 Expires: October 2003 April 2003 6 Experience with the BGP-4 Protocol 7 9 Status of this Document 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This document is a product of an individual. Comments are solicited 31 and should be addressed to the author(s). 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 The purpose of this memo is to document how the requirements for 40 advancing a routing protocol from Draft Standard to full Standard 41 have been satisfied by Border Gateway Protocol version 4 (BGP-4). 43 This report satisfies the requirement for "the second report", as 44 described in Section 6.0 of RFC 1264. In order to fulfill the 45 requirement, this report augments RFC 1773 and describes additional 46 knowledge and understanding gained in the time between when the 47 protocol was made a Draft Standard and when it was submitted for 48 Standard. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. BGP-4 Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. A Border Gateway Protocol . . . . . . . . . . . . . . . . . 4 55 2.2. BGP version 2 . . . . . . . . . . . . . . . . . . . . . . . 5 56 2.3. BGP version 3 . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.4. BGP version 4 . . . . . . . . . . . . . . . . . . . . . . . 6 58 3. Management Information Base (MIB). . . . . . . . . . . . . . . 7 59 4. Implementations. . . . . . . . . . . . . . . . . . . . . . . . 7 60 5. Operational Experience . . . . . . . . . . . . . . . . . . . . 8 61 6. Metrics. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 6.1. MULTI_EXIT_DISC (MED) . . . . . . . . . . . . . . . . . . . 9 63 6.1.1. Sending MEDs to BGP Peers. . . . . . . . . . . . . . . . 10 64 6.1.2. MED of Zero Versus No MED. . . . . . . . . . . . . . . . 10 65 6.1.3. MEDs and Temporal Route Selection. . . . . . . . . . . . 10 66 7. LOCAL_PREF . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 8. Internal BGP In Large Autonomous Systems . . . . . . . . . . . 11 68 9. Internet Dynamics. . . . . . . . . . . . . . . . . . . . . . . 12 69 10. BGP Routing Information Bases (RIBs). . . . . . . . . . . . . 12 70 11. Update Packing. . . . . . . . . . . . . . . . . . . . . . . . 13 71 12. Limit Rate Updates. . . . . . . . . . . . . . . . . . . . . . 13 72 13. Ordering of Path Attributes . . . . . . . . . . . . . . . . . 14 73 14. AS_SET Sorting. . . . . . . . . . . . . . . . . . . . . . . . 14 74 15. Control over Version Negotiation. . . . . . . . . . . . . . . 14 75 16. Reciept of Non-Transitive Attributes from eBGP 76 Peer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 17. Security Considerations . . . . . . . . . . . . . . . . . . . 15 78 17.1. TCP MD5 Signature Option . . . . . . . . . . . . . . . . . 15 79 17.2. BGP Over IPSEC . . . . . . . . . . . . . . . . . . . . . . 15 80 17.3. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . . 16 81 17.4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 16 82 18. References. . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 19. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 18 84 20. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 18 86 1. Introduction 88 The purpose of this memo is to document how the requirements for 89 advancing a routing protocol from Draft Standard to full Standard 90 have been satisfied by Border Gateway Protocol version 4 (BGP-4). 92 This report satisfies the requirement for "the second report", as 93 described in Section 6.0 of RFC 1264. In order to fulfill the 94 requirement, this report augments RFC 1773 and describes additional 95 knowledge and understanding gained in the time between when the 96 protocol was made a Draft Standard and when it was submitted for 97 Standard. 99 2. BGP-4 Overview 101 BGP is an inter-autonomous system routing protocol designed for 102 TCP/IP internets. The primary function of BGP is to exchange network 103 reachability information with other BGP systems. This information is 104 sufficient to construct a graph of loop-free AS connectivity and some 105 policy decisions at the AS level may be enforced. 107 The initial version of the BGP protocol was published in RFC 1105. 108 Since then BGP Versions 2, 3, and 4 have been developed and are 109 specified in [RFC 1163], [RFC 1267], and [RFC 1771], respectively. 110 Changes since BGP-4 went to Draft Standard [RFC 1771] are listed in 111 Appendix N of [BGP4]. 113 2.1. A Border Gateway Protocol 115 BGP [RFC 1105] 117 Appendix D of [BGP4] Comparison with 1105: 119 o Changes to FSM to accommdate BSD 4.3 TCP UI. 120 o Notion of Up/Down/Horizontal relations have been removed. 121 o Message format changes: 122 - Hold Timer removed from BGP Header and added to OPEN Message 123 - Version field removed from BGP Header and added to OPEN Message 124 - Link Type field removed from OPEN Message 125 - OPEN CONFIRM message deprecated and replaced with implicit 126 confirmation provided by KEEPALIVE message. 128 - UPDATE Message format changed. New fields were added to 129 support multiple path attributes. 130 - The Marker field was expanded and its role broadened to 131 support authentication 133 2.2. BGP version 2 135 BGPv2 [RFC 1163] 137 Appendix C of [BGP4] Comparison with RFC 1163 139 o BGP Identifier introduced to deal with collision detection. 140 o Removed restriction that border router of NEXT_HOP path attribute 141 had to be part of same AS. 142 o Optimized and simplified exchange of information about reachable 143 routes. 145 BGP version 2 removed from the protocol the concept of "up", "down", 146 and "horizontal" relations between autonomous systems that were 147 present in version 1. BGP version 2 introduced the concept of path 148 attributes. In addition, BGP version 2 clarified parts of the 149 protocol that were "under-specified". 151 2.3. BGP version 3 153 BGPv3 [RFC 1267] 155 Appendix B of [BGP4] Comparison with RFC 1267: 157 o Set of destination via single IP prefix. Concept of 158 network classes, or subnetting is foreign to BGP-4. 159 To accommodate these capabilities BGP-4 changes the 160 semantics and encoding associated with the AS_PATH attribute. 161 New text has been added to define semantics associated with 162 IP Prefixes. These abilities allow BGP to support the 163 proposed supernetting scheme [RFC 1518] (BGP4 Draft reference 164 to [9] needs to be fixed). 165 o LOCAL_PREF intrduced to facilitate route selection procedures. 166 o INTER_AS_METRIC renamed to MULTI_EXIT_DISC 167 o ATOMIC_AGGREGATE introduced to ensure that certain aggregates 168 are not deaggregated. 169 o Introduced AGGREGATOR. 171 o Holdtimer neogtiation per-connection for symmetry. Lower value 172 used. Hold Times of zero now supported. 174 BGP version 3 lifted some of the restrictions on the use of the 175 NEXT_HOP path attribute, and added the BGP Identifier field to the 176 BGP OPEN message. It also clarifies the procedure for distributing 177 BGP routes between the BGP speakers within an autonomous system. 179 2.4. BGP version 4 181 BGP v4 [RFC 1771] [BGP4] 183 Appendix A of [BGP4] Comparison with RFC 1771: 185 o Changes to reflect use of the TCP MD5 Signature Option, 186 Route Reflectors, AS Confederations for BGP and BGP Route 187 Refresh. 188 o Clarified use of BGP Identifier in AGGREGATOR Attribute 189 o Procedures for imposing upper bound of prefixes a speaker will 190 accept from a peer. 191 o Ability to include more than one instance of it's own AS in the 192 AS_PATH attribute for the purpose of inter-AS traffic engineering. 193 o Clarified various types of NEXT_HOPS 194 o Claried use of ATOMIC_AGGREGATE attribute 195 o Discussed relationship be BGP NEXT_HOP attribute and immediate 196 next hop. 197 o Clarified tie-breaking procedures 198 o Clarified route advertisement frequency text. 199 o Deprecated Optional Parameter Type 1 (Authentication Information) 200 o UPDATE Message Error subcode 7 (AS Routing Loop) deprecated. 201 o Use of Marker field for authentication has been deprecated. 203 BGP version 4 redefines the (previously defined class-based) network 204 layer reachability portion of the updates to specify prefixes of 205 arbitrary length in order to represent multiple classful networks in 206 a single entry as discussed in [RFC 1519]. BGP version 4 has also 207 modified the AS_PATH attribute so that sets of autonomous systems, as 208 well as individual ASs may be described. BGP version 4 has 209 redescribed the INTER-AS METRIC attribute as the MULTI_EXIT_DISC and 210 added new LOCAL_PREF and AGGREGATOR attributes. 212 BGP version 4 defines procedures for imposing an upper bound on the 213 number of prefixes that a BGP speaker may accept from its peer. BGP 214 version 4 has modifed the AS_PATH attribute to have an ability to 215 include more than one instance of its own AS for the purpose of 216 inter-AS traffic engineering. 218 BGP version 4 deprecates the use of OPTIONAL PARAMETER Type 1 219 (Authentication Information). BGP version 4 also depecates the use of 220 UPDATE MESSAGE Error subcode 7 (AS Routing Loop). 222 BGP version 4 provides clarifications on use of BGP Identifier in the 223 AGGREGATOR attribute and use of the ATOMIC_AGGREGATOR attribute. BGP 224 version 4 also provides clarifications on various types of NEXT_HOPs, 225 BGP tie-breaking procedures and frequency of route announcements in 226 BGP. 228 Possible applications of BGP in the Internet are documented in [RFC 229 1772]. 231 The BGP protocol was developed by the IDR Working Group of the 232 Internet Engineering Task Force. This Working Group had a mailing 233 list, idr@merit.edu, where discussions of protocol features and 234 operation are held. The IDR Working Group meets regularly during the 235 Internet Engineering Task Force meetings. Reports of these meetings 236 are published in the IETF's Proceedings. 238 3. Management Information Base (MIB) 240 The BGP-4 Management Information Base (MIB) has been published [BGP- 241 MIB]. The MIB was updated from previous versions documented in [RFC 242 1657] and [RFC 1269], respectively. 244 Apart from a few system variables, the BGP MIB is broken into two 245 tables: the BGP Peer Table and the BGP Received Path Attribute Table. 247 The Peer Table reflects information about BGP peer connections, such 248 as their state and current activity. The Received Path Attribute 249 Table contains all attributes received from all peers before local 250 routing policy has been applied. The actual attributes used in 251 determining a route are a subset of the received attribute table. 253 4. Implementations 255 There are numerous independent interoperable implementations of BGP 256 currently available. Although the previous version of this report 257 provided an overview of the implementations currently used in the 258 operational Internet, at this time it has been suggested that a 259 separate BGP Implementation Report [BGP-IMPL] be generated. 261 It should be noted that implementation experience with Cisco's BGP-4 262 implementation was documented as part of [RFC 1656]. 264 For all additional implementation information please reference [BGP- 265 IMPL]. 267 5. Operational Experience 269 This section discusses operational experience with BGP and BGP-4. 271 BGP has been used in the production environment since 1989, BGP-4 272 since 1993. Production use of BGP includes utilization of all 273 significant features of the protocol. The present production 274 environment, where BGP is used as the inter-autonomous system routing 275 protocol, is highly heterogeneous. In terms of the link bandwidth it 276 varies from 64 Kbs to 10 Gbs. In terms of the actual routes that run 277 BGP it ranges from a relatively slow performance PC/RT to a very high 278 performance RISC-based CPUs, and includes both the special purpose 279 routers and the general purpose workstations running various UNIX 280 derivatives and other operating systems. 282 In terms of the actual topologies it varies from a very sparse to 283 quite dense. Full-mesh IBGP topologies have been largely mitigated 284 by BGP Route Reflection [RFC 2796], Autonomous System Confederations 285 for BGP [RFC 3065], or some combination of the two, in many networks. 287 At the time of this writing BGP-4 is used as an inter-autonomous 288 system routing protocol between ALL Internet-attached autonomous 289 systems, with nearly 15k active autonomous systems in the global 290 Internet routing table. 292 BGP is used both for the exchange of routing information between a 293 transit and a stub autonomous system, and for the exchange of routing 294 information between multiple transit autonomous systems. There is no 295 protocol distinction between sites historically considered 296 "backbones" versus "regional" networks. 298 Within transit networks, BGP is typically used as the exclusive 299 carrier of exterior routing information. 301 The full set of exterior routes that is carried by BGP is well over 302 115,000 aggregate entries, representing several times that number of 303 connected networks. The number of active paths in some service 304 provider core routers has exceeded 2 million. Native AS_PATH lengths 305 are as long as 10 for some routes, and "padded" path lengths of 25 or 306 more ASs exist. 308 6. Metrics 310 This section discusses different metrics used within the BGP 311 protocol. BGP has a seperate metric parameter for IBGP and EBGP. This 312 allows policy based metrics to overwrite the distance based metrics; 313 allowing each autonomous systems to define their independent policies 314 in Intra-AS as well as Inter-AS. BGP Multi Exit Discriminator (MED) 315 is used as a metric by EBGP peers while BGP Local Preference is used 316 by IBGP peers. 318 6.1. MULTI_EXIT_DISC (MED) 320 BGP version 4 re-defined the old INTER-AS metric as a MULTI_EXIT_ 321 DISC (MED). This value may be used in the tie-breaking process when 322 selecting a preferred path to a given address space, and provides BGP 323 speakers with the capability to convey to a peer AS the optimal entry 324 point into the local AS. 326 Although the MED was meant to only be used when comparing paths 327 received from different external peers in the same AS, many 328 implementations provide the capability to compare MEDs between 329 different ASs as well. 331 The MED was purposely designed to be a "weak" metric that would only 332 be used late in the best-path decision process. The BGP working 333 group was concerned that any metric specified by a remote operator 334 would only affect routing in a local AS if no other preference was 335 specified. A paramount goal of the design of the MED was ensure that 336 peers could not "shed" or "absorb" traffic for networks that they 337 advertise. 339 6.1.1. Sending MEDs to BGP Peers 341 [BGP4] allows MEDs received from any EBGP peers by a BGP speaker to 342 be passed to its IBGP peers. Although advertising MEDs to IBGP peers 343 is not a required behavior, it is a common default. MEDs received 344 from EBGP peers by a BGP speaker MUST NOT be sent to other EBGP 345 peers. 347 6.1.2. MED of Zero Versus No MED 349 An implementation MUST provide a mechanism that allows for MED to be 350 removed. Previously, implementations did not consider a missing MED 351 value to be the same as a MED of zero. No MED value should now be 352 equal to a value of zero. 354 6.1.3. MEDs and Temporal Route Selection 356 Some implementations have hooks to apply temporal behavior in MED- 357 based best path selection. That is, all other things being equal up 358 to MED consideration, preference would be applied to the "oldest" 359 path, without preferring the lower MED value. The reasoning for this 360 is that "older" paths are presumably more stable, and thus more 361 preferable. However, temporal behavior in route slection results in 362 non-deterministic behavior, and as such, is often undesirable. 364 7. LOCAL_PREF 366 The LOCAL_PREF attribute was added so a network operator could easily 367 configure a policy that overrode the standard best path determination 368 mechanism without independently configuring local preference policy 369 on each router. 371 One shortcoming in the BGP-4 specification was a suggestion for a 372 default value of LOCAL-PREF to be assumed if none was provided. 373 Defaults of 0 or the maximum value each have range limitations, so a 374 common default would aid in the interoperation of multi-vendor 375 routers in the same AS (since LOCAL_PREF is a local administration 376 knob, there is no interoperability drawback across AS boundaries). 378 LOCAL_PREF MUST be sent to IBGP Peers. 380 LOCAL_PREF Attribute MUST NOT be sent to EBGP Peers. (Handling 381 errors) Spec says Notification with Error Code UPDATE Message Error. 383 The common default value for LOCAL_PREF is 100. No default value is 384 defined. 386 Another area where more exploration is required is a method whereby 387 an originating AS may influence the best path selection process. For 388 example, a dual-connected site may select one AS as a primary transit 389 service provider and have one as a backup. 391 /---- transit B ----/\n 392 end-customer transit A---- 393 /---- transit C ----/ 395 In a topology where the two transit service providers connect to a 396 third provider, the real decision is performed by the third provider 397 and there is no mechanism for indicating a preference should the 398 third provider wish to respect that preference. 400 A general purpose suggestion that has been brought up is the 401 possibility of carrying an optional vector corresponding to the AS- 402 PATH where each transit AS may indicate a preference value for a 403 given route. Cooperating ASs may then chose traffic based upon 404 comparison of "interesting" portions of this vector according to 405 routing policy. 407 While protecting a given ASs routing policy is of paramount concern, 408 avoiding extensive hand configuration of routing policies needs to be 409 examined more carefully in future BGP-like protocols. 411 8. Internal BGP In Large Autonomous Systems 413 While not strictly a protocol issue, one other concern has been 414 raised by network operators who need to maintain autonomous systems 415 with a large number of peers. Each speaker peering with an external 416 router is responsible for propagating reachability and path 417 information to all other transit and border routers within that AS. 418 This is typically done by establishing internal BGP connections to 419 all transit and border routers in the local AS. 421 In a large AS, this leads to a full mesh of TCP connections (n * 422 (n-1)) and some method of configuring and maintaining those 423 connections. BGP does not specify how this information is to be 424 propagated, so alternatives, such as injecting BGP attribute 425 information into the local IGP have been suggested. Also, there is 426 effort underway to develop internal BGP "route reflectors" or a 427 reliable multicast transport of IBGP information which would reduce 428 configuration, memory and CPU requirements of conveying information 429 to all other internal BGP peers. 431 BGP "Route Reflector" extensions has been defined in RFC 1966 to 432 alleviate the the need for "full mesh" IBGP. 434 9. Internet Dynamics 436 As discussed in [BGP4-ANALYSIS], the driving force in CPU and 437 bandwidth utilization is the dynamic nature of routing in the 438 Internet. As the net has grown, the number of route changes per 439 second has increased. 441 We automatically get some level of damping when more specific NLRI is 442 aggregated into larger blocks, however this isn't sufficient. In 443 Appendix F of [BGP4] are descriptions of damping techniques that 444 should be applied to advertisements. In future specifications of 445 BGP-like protocols, damping methods should be considered for 446 mandatory inclusion in compliant implementations. 448 Route changes are announced using BGP UPDATE messages. The greatest 449 overhead in advertising UPDATE messages happens whenever route 450 changes to be announced are inefficiently packed.Announcing routing 451 changes sharing common attributes in a single BGP UPDATE message 452 [13.1] also helps save considerable bandwidth. 454 Persistent BGP errors may cause BGP peers to flap persistently if 455 peer dampening is not implemented. This would result in significant 456 CPU utilization. Implementors may find it useful to implement peer 457 dampening to avoid such persistent peer flapping [BGP4]. 459 10. BGP Routing Information Bases (RIBs) 461 [BGP4] states "Any local policy which results in routes being added 462 to an Adj-RIB-Out without also being added to the local BGP speaker's 463 forwarding table, is outside the scope of this document". 465 However, several well-known implementations do not confirm that Loc- 466 RIB entries were used to populate the forwarding table before 467 installing them in the Adj-RIB-Out. The most common occurrence of 468 this is when routes for a given prefix are presented by more than one 469 protocol and the preferences for the BGP learned route is lower than 470 that of another protocol. As such, the route learned via the other 471 protocol is used to populate the forwarding table. 473 It may be desirable for an implementation to provide a knob that 474 permits advertisement of "inactive" BGP routes. 476 It may be also desirable for an implementation to provide a knob that 477 allows a BGP speaker to advertise BGP routes that were not selected 478 by descision process. 480 11. Update Packing 482 The BGP4 protocol permits advertisement of multiple prefixes with a 483 common set of path attributes to be advertised in a single update 484 message. When possible, Update packing is recommended as it reduces 485 overhead in receivers in terms of: 487 o System overhead due to receipt of fewer Update messages. 488 o Overhead for scanning the routing table for BGP Updates to 489 its peers and other routing protocols (and the 490 redistribution of this information as well). 492 The BGP protocol suggests that withdrawal information should be 493 packed in the begining of Update message along with information about 494 more or less specific reachable routes in a single UPDATE message. 495 This would help alleviate excessive route flapping in BGP. 497 12. Limit Rate Updates 499 The BGP protocol defines different mechanisms to rate limit the 500 Updates. The BGP protocol defines MinRouteAdvertisementInterval 501 parameter that determines the minimum time that must be elsape 502 between the advertisement of routes to a particular destination from 503 a single BGP speaker. This value is set on a per BGP peer basis. 505 13. Ordering of Path Attributes 507 The BGP protocol suggests that BGP speakers sending multiple prefixes 508 per an UPDATE message should sort and order path attributes according 509 to Type Codes. This would help their peers to quickly identify sets 510 of attributes from different update messages which are semantically 511 different. 513 Implementers may find it useful to order path attributes according to 514 Type Code so that sets of attributes with identical semantics can be 515 more quickly identified. 517 14. AS_SET Sorting 519 AS_SETs are commonly used in BGP route aggregation. They reduce the 520 size of AS_PATH information by listing AS numbers only once 521 regardless of any number of times it might appear in process of 522 aggregation. AS_SETs are usually sorted in increasing order to 523 facilitate efficient lookups of AS numbers within them. This 524 optimization is entirely optional. 526 15. Control over Version Negotiation 528 Because pre-BGP-4 route aggregation can't be supported by earlier 529 version of BGP, an implementation that supports versions in addition 530 to BGP-4 should provide the version support on a per-peer basis. 532 16. Reciept of Non-Transitive Attributes from eBGP Peer 534 E.g., LOCAL_PREF, RR or confed, etc.. 536 NEEDS MORE WORK 538 17. Security Considerations 540 BGP provides flexible and extendible mechanism for authentication and 541 security. The mechanism allows to support schemes with various 542 degree of complexity. All BGP sessions are authenticated based on 543 the BGP Identifier of a peer. In addition, all BGP sessions are 544 authenticated based on the autonomous system number advertised by a 545 peer. 547 Since BGP runs over TCP and IP, BGP's authentication scheme may be 548 augmented by any authentication or security mechanism provided by 549 either TCP or IP. 551 17.1. TCP MD5 Signature Option 553 RFC 2385 defines a way in which the TCP MD5 signature option can be 554 used to valid information transmitted between two peers. This method 555 prevents any third party from injecting information (e.g., a TCP RST) 556 into the datastream, or modifying the routing information carried 557 between two BGP peers. RFC ???? provides suggestions for choosing 558 passwords to be used with MD5. 560 TCP MD5 is not ubiquitously deployed at the moment, especially in 561 inter- domain scenarios, largely because of key distribution issues. 562 Most key distribution mechanisms are considered to be too "heavy" at 563 this point. 565 17.2. BGP Over IPSEC 567 BGP can run over IPSEC, either in a tunnel, or in transport mode, 568 where the TCP portion of the IP packet is encrypted. This not only 569 prevents random insertion of information into the data stream between 570 two BGP peers, it also prevents an attacker from learning the data 571 which is being exchanged between the peers. 573 IPSEC does, however, offer several options for exchanging session 574 keys, which may be useful on inter-domain configurations. These 575 options are being explored in many deployments, although no 576 definitive solution has been reach on the issue of key exchange for 577 BGP in IPSEC. 579 It should be noted that since BGP runs over TCP and IP, BGP is 580 vulnerable to the same denial of service or authentication attacks 581 that are present in any other TCP based protocol. 583 17.3. Miscellaneous 585 Another issue any routing protocol faces is providing evidence of the 586 validity and authority of the routing information carried within the 587 routing system. This is currently the focus of several efforts at 588 the moment, including efforts to define the threats which can be used 589 against this routing information in BGP [draft-murphy, attack tree], 590 and efforts at providing a means to provide validation and authority 591 for routing information carried within BGP [SBGP, soBGP and possibly 592 ATT stuff]. 594 Should information as it relates to IRR derived prefix-based filters 595 be included here? 597 BTSH & RP Queuing...? 599 17.4. Acknowledgements 601 We would like to thank Paul Traina and Yakov Rekhter for authoring 602 previous versions of this document. We would also like to 603 acknowledge Russ White for valuable feedback on this document. 605 18. References 607 [RFC 1105] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol 608 BGP", RFC 1105, June 1989. 610 [RFC 1163] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol 611 BGP", RFC 1105, June 1990. 613 [RFC 1264] Hinden, R., "Internet Routing Protocol Standardization 614 Criteria", RFC 1264, October 1991. 616 [RFC 1267] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol 3 617 (BGP-3)", RFC 1105, October 1991. 619 [RFC 1519] Fuller, V., Li. T., Yu J., and K. Varadhan, "Classless 620 Inter-Domain Routing (CIDR): an Address Assignment and 621 Aggregation Strategy", RFC 1519, September 1993. 623 [RFC 1656] Traina, P., "BGP-4 Protocol Document Roadmap and 624 Implementation Experience", RFC 1656, July 1994. 626 [RFC 1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 627 (BGP-4)", RFC 1771, March 1995. 629 [RFC 1772] Rekhter, Y., and P. Gross, Editors, "Application of the 630 Border Gateway Protocol in the Internet", RFC 1772, March 631 1995. 633 [RFC 1773] Traina, P., "Experience with the BGP-4 protocol", RFC 634 1773, March 1995. 636 [RFC 2796] Bates, T., Chandra, R., and Chen, E, "Route Reflection - 637 An Alternative to Full Mesh IBGP", RFC 2796, April 2000. 639 [RFC 3065] Traina, P., McPherson, D., and Scudder, J, "Autonomous 640 System Confederations for BGP", RFC 3065, Febuary 2001. 642 [RFC 3345] McPherson, D., Gill, V., Walton, D., and Retana, A, "BGP 643 Persistent Route Oscillation Condition", RFC 3345, 644 August 2002. 646 [BGP4-ANALYSIS] Work in Progress. 648 [BGP4-IMPL] Work in Progress. 650 [BGP4] Rekhter, Y., T. Li., and Hares. S, Editors, "A Border 651 Gateway Protocol 4 (BGP-4)", BGP Draft, Work in Progress. 653 19. Authors' Addresses 655 Danny McPherson 656 Arbor Networks 657 Email: danny@arbor.net 659 Keyur Patel 660 Cisco Systems 661 Email: keyupate@cisco.com 663 20. Full Copyright Statement 665 Copyright (C) The Internet Society (2003). All Rights Reserved. 667 This document and translations of it may be copied and furnished to 668 others, and derivative works that comment on or otherwise explain it 669 or assist in its implementation may be prepared, copied, published 670 and distributed, in whole or in part, without restriction of any 671 kind, provided that the above copyright notice and this paragraph are 672 included on all such copies and derivative works. However, this 673 document itself may not be modified in any way, such as by removing 674 the copyright notice or references to the Internet Society or other 675 Internet organizations, except as needed for the purpose of 676 developing Internet standards in which case the procedures for 677 copyrights defined in the Internet Standards process must be 678 followed, or as required to translate it into languages other than 679 English. 681 The limited permissions granted above are perpetual and will not be 682 revoked by the Internet Society or its successors or assigns. 684 This document and the information contained herein is provided on an 685 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 686 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 687 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 688 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 689 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.