idnits 2.17.1 draft-ietf-idr-bgp4-experience-protocol-02.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: ---------------------------------------------------------------------------- == 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 266: '...by a BGP speaker MUST NOT be sent to o...' RFC 2119 keyword, line 276: '...n implementation MUST provide a mechan...' RFC 2119 keyword, line 309: '... The LOCAL_PREF MUST be sent to IBGP ...' RFC 2119 keyword, line 310: '... MUST NOT be sent to EBGP Peers. Al...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 396 has weird spacing: '...sistent peer ...' -- 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 (September 2003) is 7528 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 2119' is mentioned on line 35, but not defined == Missing Reference: 'BGP-MIB' is mentioned on line 132, but not defined == Missing Reference: 'BGP-IMPL' is mentioned on line 156, but not defined == Missing Reference: 'RFC 1965' is mentioned on line 180, but not defined ** Obsolete undefined reference: RFC 1965 (Obsoleted by RFC 3065) == Unused Reference: 'RFC 1264' is defined on line 664, but no explicit reference was found in the text == Unused Reference: 'RFC 1519' is defined on line 674, but no explicit reference was found in the text == Unused Reference: 'RFC 1657' is defined on line 681, but no explicit reference was found in the text == Unused Reference: 'RFC 1772' is defined on line 689, but no explicit reference was found in the text == Unused Reference: 'RFC 1773' is defined on line 693, but no explicit reference was found in the text == Unused Reference: 'RFC 3345' is defined on line 714, but no explicit reference was found in the text == Unused Reference: 'BGP4-IMPL' is defined on line 720, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** 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 1269 (Obsoleted by RFC 4273) ** Obsolete normative reference: RFC 1519 (Obsoleted by RFC 4632) ** Obsolete normative reference: RFC 1656 (Obsoleted by RFC 1773) ** Obsolete normative reference: RFC 1657 (Obsoleted by RFC 4273) ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) ** Downref: Normative reference to an Informational RFC: RFC 1773 ** Obsolete normative reference: RFC 1966 (Obsoleted by RFC 4456) ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'SBGP' Summary: 21 errors (**), 0 flaws (~~), 14 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Danny McPherson 2 Arbor Networks 3 Keyur Patel 4 Cisco Systems 5 Category Informational 6 Expires: March 2004 September 2003 8 Experience with the BGP-4 Protocol 9 11 Status of this Document 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119 [RFC 2119]. 36 This document is a product of an individual. Comments are solicited 37 and should be addressed to the author(s). 39 Copyright Notice 41 Copyright (C) The Internet Society (2003). All Rights Reserved. 43 Abstract 45 The purpose of this memo is to document how the requirements for 46 advancing a routing protocol from Draft Standard to full Standard 47 have been satisfied by Border Gateway Protocol version 4 (BGP-4). 49 This report satisfies the requirement for "the second report", as 50 described in Section 6.0 of RFC 1264. In order to fulfill the 51 requirement, this report augments RFC 1773 and describes additional 52 knowledge and understanding gained in the time between when the 53 protocol was made a Draft Standard and when it was submitted for 54 Standard. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. BGP-4 Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. A Border Gateway Protocol . . . . . . . . . . . . . . . . . 4 61 3. Management Information Base (MIB). . . . . . . . . . . . . . . 5 62 4. Implementations. . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Operational Experience . . . . . . . . . . . . . . . . . . . . 5 64 6. TCP Awareness. . . . . . . . . . . . . . . . . . . . . . . . . 6 65 7. Metrics. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 7.1. MULTI_EXIT_DISC (MED) . . . . . . . . . . . . . . . . . . . 7 67 7.1.1. Sending MEDs to BGP Peers. . . . . . . . . . . . . . . . 8 68 7.1.2. MED of Zero Versus No MED. . . . . . . . . . . . . . . . 8 69 7.1.3. MEDs and Temporal Route Selection. . . . . . . . . . . . 8 70 8. LOCAL_PREF . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 9. Internal BGP In Large Autonomous Systems . . . . . . . . . . . 10 72 10. Internet Dynamics . . . . . . . . . . . . . . . . . . . . . . 10 73 11. BGP Routing Information Bases (RIBs). . . . . . . . . . . . . 11 74 12. Update Packing. . . . . . . . . . . . . . . . . . . . . . . . 11 75 13. Limit Rate Updates. . . . . . . . . . . . . . . . . . . . . . 12 76 14. Ordering of Path Attributes . . . . . . . . . . . . . . . . . 13 77 15. AS_SET Sorting. . . . . . . . . . . . . . . . . . . . . . . . 13 78 16. Control over Version Negotiation. . . . . . . . . . . . . . . 13 79 17. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 17.1. TCP MD5 Signature Option . . . . . . . . . . . . . . . . . 14 81 17.2. BGP Over IPSEC . . . . . . . . . . . . . . . . . . . . . . 14 82 17.3. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . . 14 83 17.4. PTOMAINE and GROW. . . . . . . . . . . . . . . . . . . . . 15 84 17.5. Internet Routing Registries (IRRs) . . . . . . . . . . . . 15 85 17.6. Regional Internet Registries (RIRs) and IRRs, 86 A Bit of History . . . . . . . . . . . . . . . . . . . . . . . . 16 87 17.7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 17 88 18. References. . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 19. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 19 90 20. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 20 92 1. Introduction 94 The purpose of this memo is to document how the requirements for 95 advancing a routing protocol from Draft Standard to full Standard 96 have been satisfied by Border Gateway Protocol version 4 (BGP-4). 98 This report satisfies the requirement for "the second report", as 99 described in Section 6.0 of RFC 1264. In order to fulfill the 100 requirement, this report augments RFC 1773 and describes additional 101 knowledge and understanding gained in the time between when the 102 protocol was made a Draft Standard and when it was submitted for 103 Standard. 105 2. BGP-4 Overview 107 BGP is an inter-autonomous system routing protocol designed for 108 TCP/IP internets. The primary function of a BGP speaking system is 109 to exchange network reachability information with other BGP systems. 110 This network reachability information includes information on the 111 list of Autonomous Systems (ASs) that reachability information 112 traverses. This information is sufficient to construct a graph of AS 113 connectivity for this reachability from which routing loops may be 114 pruned and some policy decisions at the AS level may be enforced. 116 The initial version of the BGP protocol was published in RFC 1105. 117 Since then BGP Versions 2, 3, and 4 have been developed and are 118 specified in [RFC 1163], [RFC 1267], and [RFC 1771], respectively. 119 Changes since BGP-4 went to Draft Standard [RFC 1771] are listed in 120 Appendix N of [BGP4]. 122 2.1. A Border Gateway Protocol 124 The Initial Version of BGP [RFC 1105]. BGP version 2 is defined in 125 [RFC 1163]. BGP version 3 is defined in [RFC 1267]. BGP version 4 126 is defined in [RFC 1771] and [BGP4]. Appendices A, B, C, and D of 127 [BGP4] provide summaries of the changes between each iteration of the 128 BGP specification. 130 3. Management Information Base (MIB) 132 The BGP-4 Management Information Base (MIB) has been published [BGP- 133 MIB]. The MIB was updated from previous versions documented in [RFC 134 1657] and [RFC 1269], respectively. 136 Apart from a few system variables, the BGP MIB is broken into two 137 tables: the BGP Peer Table and the BGP Received Path Attribute Table. 139 The Peer Table reflects information about BGP peer connections, such 140 as their state and current activity. The Received Path Attribute 141 Table contains all attributes received from all peers before local 142 routing policy has been applied. The actual attributes used in 143 determining a route are a subset of the received attribute table. 145 4. Implementations 147 There are numerous independent interoperable implementations of BGP 148 currently available. Although the previous version of this report 149 provided an overview of the implementations currently used in the 150 operational Internet, at this time it has been suggested that a 151 separate BGP Implementation Report [BGP-IMPL] be generated. 153 It should be noted that implementation experience with Cisco's BGP-4 154 implementation was documented as part of [RFC 1656]. 156 For all additional implementation information please reference [BGP- 157 IMPL]. 159 5. Operational Experience 161 This section discusses operational experience with BGP and BGP-4. 163 BGP has been used in the production environment since 1989, BGP-4 164 since 1993. Production use of BGP includes utilization of all 165 significant features of the protocol. The present production 166 environment, where BGP is used as the inter-autonomous system routing 167 protocol, is highly heterogeneous. In terms of the link bandwidth it 168 varies from 56 Kbps to 10 Gbps. In terms of the actual routers that 169 run BGP, it ranges from a relatively slow performance general purpose 170 CPUs to very high performance RISC network processors, and includes 171 both special purpose routers and the general purpose workstations 172 running various UNIX derivatives and other operating systems. 174 In terms of the actual topologies it varies from very sparse to quite 175 dense. The requirement for full-mesh IBGP topologies has been 176 largely remedied by BGP Route Reflection, Autonomous System 177 Confederations for BGP, and perhaps some mix of the two. BGP Route 178 Reflection was initially defined in [RFC 1966] and subsequently 179 updated in [RFC 2796]. Autonomous System Confederations for BGP were 180 initially defined in [RFC 1965] and subsequently updated in [RFC 181 3065]. 183 At the time of this writing BGP-4 is used as an inter-autonomous 184 system routing protocol between all Internet-attached autonomous 185 systems, with nearly 15k active autonomous systems in the global 186 Internet routing table. 188 BGP is used both for the exchange of routing information between a 189 transit and a stub autonomous system, and for the exchange of routing 190 information between multiple transit autonomous systems. There is no 191 protocol distinction between sites historically considered 192 "backbones" versus "regional" or "edge" networks. 194 The full set of exterior routes that is carried by BGP is well over 195 120,000 aggregate entries, representing several times that number of 196 connected networks. The number of active paths in some service 197 provider core routers exceeds 2.5 million. Native AS_PATH lengths 198 are as long as 10 for some routes, and "padded" path lengths of 25 or 199 more ASs exist. 201 6. TCP Awareness 203 BGP employs TCP [RFC 793] as it's Transport Layer protocol. As such, 204 all characteristics inherent to TCP are inherited by BGP. 206 For example, due to TCP's behavior, bandwidth capabilities may not be 207 realized due to TCP's slow start algorithms, and slow-start restarts 208 of connections, etc.. 210 7. Metrics 212 This section discusses different metrics used within the BGP 213 protocol. BGP has a separate metric parameter for IBGP and EBGP. This 214 allows policy based metrics to overwrite the distance based metrics; 215 allowing each autonomous systems to define their independent policies 216 in Intra-AS as well as Inter-AS. BGP Multi Exit Discriminator (MED) 217 is used as a metric by EBGP peers while BGP Local Preference is used 218 by IBGP peers. 220 7.1. MULTI_EXIT_DISC (MED) 222 BGP version 4 re-defined the old INTER-AS metric as a MULTI_EXIT_ 223 DISC (MED). This value may be used in the tie-breaking process when 224 selecting a preferred path to a given address space, and provides BGP 225 speakers with the capability to convey to a peer AS the optimal entry 226 point into the local AS. 228 Although the MED was meant to only be used when comparing paths 229 received from different external peers in the same AS, many 230 implementations provide the capability to compare MEDs between 231 different ASs as well. 233 Though this may seem a fine idea for some configurations, care must 234 be taken when comparing MEDs between different autonomous systems. 235 BGP speakers often derive MED values by obtaining the IGP metric 236 associated with reaching a given BGP NEXT_HOP within the local AS. 237 This allows MEDs to reasonably reflect IGP topologies when 238 advertising routes to peers. While this is fine when comparing MEDs 239 between multiple paths learned from a single AS, it can result in 240 potentially bad decisions when comparing MEDs between differt 241 automomous systems. This is most typically the case when the 242 autonomous systems use different mechanisms to derive IGP metrics, 243 BGP MEDs, or perhaps even use different IGP procotols with vastly 244 contrasting metric spaces. 246 Another MED deployment consideration involves the impact of 247 aggregation of BGP routing information on MEDs. Aggregates are often 248 generated from multiple locations in an AS in order to accommodate 249 stability, redundancy and other network design goals. When MEDs are 250 derived from IGP metrics associated with said aggregates the MED 251 value advertised to peers can result in very suboptimal routing. 253 The MED was purposely designed to be a "weak" metric that would only 254 be used late in the best-path decision process. The BGP working 255 group was concerned that any metric specified by a remote operator 256 would only affect routing in a local AS if no other preference was 257 specified. A paramount goal of the design of the MED was to ensure 258 that peers could not "shed" or "absorb" traffic for networks that 259 they advertise. 261 7.1.1. Sending MEDs to BGP Peers 263 [BGP4] allows MEDs received from any EBGP peers by a BGP speaker to 264 be passed to its IBGP peers. Although advertising MEDs to IBGP peers 265 is not a required behavior, it is a common default. MEDs received 266 from EBGP peers by a BGP speaker MUST NOT be sent to other EBGP 267 peers. 269 Note that many implementations provide a mechanism to derive MED 270 values from IGP metrics in order to allow BGP MED information to 271 reflect the IGP topologies and metrics of the network when 272 propagating information to adjacent autonomous systems. 274 7.1.2. MED of Zero Versus No MED 276 An implementation MUST provide a mechanism that allows for MED to be 277 removed. Previously, implementations did not consider a missing MED 278 value to be the same as a MED of zero. No MED value should now be 279 equal to a value of zero. 281 Note that many implementations provide an mechanism to explicitly 282 define a missing MED value as "worst" or less preferable than zero or 283 larger values. 285 7.1.3. MEDs and Temporal Route Selection 287 Some implementations have hooks to apply temporal behavior in MED- 288 based best path selection. That is, all other things being equal up 289 to MED consideration, preference would be applied to the "oldest" 290 path, without preferring the lower MED value. The reasoning for this 291 is that "older" paths are presumably more stable, and thus more 292 preferable. However, temporal behavior in route selection results in 293 non-deterministic behavior, and as such, is often undesirable. 295 8. LOCAL_PREF 297 The LOCAL_PREF attribute was added so a network operator could easily 298 configure a policy that overrode the standard best path determination 299 mechanism without independently configuring local preference policy 300 on each router. 302 One shortcoming in the BGP-4 specification was a suggestion for a 303 default value of LOCAL-PREF to be assumed if none was provided. 304 Defaults of 0 or the maximum value each have range limitations, so a 305 common default would aid in the interoperation of multi-vendor 306 routers in the same AS (since LOCAL_PREF is a local administration 307 knob, there is no interoperability drawback across AS boundaries). 309 The LOCAL_PREF MUST be sent to IBGP Peers. The LOCAL_PREF Attribute 310 MUST NOT be sent to EBGP Peers. Although no default value for 311 LOCAL_PREF is defined, the common default value is 100. 313 Another area where more exploration is required is a method whereby 314 an originating AS may influence the best path selection process. For 315 example, a dual-connected site may select one AS as a primary transit 316 service provider and have one as a backup. 318 /---- transit B ----\ 319 end-customer transit A---- 320 /---- transit C ----\ 322 In a topology where the two transit service providers connect to a 323 third provider, the real decision is performed by the third provider 324 and there is no mechanism for indicating a preference should the 325 third provider wish to respect that preference. 327 A general purpose suggestion that has been brought up is the 328 possibility of carrying an optional vector corresponding to the AS- 329 PATH where each transit AS may indicate a preference value for a 330 given route. Cooperating ASs may then chose traffic based upon 331 comparison of "interesting" portions of this vector according to 332 routing policy. 334 While protecting a given ASs routing policy is of paramount concern, 335 avoiding extensive hand configuration of routing policies needs to be 336 examined more carefully in future BGP-like protocols. 338 9. Internal BGP In Large Autonomous Systems 340 While not strictly a protocol issue, one other concern has been 341 raised by network operators who need to maintain autonomous systems 342 with a large number of peers. Each speaker peering with an external 343 router is responsible for propagating reachability and path 344 information to all other transit and border routers within that AS. 345 This is typically done by establishing internal BGP connections to 346 all transit and border routers in the local AS. 348 Note that the number of BGP peers that can be fully meshed depends on 349 a number of factors, to include number of prefixes in the routing 350 system, stability of the system, and perhaps most importantly, 351 implementation ifficiency. As a result, although it's difficult to 352 define "a large number of peers", there is always some practical 353 limit. 355 In a large AS, this leads to a full mesh of TCP connections (n * 356 (n-1)) and some method of configuring and maintaining those 357 connections. BGP does not specify how this information is to be 358 propagated, so alternatives, such as injecting BGP routing 359 information into the local IGP have been attempted, though it turned 360 out to be a non-practical alternative (to say the least). 362 Several alternatives to a full mesh IBGP have been defined, to 363 include BGP Route Reflection [RFC 2796] and AS Confederations for BGP 364 [RFC 3065], in order to alleviate the the need for "full mesh" IBGP. 366 10. Internet Dynamics 368 As discussed in [BGP4-ANALYSIS], the driving force in CPU and 369 bandwidth utilization is the dynamic nature of routing in the 370 Internet. As the net has grown, the number of route changes per 371 second has increased. 373 We automatically get some level of damping when more specific NLRI is 374 aggregated into larger blocks, however, this isn't sufficient. In 375 Appendix F of [BGP4] are descriptions of damping techniques that 376 should be applied to advertisements. In future specifications of 377 BGP-like protocols, damping methods should be considered for 378 mandatory inclusion in compliant implementations. 380 BGP Route Flap Damping is defined in [RFC 2439]. BGP Route Flap 381 Damping defines a mechanism to help reduce the amount of routing 382 information passed between BGP peers, and subsequently, the load on 383 these peers, without adversely affecting route convergence time for 384 relatively stable routes. 386 Route changes are announced using BGP UPDATE messages. The greatest 387 overhead in advertising UPDATE messages happens whenever route 388 changes to be announced are inefficiently packed. As previously 389 discussed, announcing routing changes sharing common attributes in a 390 single BGP UPDATE message helps save considerable bandwidth and lower 391 processing overhead. 393 Persistent BGP errors may cause BGP peers to flap persistently if 394 peer dampening is not implemented. This would result in significant 395 CPU utilization. Implementors may find it useful to implement peer 396 dampening to avoid such persistent peer flapping [BGP4]. 398 11. BGP Routing Information Bases (RIBs) 400 [BGP4] states "Any local policy which results in routes being added 401 to an Adj-RIB-Out without also being added to the local BGP speaker's 402 forwarding table, is outside the scope of this document". 404 However, several well-known implementations do not confirm that Loc- 405 RIB entries were used to populate the forwarding table before 406 installing them in the Adj-RIB-Out. The most common occurrence of 407 this is when routes for a given prefix are presented by more than one 408 protocol and the preferences for the BGP learned route is lower than 409 that of another protocol. As such, the route learned via the other 410 protocol is used to populate the forwarding table. 412 It may be desirable for an implementation to provide a knob that 413 permits advertisement of "inactive" BGP routes. 415 It may be also desirable for an implementation to provide a knob that 416 allows a BGP speaker to advertise BGP routes that were not selected 417 by decision process. 419 12. Update Packing 421 Multiple unfeasible routes can be advertised in a single BGP Update 422 message. In addition, one or more feasible routes can be advertised 423 in a single Update message so long as all prefixes share a common 424 attribute set. 426 The BGP4 protocol permits advertisement of multiple prefixes with a 427 common set of path attributes to be advertised in a single update 428 message, this is commonly referred to as "update packing". When 429 possible, update packing is recommended as it provides a mechanism 430 for more efficient behavior in a number of areas, to include: 432 o Reduction in system overhead due to generation or receipt of 433 fewer Update messages. 435 o Reduction in network overhead as a result of less packets 436 and lower bandwidth consumption. 438 o Allows you to process path attributes and look for matching 439 sets in your AS_PATH database (if you have one) less 440 frequently. Consistent ordering of the path attributes 441 allows for ease of matching in the database as you don't have 442 different representations of the same data. 444 The BGP protocol suggests that withdrawal information should be 445 packed in the begining of Update message, followed by information 446 about more or less specific reachable routes in a single UPDATE 447 message. This helps alleviate excessive route flapping in BGP. 449 13. Limit Rate Updates 451 The BGP protocol defines different mechanisms to rate limit Update 452 advertisement. The BGP protocol defines MinRouteAdvertisementInterval 453 parameter that determines the minimum time that must be elapse 454 between the advertisement of routes to a particular destination from 455 a single BGP speaker. This value is set on a per BGP peer basis. 457 Due to the fact that BGP relies on TCP as the Transport protocol, TCP 458 can prevent transmission of data due to empty windows. As a result, 459 multiple Updates may be spaced closer together than orginally queued. 460 Although this is not a common occurrence, implementations should be 461 aware of this. 463 14. Ordering of Path Attributes 465 The BGP protocol suggests that BGP speakers sending multiple prefixes 466 per an UPDATE message should sort and order path attributes according 467 to Type Codes. This would help their peers to quickly identify sets 468 of attributes from different update messages which are semantically 469 different. 471 Implementers may find it useful to order path attributes according to 472 Type Code so that sets of attributes with identical semantics can be 473 more quickly identified. 475 15. AS_SET Sorting 477 AS_SETs are commonly used in BGP route aggregation. They reduce the 478 size of AS_PATH information by listing AS numbers only once 479 regardless of any number of times it might appear in process of 480 aggregation. AS_SETs are usually sorted in increasing order to 481 facilitate efficient lookups of AS numbers within them. This 482 optimization is entirely optional. 484 16. Control over Version Negotiation 486 Because pre-BGP-4 route aggregation can't be supported by earlier 487 version of BGP, an implementation that supports versions in addition 488 to BGP-4 should provide the version support on a per-peer basis. 490 17. Security Considerations 492 BGP a provides flexible and extendable mechanism for authentication 493 and security. The mechanism allows to support schemes with various 494 degree of complexity. BGP sessions are authenticated based on the IP 495 address of a peer. In addition, all BGP sessions are authenticated 496 based on the autonomous system number advertised by a peer. 498 Since BGP runs over TCP and IP, BGP's authentication scheme may be 499 augmented by any authentication or security mechanism provided by 500 either TCP or IP. 502 17.1. TCP MD5 Signature Option 504 [RFC 2385] defines a way in which the TCP MD5 signature option can be 505 used to validate information transmitted between two peers. This 506 method prevents any third party from injecting information (e.g., a 507 TCP Reset) into the datastream, or modifying the routing information 508 carried between two BGP peers. 510 TCP MD5 is not ubiquitously deployed at the moment, especially in 511 inter- domain scenarios, largely because of key distribution issues. 512 Most key distribution mechanisms are considered to be too "heavy" at 513 this point. 515 17.2. BGP Over IPSEC 517 BGP can run over IPSEC, either in a tunnel, or in transport mode, 518 where the TCP portion of the IP packet is encrypted. This not only 519 prevents random insertion of information into the data stream between 520 two BGP peers, it also prevents an attacker from learning the data 521 which is being exchanged between the peers. 523 IPSEC does, however, offer several options for exchanging session 524 keys, which may be useful on inter-domain configurations. These 525 options are being explored in many deployments, although no 526 definitive solution has been reached on the issue of key exchange for 527 BGP in IPSEC. 529 It should be noted that since BGP runs over TCP and IP, BGP is 530 vulnerable to the same denial of service or authentication attacks 531 that are present in any other TCP based protocol. 533 17.3. Miscellaneous 535 Another issue any routing protocol faces is providing evidence of the 536 validity and authority of the routing information carried within the 537 routing system. This is currently the focus of several efforts at 538 the moment, including efforts to define the threats which can be used 539 against this routing information in BGP [draft-murphy, attack tree], 540 and efforts at developing a means to provide validation and authority 541 for routing information carried within BGP [SBGP] [soBGP]. 543 In addition, the Routing Protocol Security Requirements (RPSEC) 544 working group has been chartered within the Routing Area of the IETF 545 in order to discuss and assist in addressing issues surrounding 546 routing protocol security. It is the intent that this work within 547 RPSEC will result in feedback to BGPv4 and future enhancements to the 548 protocol where appropriate. 550 17.4. PTOMAINE and GROW 552 The Prefix Taxonomy (PTOMAINE) working group, recently replaced by 553 the Global Routing Operations (GROW) working group, is chartered to 554 consider and measure the problem of routing table growth, the effects 555 of the interactions between interior and exterior routing protocols, 556 and the effect of address allocation policies and practices on the 557 global routing system. Finally, where appropriate, GROW will also 558 document the operational aspects of measurement, policy, security and 559 VPN infrastructures. 561 One such item GROW is currently studying is the effects of route 562 aggregation and the inability to aggregate over multiple provider 563 boundaries due to inadequate provider coordination. 565 It is the intent that this work within GROW will result in feedback 566 to BGPv4 and future enhancements to the protocol as necessary. 568 17.5. Internet Routing Registries (IRRs) 570 Many organizations register their routing policy and prefix 571 origination in the various distributed databases of the Internet 572 Routing Registry. These databases provide access to the information 573 using the RPSL language as defined in [RFC 2622]. While registered 574 information may be maintained and correct for certain providers, the 575 lack of timely or correct data in the various IRR databases has 576 prevented wide-spread use of this resource. 578 17.6. Regional Internet Registries (RIRs) and IRRs, A Bit of History 580 The NSFNET program used EGP and then BGP to provide external routing 581 information. It was the NSF policy of offering differing pricing and 582 providing a different level of support to the Research and Education 583 (RE) networks and the Commercial (CO) networks that led to BGP's 584 initial policy requirements. CO networks were not able to use the 585 NSFNET backbone to reach other CO networks, in addition to being 586 charged more. The rationelle was that commercial users of the NSFNET 587 with business with research entities should subsidize the RE 588 community. Recognition that the Internet was evolving away from a 589 hierarchical network to a mesh of peers led to changes from EGP and 590 BGP-1 that eliminated any assumptions of hierarchy. 592 Enforcement of NSF policy was accomplished through maintenance of the 593 NSF Policy Routing Database (PRDB). The PRDB not only contained each 594 networks designation as CO or RE, but also contained a list of the 595 preferred exit points to the NSFNET to reach each network. This was 596 the basis for setting what would later be called BGP LOCAL_PREF on 597 the NSFNET. Tools provided with the PRDB generated complete router 598 configurations for the NSFNET. 600 Use of the PRDB had the fortunate consequence of greatly improving 601 reliability of the NSFNET relative to peer networks of the time and 602 offering more optimal routing for those networks sufficiently 603 knowledgeable and willing to keep their entries current. 605 With the decommission of the NSFNET Backbone Network Service in 1995, 606 it was recognized that the PRDB should be made less single provider 607 centric and its legacy contents plus any further updates made 608 available to any provider willing to make use of it. The European 609 networking community had long seen the PRDB as too US centric. 610 Through Reseaux IP Europeens (RIPE) the Europeans had created an open 611 format in RIPE-181 and had been maintaining an open database used for 612 address and AS registry more than policy. The initial conversion of 613 the PRDB was to RIPE-181 format and tools were converted to make use 614 of this format. The collection of databases was termed the Internet 615 Routing Registry, with the RIPE database and US NSF funded Routing 616 Arbitrator (RA) being the inital components of the IRR. 618 A need to extend RIPE-181 was recognized and RIPE agreed to allow the 619 extensions to be defined within the IETF in the RPS WG. The result 620 was the RPSL language. Other work products of the RPS WG provided an 621 authentication framework and means to widely distribute the database 622 in a controlled manner and synchronize the many repositories. Freely 623 available tools were provided primarily by RIPE, Merit, and ISI, the 624 most comprehensive set from ISI. The efforts of the IRR participants 625 has been severely hampered by providers unwilling to keep information 626 in the IRR up to date. The larger of these providers have been 627 vocal, claiming that the database entry, simple as it may be, are an 628 administrative burden and some acknowledge that doing so provides a 629 advantage to competitors that use the IRR. The result has been an 630 erosion of the usefulness of the IRR and an increase in vulnerability 631 of the Internet to routing based attack or accidental injection of 632 faulty routing information. 634 There have been numerous cases of accidental disruption of Internet 635 routing which were avoided by providers using the IRR but highly 636 detrimental to non-users. As filters have had to be relaxed due to 637 the erosion of the IRR to less complete coverage, these types of 638 disruptions have continued to occur very infrequently, but have had 639 increasingly widespread impact. 641 17.7. Acknowledgements 643 We would like to thank Paul Traina and Yakov Rekhter for authoring 644 previous versions of this document and providing valuable input on 645 this update as well. We would also like to explicitly acknowledge 646 Curtis Villamizar for providing both text and thorough reviews. 647 Thanks to Russ White, Jeffrey Haas, Sean Mentzer, Mitchell Erblich 648 and Jude Ballard for supplying their usual keen eye. 650 Finally, we'd like to think the IDR WG for general and specific input 651 that contributed to this document. 653 18. References 655 [RFC 793] Postel, J., "Transmission Control Protocol", RFC 793, 656 September 1981. 658 [RFC 1105] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol 659 BGP", RFC 1105, June 1989. 661 [RFC 1163] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol 662 BGP", RFC 1105, June 1990. 664 [RFC 1264] Hinden, R., "Internet Routing Protocol Standardization 665 Criteria", RFC 1264, October 1991. 667 [RFC 1267] Lougheed, K., and Rekhter, Y, "Border Gateway Protocol 3 668 (BGP-3)", RFC 1105, October 1991. 670 [RFC 1269] Willis, S., and Burruss, J., "Definitions of Managed 671 Objects for the Border Gateway Protocol (Version 3)", 672 RFC 1269, October 1991. 674 [RFC 1519] Fuller, V., Li. T., Yu J., and K. Varadhan, "Classless 675 Inter-Domain Routing (CIDR): an Address Assignment and 676 Aggregation Strategy", RFC 1519, September 1993. 678 [RFC 1656] Traina, P., "BGP-4 Protocol Document Roadmap and 679 Implementation Experience", RFC 1656, July 1994. 681 [RFC 1657] Willis, S., Burruss, J., Chu, J., " Definitions of 682 Managed Objects for the Fourth Version of the Border 683 Gateway Protocol (BGP-4) using SMIv2", RFC 1657, July 684 1994. 686 [RFC 1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 687 (BGP-4)", RFC 1771, March 1995. 689 [RFC 1772] Rekhter, Y., and P. Gross, Editors, "Application of the 690 Border Gateway Protocol in the Internet", RFC 1772, March 691 1995. 693 [RFC 1773] Traina, P., "Experience with the BGP-4 protocol", RFC 694 1773, March 1995. 696 [RFC 1966] Bates, T., Chandra, R., "BGP Route Reflection: An 697 alternative to full mesh IBGP", RFC 1966, June 1996. 699 [RFC 2385] Heffernan, A., "Protection of BGP Sessions via the TCP 700 MD5 Signature Option", RFC 2385, August 1998. 702 [RFC 2439] Villamizar, C. and Chandra, R., "BGP Route Flap Damping", 703 RFC 2439, November 1998. 705 [RFC 2622] C. Alaettinoglu et al., "Routing Policy Specification 706 Language", RFC 2622, June 1999. 708 [RFC 2796] Bates, T., Chandra, R., and Chen, E, "Route Reflection - 709 An Alternative to Full Mesh IBGP", RFC 2796, April 2000. 711 [RFC 3065] Traina, P., McPherson, D., and Scudder, J, "Autonomous 712 System Confederations for BGP", RFC 3065, Febuary 2001. 714 [RFC 3345] McPherson, D., Gill, V., Walton, D., and Retana, A, "BGP 715 Persistent Route Oscillation Condition", RFC 3345, 716 August 2002. 718 [BGP4-ANALYSIS] Work in Progress. 720 [BGP4-IMPL] Work in Progress. 722 [BGP4] Rekhter, Y., T. Li., and Hares. S, Editors, "A Border 723 Gateway Protocol 4 (BGP-4)", BGP Draft, Work in Progress. 725 [SBGP] 727 [soBGP] 729 19. Authors' Addresses 731 Danny McPherson 732 Arbor Networks 733 Email: danny@arbor.net 735 Keyur Patel 736 Cisco Systems 737 Email: keyupate@cisco.com 739 20. Full Copyright Statement 741 Copyright (C) The Internet Society (2003). All Rights Reserved. 743 This document and translations of it may be copied and furnished to 744 others, and derivative works that comment on or otherwise explain it 745 or assist in its implementation may be prepared, copied, published 746 and distributed, in whole or in part, without restriction of any 747 kind, provided that the above copyright notice and this paragraph are 748 included on all such copies and derivative works. However, this 749 document itself may not be modified in any way, such as by removing 750 the copyright notice or references to the Internet Society or other 751 Internet organizations, except as needed for the purpose of 752 developing Internet standards in which case the procedures for 753 copyrights defined in the Internet Standards process must be 754 followed, or as required to translate it into languages other than 755 English. 757 The limited permissions granted above are perpetual and will not be 758 revoked by the Internet Society or its successors or assigns. 760 This document and the information contained herein is provided on an 761 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 762 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 763 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 764 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 765 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.