idnits 2.17.1 draft-ietf-bgp-idrp-usage-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == Mismatching filename: the document gives the document name as 'draft-ietf-bgp-idrp-idrp-usage-00', but the file name used is 'draft-ietf-bgp-idrp-usage-00' ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 20 longer pages, the longest (page 11) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([3], [6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 (September 1993) is 11179 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: '1' is defined on line 995, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1021, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Unknown state RFC: RFC 1104 (ref. '2') ** Obsolete normative reference: RFC 1519 (ref. '3') (Obsoleted by RFC 4632) ** Downref: Normative reference to an Historic RFC: RFC 1518 (ref. '4') ** Downref: Normative reference to an Historic RFC: RFC 1520 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 16 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Y. Rekhter 2 Request for Comments: DRAFT T.J. Watson Research Center, IBM Corp. 3 draft-ietf-bgp-idrp-idrp-usage-00.txt S. Hares 4 Merit, Inc. 5 Editors 6 September 1993 8 Application of the Border Gateway Protocol and IDRP for IP in the Internet 10 Status of this Memo 12 This document, together with its companion documents, "A Border 13 Gateway Gateway Protocol 4 (BGP-4)" and "IDRP for IP", defines an 14 inter-autonomous system routing protocol for the Internet. This RFC 15 specifies an IAB standards track protocol for the Internet community, 16 and requests discussion and suggestions for improvements. Please 17 refer to the current edition of the "IAB Official Protocol Standards" 18 for the standardization state and status of this protocol. 19 Distribution of this document is unlimited. 21 This document is an Internet Draft. Internet Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its Areas, 23 and its Working Groups. Note that other groups may also distribute 24 working documents as Internet Drafts. 26 Internet Drafts are draft documents valid for a maximum of six 27 months. Internet Drafts may be updated, replaced, or obsoleted by 28 other documents at any time. It is not appropriate to use Internet 29 Drafts as reference material or to cite them other than as a "working 30 draft" or "work in progress". 32 Abstract 34 This document, together with its companion documents, "A Border 35 Gateway Protocol 4 (BGP-4)" and "IDRP for IP", define an inter- 36 autonomous system routing protocol for the Internet. "A Border 37 Gateway Protocol 4 (BGP-4)" defines the BGP protocol specification. 38 "IDRP for IP" defines the use of IDRP for IP in the Internet. The 39 IDRP specification [6] defines the IDRP protocol. This document 40 describes the usage of the BGP and IDRP for IP in the Internet. 42 Information about the progress of BGP can be monitored and/or 43 reported on the BGP mailing list (bgp@ans.net). Information about 44 the progress of IDRP for IP can be monitored and/or reported on the 45 IDRP for IP mailing list (idrp-for-ip@merit.edu). 47 Acknowledgements 49 This document was originally published as RFC 1164 in June 1990, 50 jointly authored by Jeffrey C. Honig (Cornell University), Dave Katz 51 (Merit), Matt Mathis (PSC), Yakov Rekhter (IBM), and Jessica Yu 52 (Merit). 54 The following people also made key contributions to RFC 1164 -- Guy 55 Almes (ANS, then at Rice University), Kirk Lougheed (cisco Systems), 56 Hans- Werner Braun (SDSC, then at Merit), and Sue Hares (Merit). 58 We would like to explicitly thank Bob Braden (ISI) for the review of 59 the previous version of this document. 61 This updated version of the document was the product of the IETF BGP 62 Working Group with Phill Gross (ANS) and Yakov Rekhter (IBM) as 63 editors. Finally, the current version of the document covers the 64 usage of both BGP and IDRP for IP. The document is the product of 65 both the IETF BGP and IDRP for IP Working Groups with Susan Hares 66 (Merit, Inc.) and Yakov Rekhter (IBM) as editors. 68 John Moy (Proteon) contributed Section 7 "Required set of supported 69 routing policies". 71 Scott Brim (Cornell University) contributed the basis for Section 8 72 "Interaction with other exterior routing protocols". 74 Most of the text in Section 9 was contributed by Gerry Meyer 75 (Spider). 77 John Scudder (Merit) contributed bits of text throughout and did 78 proofreading and editing of several drafts of the document. 80 Parts of the Introduction were taken almost verbatim from [3]. 82 We would like to acknowledge Dan Long (NEARNET) and Tony Li (cisco 83 Systems) for their review and comments on the previous version of the 84 document. 86 1. Introduction 88 This memo describes the use of the Border Gateway Protocol (BGP) and 89 "IDRP for IP" in the Internet environment. IDRP and BGP are inter- 90 Autonomous System routing protocols. IDRP and BGP have common roots 91 in version 2 of BGP. However, IDRP has been standardized within ISO 92 as a multi-protocol inter-domain routing protocol. IDRP for IP and 93 BGP-4 can be considered, for the most part, interchangeable. IDRP 94 has a few additional features, and some minor differences in 95 encoding. The usage of these additional features will be discussed 96 in Section 10. 98 Hereafter in this memo, "BGP" will refer to both BGP-4 and IDRP for 99 IP. BGP-4 will refer only to version 4 of BGP, and IDRP will refer 100 to only the IDRP for IP protocol. 102 The network reachability information exchanged via BGP provides 103 sufficient information to detect routing loops and enforce routing 104 decisions based on performance preference and policy constraints as 105 outlined in RFC 1104 [2]. In particular, BGP exchanges routing 106 information containing full AS paths and enforces routing policies 107 based on configuration information. 109 As the Internet has evolved and grown, it has become evident that it 110 is soon to face several serious scaling problems. These include: 112 Exhaustion of the class B network address space. One fundamental 113 cause of this problem is the lack of a network class of a size which 114 is appropriate for mid-sized organizations; class C, with a maximum 115 of 254 host addresses, is too small while class B, which allows up to 116 65534 addresses, is too large to be densely populated. Growth of 117 routing tables in Internet routers is beyond the ability of current 118 software (and people) to effectively manage. Eventual exhaustion of 119 the 32-bit IP address space. 121 It has become clear that the first two of these problems are likely 122 to become critical within the next one to three years. Classless 123 inter-domain routing (CIDR) attempts to deal with these problems by 124 proposing a mechanism to slow the growth of the routing table and the 125 need for allocating new IP network numbers. It does not attempt to 126 solve the third problem, which is of a more long-term nature, but 127 instead endeavors to ease enough of the short to mid-term 128 difficulties to allow the Internet to continue to function 129 efficiently while progress is made on a longer-term solution. 131 BGP-4 is an extension of BGP-3 that provides support for routing 132 information aggregation and reduction based on the Classless inter- 133 domain routing architecture (CIDR) [4]. BGP-4 contains many of the 134 features initially put into the multi-protocol ISO IDRP protocol. 135 This memo describes the usage of both BGP-4 and IDRP for IP in the 136 Internet. 138 All of the discussions in this paper are based on the assumption that 139 the Internet is a collection of arbitrarily connected Autonomous 140 Systems. That is, the Internet will be modeled as a general graph 141 whose nodes are AS's and whose edges are connections between pairs of 142 AS's. 144 The classic definition of an Autonomous System is a set of routers 145 under a single technical administration, using an interior gateway 146 protocol and common metrics to route packets within the AS and using 147 an exterior gateway protocol to route packets to other AS's. Since 148 this classic definition was developed, it has become common for a 149 single AS to use several interior gateway protocols and sometimes 150 several sets of metrics within an AS. The use of the term Autonomous 151 System here stresses the fact that, even when multiple IGPs and 152 metrics are used, the administration of an AS appears to other AS's 153 to have a single coherent interior routing plan and presents a 154 consistent picture of which networks are reachable through it. 156 AS's are assumed to be administered by a single administrative 157 entity, at least for the purposes of representation of routing 158 information to systems outside of the AS. 160 2. BGP Topological Model 162 When we say that a connection exists between two AS's, we mean two 163 things: 165 Physical connection: There is a shared network between the two 166 AS's, and on this shared network each AS has at least one border 167 gateway belonging to that AS. Thus the border gateway of each AS 168 can forward packets to the border gateway of the other AS without 169 resorting to Inter-AS or Intra-AS routing. 171 BGP connection: There is a BGP session between BGP speakers in 172 each of the AS's, and this session communicates those routes that 173 can be used for specific networks via the advertising AS. 174 Throughout this document we place an additional restriction on the 175 BGP speakers that form the BGP connection: they must themselves 176 share the same network that their border gateways share. Thus, a 177 BGP session between adjacent AS's requires no support from either 178 Inter-AS or Intra-AS routing. Cases that do not conform to this 179 restriction fall outside the scope of this document. 181 Thus, at each connection, each AS has one or more BGP speakers and 182 one or more border gateways, and these BGP speakers and border 183 gateways are all located on a shared network. Note that BGP speakers 184 do not need to be a border gateway, and vice versa. Paths announced 185 by a BGP speaker of one AS on a given connection are taken to be 186 feasible for each of the border gateways of the other AS on the same 187 shared network, i.e. indirect neighbors are allowed. 189 Much of the traffic carried within an AS either originates or 190 terminates at that AS (i.e., either the source IP address or the 191 destination IP address of the IP packet identifies a host on a 192 network internal to that AS). Traffic that fits this description is 193 called "local traffic". Traffic that does not fit this description is 194 called "transit traffic". A major goal of BGP usage is to control the 195 flow of transit traffic. 197 Based on how a particular AS deals with transit traffic, the AS may 198 now be placed into one of the following categories: 200 Stub AS: an AS that has only a single connection to one other AS. 201 Naturally, a stub AS only carries local traffic. 203 Multihomed AS: an AS that has connections to more than one other 204 AS, but refuses to carry transit traffic. 206 Transit AS: an AS that has connections to more than one other AS, 207 and is designed (under certain policy restrictions) to carry both 208 transit and local traffic. 210 Since a full AS path provides an efficient and straightforward way of 211 suppressing routing loops and eliminates the "count-to-infinity" 212 problem associated with some distance vector algorithms, BGP imposes 213 no topological restrictions on the interconnection of AS's. 215 3. BGP in the Internet 217 3.1 Topology Considerations 219 The overall Internet topology may be viewed as an arbitrary 220 interconnection of transit, multihomed, and stub AS's. In order to 221 minimize the impact on the current Internet infrastructure, stub and 222 multihomed AS's need not use BGP. These AS's may run other protocols 223 (e.g., EGP) to exchange reachability information with transit AS's. 224 Transit AS's using BGP will tag this information as having been 225 learned by some method other than BGP. The fact that BGP need not run 226 on stub or multihomed AS's has no negative impact on the overall 227 quality of inter-AS routing for traffic that either destined to or 228 originated from the stub or multihomed AS's in question. 230 However, it is recommended that BGP be used for stub and multihomed 231 AS's as well. In these situations, BGP will provide an advantage in 232 bandwidth and performance over some of the currently used protocols 233 (such as EGP). In addition, this would reduce the need for the use 234 of default routes and in better choices of Inter-AS routes for 235 multihomed AS's. 237 3.2 Global Nature of BGP 239 At a global level, BGP is used to distribute routing information 240 among multiple Autonomous Systems. The information flows can be 241 represented as follows: 243 +-------+ +-------+ 244 BGP | BGP | BGP | BGP | BGP 245 ---------+ +---------+ +--------- 246 | IGP | | IGP | 247 +-------+ +-------+ 249 <-AS A--> <--AS B-> 251 This diagram points out that, while BGP alone carries information 252 between AS's, both BGP and an IGP may carry information across an AS. 253 Ensuring consistency of routing information between BGP and an IGP 254 within an AS is a significant issue and is discussed at length later 255 in Appendix A. 257 3.3 BGP Neighbor Relationships 259 The Internet is viewed as a set of arbitrarily connected AS's. BGP 260 speakers in each AS communicate with each other to exchange network 261 reachability information based on a set of policies established 262 within each AS. Routers that communicate directly with each other via 263 BGP are known as BGP neighbors. BGP neighbors can be located within 264 the same AS or in different AS's. For the sake of discussion, BGP 265 communications with neighbors in different AS's will be referred to 266 as External BGP, and with neighbors in the same AS as Internal BGP. 268 There can be as many BGP speakers as deemed necessary within an AS. 269 Usually, if an AS has multiple connections to other AS's, multiple 270 BGP speakers are needed. All BGP speakers representing the same AS 271 must give a consistent image of the AS to the outside. This requires 272 that the BGP speakers have consistent routing information among them. 273 These gateways can communicate with each other via BGP or by other 274 means. The policy constraints applied to all BGP speakers within an 275 AS must be consistent. Techniques such as using a tagged IGP (see 276 A.2.2) may be employed to detect possible inconsistencies. 278 In the case of External BGP, the BGP neighbors must belong to 279 different AS's, but share a common network. This common network 280 should be used to carry the BGP messages between them. The use of BGP 281 across an intervening AS invalidates the AS path information. An 282 Autonomous System number must be used with BGP to specify which 283 Autonomous System the BGP speaker belongs to. 285 4. Requirements for Route Aggregation 287 A conformant BGP implementation is required to have the ability to 288 specify when an aggregated route may be generated out of partial 289 routing information. For example, a BGP speaker at the border of an 290 autonomous system (or group of autonomous systems) must be able to 291 generate an aggregated route for a whole set of destination IP 292 addresses (in BGP terminology such a set is called the Network Layer 293 Reachability Information or NLRI) over which it has administrative 294 control, even when not all of them are reachable at the same time. 296 A conformant implementation is required to have the ability to 297 specify how NLRI may be de-aggregated. 299 A conformant implementation is required to support the following 300 options when dealing with overlapping routes: 302 Install both the less and the more specific routes Install the more 303 specific route only Install neither route 305 A conformant implementation may also support other options when 306 dealing with overlapping routes, as specified in Clause 7.16.3.1 of 307 [6]. 309 By default a BGP speaker should aggregate NLRI representing subnets 310 to the corresponding network. 312 Injecting NLRI representing arbitrary subnets into BGP without 313 aggregation to the corresponding network shall be controlled via 314 configuration parameters. 316 Certain routing policies may depend on the NLRI (e.g. "research" 317 versus "commercial"). Therefore, a BGP speaker that performs route 318 aggregation should be cognizant, if possible, of potential 319 implications on routing policies when aggregating NLRI. 321 5. Policy Making with BGP 323 BGP provides the capability for enforcing policies based on various 324 routing preferences and constraints. Policies are not directly 325 encoded in the protocol. Rather, policies are provided to BGP in the 326 form of configuration information. 328 BGP enforces policies by affecting the selection of paths from 329 multiple alternatives and by controlling the redistribution of 330 routing information. Policies are determined by the AS 331 administration. 333 Routing policies are related to political, security, or economic 334 considerations. For example, if an AS is unwilling to carry traffic 335 to another AS, it can enforce a policy prohibiting this. The 336 following are examples of routing policies that can be enforced with 337 the use of BGP: 339 A multihomed AS can refuse to act as a transit AS for other AS's. 340 (It does so by only advertising routes to networks internal to the 341 AS.) A multihomed AS can become a transit AS for a restricted set of 342 adjacent AS's, i.e., some, but not all, AS's can use the multihomed 343 AS as a transit AS. (It does so by advertising its routing 344 information to this set of AS's.) An AS can favor or disfavor the use 345 of certain AS's for carrying transit traffic from itself. 347 A number of performance-related criteria can be controlled with the 348 use of BGP: 350 An AS can minimize the number of transit AS's. (Shorter AS paths can 351 be preferred over longer ones.) The quality of transit AS's. If an AS 352 determines that two or more AS paths can be used to reach a given 353 destination, that AS can use a variety of means to decide which of 354 the candidate AS paths it will use. The quality of an AS can be 355 measured by such things as diameter, link speed, capacity, tendency 356 to become congested, and quality of operation. Information about 357 these qualities might be determined by means other than BGP. 358 Preference of internal routes over external routes. 360 For consistency within an AS, equal cost paths, resulting from 361 combinations of policies and/or normal route selection procedures, 362 must be resolved in a consistent fashion. 364 Fundamental to BGP is the rule that an AS advertises to its 365 neighboring AS's only those routes that it uses. This rule reflects 366 the "hop-by-hop" routing paradigm generally used by the current 367 Internet. 369 IDRP for IP has two features (DIST_LIST_INCL and DIST_LIST_EXCL) 370 which allow additional constraints to be placed on the propagation of 371 routing information, by restricting the group of AS's which may 372 receive certain information. See Section 10 for further details. 374 6. Path Selection with BGP 376 One of the major tasks of a BGP speaker is to evaluate different 377 paths to a destination network from its border gateways, select the 378 best one, apply appropriate policy constraints, and then advertise it 379 to all of its BGP neighbors. The key issue is how different paths are 380 evaluated and compared. In traditional distance vector protocols 381 (e.g., RIP) there is only one metric (e.g., hop count) associated 382 with a path. As such, comparison of different paths is reduced to 383 simply comparing two numbers. A complication in Inter-AS routing 384 arises from the lack of a universally agreed-upon metric among AS's 385 that can be used to evaluate external paths. Rather, each AS may have 386 its own set of criteria for path evaluation. 388 A BGP speaker builds a routing database consisting of the set of all 389 feasible paths and the list of networks reachable through each path. 390 For purposes of precise discussion, it's useful to consider the set 391 of feasible paths for a given destination network. In many cases, we 392 would expect to find only one feasible path. However, when this is 393 not the case, all feasible paths should be maintained, as their 394 maintenance speeds adaptation to the loss of the primary path. Only 395 the primary path at any given time will ever be advertised. 397 The path selection process can be formalized by defining a partial 398 order over the set of all feasible paths to a given destination 399 network. One way to define this partial order is to define a function 400 that maps each full AS path to a non-negative integer that denotes 401 the path's degree of preference. Path selection is then reduced to 402 applying this function to all feasible paths and choosing the one 403 with the lowest degree of preference. 405 In actual BGP implementations, the criteria for assigning degree of 406 preferences to a path are specified as configuration information. 408 The process of assigning a degree of preference to a path can be 409 based on several sources of information: 411 Information explicitly present in the full AS path. A combination of 412 information that can be derived from the full AS path and information 413 outside the scope of BGP (e.g., policy routing constraints provided 414 as configuration information). 416 Possible criteria for assigning a degree of preference to a path are: 418 AS count. Paths with a smaller AS count are generally better. Policy 419 considerations. BGP supports policy-based routing based on the 420 controlled distribution of routing information. A BGP speaker may be 421 aware of some policy constraints (both within and outside of its own 422 AS) and do appropriate path selection. Paths that do not comply with 423 policy requirements are not considered further. Presence or absence 424 of a certain AS or set of AS's in the path. By means of information 425 outside the scope of BGP, an AS may know some performance 426 characteristics (e.g., bandwidth, MTU, intra-AS diameter) of certain 427 AS's and may try to avoid or prefer them. Path origin. A path 428 learned entirely from BGP (i.e., whose endpoint is internal to the 429 last AS on the path) is generally better than one for which part of 430 the path was learned via EGP or some other means. AS path subsets. 431 An AS path that is a subset of a longer AS path to the same 432 destination should be preferred over the longer path. Any problem in 433 the shorter path (such as an outage) will also be a problem in the 434 longer path. Link dynamics. Stable paths should be preferred over 435 unstable ones. Note that this criterion must be used in a very 436 careful way to avoid causing unnecessary route fluctuation. 437 Generally, any criteria that depend on dynamic information might 438 cause routing instability and should be treated very carefully. 440 7. Recommended Set of Supported Routing Policies. 442 Policies are provided to BGP in the form of configuration 443 information. This information is not directly encoded in the 444 protocol. Therefore, BGP can provide support for very complex routing 445 policies. However, it is not required that all BGP implementations 446 support such policies. 448 While we are not attempting to standardize the routing policies that 449 must be supported in every BGP implementation, we strongly encourage 450 all implementors to support the following set of routing policies: 452 BGP implementations should allow an AS to control announcements of 453 BGP-learned routes to adjacent AS's. Implementations should support 454 such control with at least the granularity of a single network. 455 Implementations should also support such control with the granularity 456 of an autonomous system, where the autonomous system may be either 457 the autonomous system that originated the route, or the autonomous 458 system that advertised the route to the local system (adjacent 459 autonomous system). Care must be taken when a BGP speaker selects a 460 new route that can't be announced to a particular external peer, 461 while the previously selected route was announced to that peer. 462 Specifically, the local system must explicitly indicate to the peer 463 that the previous route is now infeasible. BGP implementations 464 should allow an AS to prefer a particular path to a destination (when 465 more than one path is available). This function may be implemented 466 by allowing system administrators to assign "weights" to AS's, and by 467 having the route selection process select a route with the lowest 468 "weight" (where "weight" of a route is defined as a sum of "weights" 469 of all AS's in the AS_PATH path attribute associated with that 470 route). BGP implementations should allow an AS to ignore routes with 471 certain AS's in the AS_PATH path attribute. Such function can be 472 implemented by using the technique outlined in [2], and by assigning 473 "infinity" as "weights" for such AS's. The route selection process 474 must ignore routes that have "weight" equal to "infinity". 476 8. Interaction With Other Exterior Routing Protocols 478 This section presents guidelines for routing information exchange 479 between BGP and BGP-3 or EGP-2, as well as between BGP-4 and IDRP. 480 The suggested guidelines are consistent with the guidelines presented 481 in [3], [4], and [5]. 483 The routing information exchange has the following aspects: how a 484 route received via EGP2/BGP-3 gets injected into BGP how a route 485 received via BGP gets injected into EGP2/BGP-3 how a route received 486 via BGP-4 gets injected into IDRP how a route received via IDRP gets 487 injected into BGP-4 489 An AS should advertise a minimal aggregate for its internal networks 490 with respect to the amount of address space that it is actually 491 using. This can be used by administrators of non-BGP AS's to 492 determine how many routes to explode from a single aggregate. 494 8.1 Exchanging Information With EGP2 496 The following guidelines are suggested for exchanging routing 497 information between BGP and EGP2. 499 To provide for graceful migration, a BGP speaker may participate in 500 EGP2 as well as in BGP. Thus, a BGP speaker may receive IP 501 reachability information by means of EGP2 as well as by means of BGP. 502 It is strongly recommended that the exchange of routing information 503 via EGP2 between a BGP speaker participating in BGP and a pure EGP2 504 speaker occur only at Autonomous System boundaries. 506 The information received by EGP2 can be injected into BGP-4 with the 507 ORIGIN path attribute set to 1. It can likewise be injected into 508 IDRP with the EXT_INFO path attribute. 510 Likewise, the information received via BGP can be injected into EGP2. 511 In the latter case, however, one needs to be aware of the potential 512 information explosion when a given IP prefix received from BGP 513 denotes a set of consecutive A/B/C class networks. Injection of BGP 514 received NLRI that denotes IP subnets requires the BGP speaker to 515 inject the corresponding network into EGP2. 517 The local system shall provide mechanisms to control the exchange of 518 reachability information between EGP2 and BGP. Specifically, a 519 conformant implementation is required to support all of the following 520 options when injecting BGP received reachability information into 521 EGP2: 523 inject default only (0.0.0.0); no export of any other NLRI allow 524 controlled deaggregation, but only of specific routes; allow export 525 of non-aggregated NLRI allow export of only non-aggregated NLRI 527 Additional constraints on injecting information received via IDRP 528 into EGP2 are listed in Section 8.4. Additional constraints on 529 injecting information received via BGP-4 into EGP2 are listed in 530 Section 8.5. 532 8.2 Exchanging information with BGP-3 534 The following guidelines are suggested for exchanging routing 535 information between BGP and BGP-3. 537 To provide for graceful migration, a BGP speaker may participate in 538 BGP-3 as well as in BGP. Thus, a BGP speaker may receive IP 539 reachability information by means of BGP-3 as well as by means of 540 BGP. It is strongly recommended that the exchange of routing 541 information via BGP-3 between a BGP speaker participating in BGP-3 542 and a pure BGP-3 speaker occur only at Autonomous System boundaries. 544 When injecting BGP-3 routes into BGP-4, the AS_SEQUENCE information 545 shall be injected as an AS_SET. For IDRP, the AS_SEQUENCE 546 information shall be injected as an RD_SET within the RD_PATH 547 attribute. 549 A BGP speaker may inject the information received by BGP-4 into BGP-3 550 as follows. 552 If an AS_PATH attribute of a BGP-4 route carries AS_SET path 553 segments, then the AS_PATH attribute of the BGP-3 route shall be 554 constructed by treating the AS_SET segments as AS_SEQUENCE segments, 555 with the resulting AS_PATH being a single AS_SEQUENCE. While this 556 procedure loses set/sequence information, it doesn't affect 557 protection for routing loops suppression. It may affect policies if 558 they are based on the content or ordering of the AS_PATH attribute. 560 A BGP speaker may inject the information received by IDRP into BGP-3 561 as follows. 563 IDRP's equivalent for the AS_PATH attribute is RD_PATH path 564 attribute, where RD stands for Routing Domain. A Routing Domain has 565 an identifier which for IDRP for IP is a fixed prefix catenated with 566 the AS number. Given this translation, as defined in the "IDRP for 567 IP" document, the IDRP RD_PATH information containing RD_SEQUENCEs 568 and RD_SETs is translated into BGP-3 AS_SEQUENCES attribute in the 569 same way BGP-4's AS_SEQUENCEs and AS-SETs are. The resulting BGP-3 570 AS_PATH attribute contains all the domains listed in the RD_PATH 571 attribute. Again, this does not affect loop suppression, but may 572 affect policies. 574 While injecting BGP derived NLRI into BGP-3, one needs to be aware of 575 the potential information explosion when a given IP prefix denotes a 576 set of consecutive A/B/C class networks. Injection of BGP derived 577 NLRI that denotes IP subnets requires the BGP speaker to inject the 578 corresponding network into BGP-3. The local system shall provide 579 mechanisms to control the exchange of routing information between 580 BGP-3 and BGP. Specifically, a conformant implementation is required 581 to support all of the following options when injecting BGP received 582 routing information into BGP-3: 584 inject default only (0.0.0.0), no export of any other NLRI allow 585 controlled deaggregation, but only of specific routes; allow export 586 of non-aggregated NLRI allow export of only non-aggregated NLRI 588 Additional constraints on injecting information received via IDRP 589 into BGP-3 are listed in Section 8.4. Additional constraints on 590 injecting information received via BGP-4 into BGP-3 are listed in 591 Section 8.5. 593 8.3 Exchanging Information Between IDRP and BGP-4 595 To provide for graceful migration, an IDRP speaker may participate in 596 BGP-4. Thus, an IDRP speaker may receive IP reachability information 597 by means of BGP-4, as well as by means of IDRP. If IDRP for IP and 598 BGP-4 routers restrict themselves to the set of functions which is 599 common to both protocols, translation between the protocols can be 600 done. Within these restrictions, routers can participate in both 601 IDRP and BGP-4 conversations on domain boundaries, and within routing 602 domains. 604 When passing a BGP-4 route with the ATOMIC_AGGREGATE path attribute 605 to IDRP, the IDRP for IP ATOMIC_AGGREGATE shall be included in the 606 IDRP route. The ATOMIC_AGGREGATE attribute is defined in [7]. 608 Note that any IDRP for IP router receiving a route with the 609 ATOMIC_AGGREGATE option shall not deaggregate that route. 611 Also note that any IDRP router not recognizing the ATOMIC_AGGREGATE 612 option shall set the Partial bit in the Flag field of the attribute 613 to 1, as required by clause 7.11.1.a in [6]. 615 In exporting reachability information from IDRP for IP to BGP-4, if 616 the IDRP for IP ATOMIC_AGGREGATE attribute is present and the Partial 617 bit is set to 0, the BGP-4 ATOMIC_AGGREGATE attribute shall be 618 included in the BGP-4 route. If the IDRP for IP ATOMIC_AGGREGATE 619 attribute is present and the Partial bit is set to 1, the BGP-4 620 ORIGIN attribute shall be set to INCOMPLETE. 622 The following table specifies mapping between BGP-4 and IDRP for IP 623 path attributes. 625 BGP4 IDRP 626 ------------------------------- 628 ORIGIN EXT_INFO 630 AS_PATH RD_PATH 632 NEXT_HOP NEXT_HOP 634 MULTI_EXTI_DISC MULTI_EXIT_DISC 636 LOC_PREF ROUTE_SEPARATOR 638 Additional constraints on injecting information received via IDRP 639 into BGP-4 are listed in Section 8.4. 641 8.4 Additional Constraints on Exchange of IDRP Routes 643 The following IDRP attributes cannot be passed into EGP2, BGP-3, or 644 BGP-4: 646 CAPACITY RD-HOP-COUNT 648 However, IDRP routes with these attributes can be passed into EGP2, 649 BGP-3, or BGP-4 after stripping the attributes. 651 IDRP routes with the following path attributes cannot be passed into 652 BGP-3, BGP-4, and EGP2: 654 DIST_LIST_INCL DIST_LIST_EXCL HIERARCHICAL_RECORDING TRANSIT DELAY 655 RESIDUAL_ERROR EXPENSE LOCALLY DEFINED QoS SECURITY PRIORITY 657 When passing a route received via EGP2 or a route received via BGP-3 658 or BGP-4, such that the value of the ORIGIN attribute of the route is 659 anything but IGP, to IDRP, the corresponding IDRP route shall have 660 the EXT_INFO path attribute. If an IDRP route carries EXT_INFO path 661 attribute then the corresponding BGP-3 or BGP-4 route shall have 662 value of its ORIGIN attribute set to INCOMPLETE. 664 When passing a BGP-3 or BGP-4 route to IDRP, the IDRP RD-HOP-COUNT 665 attribute shall be constructed by counting the number of ASs in the 666 AS-PATH attribute of the route. 668 If an IDRP route carries ENTRY_SEQ or ENTRY_SET path segments, then 669 before passing this route to BGP-3 or BGP-4 the BIS shall assume that 670 the route exited all the confederations denoted in ENTRY_SET or 671 ENTRY_SEQ and update the RD_PATH of the route accordingly. 673 8.5 Additional Constrains on Exchange of BGP-4 Routes 675 The following BGP-4 attribute can not be passed into EGP2, BGP-3, or 676 IDRP: 678 AGGREGATOR 680 However, BGP-4 routes with this attribute can be passed into IDRP. 682 A route that carries the BGP-4 ATOMIC_AGGREGATE path attribute shall 683 not be exported into EGP2 or BGP-3, unless such export can be 684 accomplished without deaggregating the NLRI of the route. 686 9. Operations over Switched Virtual Circuits 688 When using BGP over Switched Virtual Circuit (SVC) subnetworks it may 689 be desirable to minimize traffic generated by BGP. Specifically, it 690 may be desirable to eliminate traffic associated with periodic 691 KEEPALIVE messages. BGP includes a mechanism for operation over 692 switched virtual circuit (SVC) services which avoids keeping SVCs 693 permanently open and allows it to eliminate periodic sending of 694 KEEPALIVE messages. 696 This section describes how to operate without periodic KEEPALIVE 697 messages to minimize SVC usage when using an intelligent SVC circuit 698 manager. This scheme may also be used on "permanent" circuits, which 699 support a feature like link quality monitoring or echo request to 700 determine the status of link connectivity. 702 The mechanism described in this section is suitable only between BGP 703 speakers that are directly connected over a common virtual circuit. 705 9.1 Establishing a BGP Connection 707 The feature is selected by specifying zero Hold Time in the OPEN 708 message. 710 9.2 Circuit Manager Properties 712 The circuit manager must have sufficient functionality to be able to 713 compensate for the lack of periodic KEEPALIVE messages: 715 It must be able to determine link layer unreachability within a 716 bounded time of the occurance of such a failure. On determining 717 unreachability it should: start a configurable dead timer (comparable 718 to a typical Hold timer value). attempt to re-establish the Link 719 Layer connection. 721 If the dead timer expires it should: send an internal circuit DEAD 722 indication to TCP (if used with BGP-4) or to the IDRP Finite State 723 Machine (if used with IDRP for IP) If the connection is re- 724 established before the dead timer expires it should: cancel the dead 725 timer. If the connection is re-established after the dead timer has 726 expired (that is, after a DEAD indication has been sent) it should: 727 send an internal circuit UP indication to TCP (if used with BGP-4) or 728 to the IDRP Finite State Machine (if used with IDRP for IP). 730 9.3 TCP Properties 732 A small modification must be made to TCP to process internal 733 notifications from the circuit manager: DEAD: Flush transmit queue 734 and abort TCP connection. UP: Transmit any queued data or allow an 735 outgoing TCP call to proceed. 737 9.4 IDRP Finite State Machine Properties 739 A small modification must be made to the IDRP Finite State Machine to 740 process internal notifications from the circuit manager: DEAD: 741 Generate the DEACTIVATE event UP: Generate the ACTIVATE event 743 9.5 Combined Properties 745 Some implementations may not be able to guarantee that the BGP 746 process and the circuit manager will operate as a single entity; i.e. 747 they can have a separate existence when the other has been stopped or 748 has crashed. 750 If this is the case, a periodic two-way poll between the BGP process 751 and the circuit manager should be implemented. If the BGP process 752 discovers the circuit manager has gone away it should close all 753 relevant TCP connections in the case of BGP-4 or close all relevant 754 peer sessions in the case of IDRP. If the circuit manager discovers 755 the BGP process has gone away it should close all its connections 756 associated with the BGP process and reject any further incoming 757 connections. 759 10. IDRP for IP Differences 761 The additional attributes and protocol semantics IDRP contains 762 besides those in BGP-4 fall into three categories: QoS related, 763 Distribution List related, and Routing Domain Confederations related. 765 The QoS related attributes can be thought of as an extension of the 766 TOS functions already defined in IP. These functions have been left 767 by IDRP for IP for future study and experimentation. Anyone 768 interested in IDRP's QoS features should contact the BGP/IDRP for IP 769 working groups. 771 The Distribution List attributes are DIST_LIST_INCL and 772 DIST_LIST_EXCL. Their function can be described as follows: BGP 773 speakers receive information from BGP speakers in other AS's, which 774 we call the "upstream" AS's. They then select routes from this 775 information and propagate them to other AS's, which we call the 776 "downstream" AS's. The distribution list attributes provide 777 mechanisms for the router originating some reachability information 778 (or any router downstream of it) to constrain the downstream 779 propagation of that information. If distribution list attributes are 780 included, downstream AS's are required to restrict distribution of 781 the routing information -- in the case of DIST_LIST_INCL, the routing 782 information may only be distributed to the specified set of AS's, and 783 in the case of DIST_LIST_EXCL, the routing information my be 784 distributed to any AS's but the specified set. If no distribution 785 list attributes are included, the information may be distributed 786 without constraint. 788 Routing Domain Confederations is a mechanism to group together 789 routing domains with compatible policies, in effect providing 790 "aggregation" of Routing Domains. By using RDCs, AS paths can be 791 compacted considerably. 793 With a Confederation, several AS's can be grouped together. From the 794 point of view of AS's external to the Confederation, the AS path 795 information (RD_PATH) can be replaced by a single identifier, the RDC 796 identifier. For example, if 10 associated AS's containing 30 IP 797 networks decide to form a Confederation (they might be the members of 798 an academic consortium, for example), they could advertise all 30 of 799 their networks with a single entry in the RD_PATH, abstracting the 800 internal topology of their confederation. 802 11. Conclusion 804 The BGP protocols, BGP-4 and IDRP, provide a high degree of control 805 and flexibility for doing interdomain routing while enforcing policy 806 and performance constraints and avoiding routing loops. The 807 guidelines presented here will provide a starting point for using BGP 808 to provide more sophisticated and manageable routing in the Internet 809 as it grows. 811 Appendix A. The Interaction of BGP and an IGP 813 This section outlines methods by which BGP can exchange routing 814 information with an IGP. The methods outlined here are not proposed 815 as part of the standard BGP usage at this time. These methods are 816 outlined for information purposes only. Implementors may want to 817 consider these methods when importing IGP information. 819 This is general information that applies to any generic IGP. 820 Interaction between BGP and any specific IGP is outside the scope of 821 this section. Methods for specific IGP's should be proposed in 822 separate documents. Methods for specific IGP's could be proposed for 823 standard usage in the future. 825 Overview 827 By definition, all transit AS's must be able to carry traffic which 828 originates from and/or is destined to locations outside of that AS. 829 This requires a certain degree of interaction and coordination 830 between BGP and the Interior Gateway Protocol (IGP) used by that 831 particular AS. In general, traffic originating outside of a given AS 832 will pass through both interior gateways (gateways that support the 833 IGP only) and border gateways (gateways that support both the IGP and 834 BGP). All interior gateways receive information about external routes 835 from one or more of the border gateways of the AS via the IGP, unless 836 encapsulation is used (see Section A.2.3). 838 Depending on the mechanism used to propagate BGP information within a 839 given AS, special care must be taken to ensure consistency between 840 BGP and the IGP, since changes in state are likely to propagate at 841 different rates across the AS. There may be a time window between the 842 moment when some border gateway (A) receives new BGP routing 843 information which was originated from another border gateway (B) 844 within the same AS, and the moment the IGP within this AS is capable 845 of routing transit traffic to that border gateway (B). During that 846 time window, either incorrect routing or "black holes" can occur. 848 In order to minimize such routing problems, border gateway (A) should 849 not advertise a route to some exterior network X via border gateway 850 (B) to all of its BGP neighbors in other AS's until all the interior 851 gateways within the AS are ready to route traffic destined to X via 852 the correct exit border gateway (B). In other words, interior routing 853 should converge on the proper exit gateway before/advertising routes 854 via that exit gateway to other AS's. 856 A.2 Methods for Achieving Stable Interactions 858 The following discussion outlines several techniques capable of 859 achieving stable interactions between BGP and the IGP within an 860 Autonomous System. 862 A.2.1 Propagation of BGP Information via the IGP 864 While BGP can provide its own mechanism for carrying BGP information 865 within an AS, one can also use an IGP to transport this information, 866 as long as the IGP supports complete flooding of routing information 867 (providing the mechanism to distribute the BGP information) and one 868 pass convergence (making the mechanism effectively atomic). If an IGP 869 is used to carry BGP information, then the period of 870 desynchronization described earlier does not occur at all, since BGP 871 information propagates within the AS synchronously with the IGP, and 872 the IGP converges more or less simultaneously with the arrival of the 873 new routing information. Note that the IGP only carries BGP 874 information and should not interpret or process this information. 876 A.2.2 Tagged Interior Gateway Protocol 878 Certain IGPs can tag routes exterior to an AS with the identity of 879 their exit points while propagating them within the AS. Each border 880 gateway should use identical tags for announcing exterior routing 881 information (received via BGP) both into the IGP and into Internal 882 BGP when propagating this information to other border gateways within 883 the same AS. Tags generated by a border gateway must uniquely 884 identify that particular border gateway--different border gateways 885 must use different tags. 887 All Border Gateways within a single AS must observe the following two 888 rules: 890 Information received via Internal BGP by a border gateway A declaring 891 a network to be unreachable must immediately be propagated to all of 892 the External BGP neighbors of A. Information received via Internal 893 BGP by a border gateway A about a reachable network X cannot be 894 propagated to any of the External BGP neighbors of A unless/until A 895 has an IGP route to X and both the IGP and the BGP routing 896 information have identical tags. 898 These rules guarantee that no routing information is announced 899 externally unless the IGP is capable of correctly supporting it. It 900 also avoids some causes of "black holes". 902 One possible method for tagging BGP and IGP routes within an AS is to 903 use the IP address of the exit border gateway announcing the exterior 904 route into the AS. In this case the "gateway" field in the BGP UPDATE 905 message is used as the tag. 907 An alternate method for tagging BGP and IGP routes is to have BGP and 908 the IGP agree on a router ID. In this case, the router ID is 909 available to all BGP (version 3 or higher) speakers. Since this ID 910 is already unique it can be used directly as the tag in the IGP. 912 A.2.3 Encapsulation 914 Encapsulation provides the simplest (in terms of the interaction 915 between the IGP and BGP) mechanism for carrying transit traffic 916 across the AS. In this approach, transit traffic is encapsulated 917 within an IP datagram addressed to the exit gateway. The only 918 requirement imposed on the IGP by this approach is that it should be 919 capable of supporting routing between border gateways within the same 920 AS. 922 The address of the exit gateway A for some exterior network X is 923 specified in the BGP identifier field of the BGP OPEN message 924 received from gateway A via Internal BGP by all other border gateways 925 within the same AS. In order to route traffic to network X, each 926 border gateway within the AS encapsulates it in datagrams addressed 927 to gateway A. Gateway A then performs decapsulation and forwards the 928 original packet to the proper gateway in another AS. 930 Since encapsulation does not rely on the IGP to carry exterior 931 routing information, no synchronization between BGP and the IGP is 932 required. 934 Some means of identifying datagrams containing encapsulated IP, such 935 as an IP protocol type code, must be defined if this method is to be 936 used. 938 Note that, if a packet to be encapsulated has length that is very 939 close to the MTU, that packet would be fragmented at the gateway that 940 performs encapsulation. 942 A.2.4 Pervasive BGP 944 If all routers in an AS are BGP speakers, then there is no need to 945 have any interaction between BGP and an IGP. In such cases, all 946 routers in the AS already have full information of all BGP routes. 947 The IGP is then only used for routing within the AS, and no BGP 948 routes are imported into the IGP. 950 For routers to operate in this fashion, they must be able to perform 951 a recursive lookup in their routing table. The first lookup will use 952 a BGP route to establish the exit router, while the second lookup 953 will determine the IGP path to the exit router. 955 Since the IGP carries no external information in this scenario, all 956 routers in the AS will have converged as soon as all BGP speakers 957 have new information about this route. Since there is no need to 958 delay for the IGP to converge, an implementation may advertise these 959 routes without further delay due to the IGP. 961 A.2.5 Other Cases 963 There may be AS's with IGPs which can neither carry BGP information 964 nor tag exterior routes (e.g., RIP). In addition, encapsulation may 965 be either infeasible or undesirable. In such situations, the 966 following two rules must be observed: 968 Information received via Internal BGP by a border gateway A declaring 969 a network to be unreachable must immediately be propagated to all of 970 the External BGP neighbors of A. Information received via Internal 971 BGP by a border gateway A about a reachable network X cannot be 972 propagated to any of the External BGP neighbors of A unless A has an 973 IGP route to X and sufficient time has passed for the IGP routes to 974 have converged. 976 The above rules present necessary (but not sufficient) conditions for 977 propagating BGP routing information to other AS's. In contrast to 978 tagged IGPs, these rules cannot ensure that interior routes to the 979 proper exit gateways are in place before propagating the routes to 980 other AS's. 982 If the convergence time of an IGP is less than some small value X, 983 then the time window during which the IGP and BGP are unsynchronized 984 is less than X as well, and the whole issue can be ignored at the 985 cost of transient periods (of less than length X) of routing 986 instability. A reasonable value for X is a matter for further study, 987 but X should probably be less than one second. 989 If the convergence time of an IGP cannot be ignored, a different 990 approach is needed. Mechanisms and techniques which might be 991 appropriate in this situation are subjects for further study. 993 References 995 [1] Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4), 996 Internet Draft, cisco Systems, T.J. Watson Research Center, IBM 997 Corp., September 1993. 999 [2] Braun, H-W., "Models of Policy Based Routing", RFC 1104, 1000 Merit/NSFNET, June 1989. 1002 [3] Fuller, V., Li, T., Yu, J., Varadhan, K., "Supernetting: an 1003 Address Assignment and Aggregation Strategy", RFC1519, September 1004 1993. 1006 [4] Rekhter, Y., Li, T., "An Architecture for IP address Allocation 1007 with CIDR", RFC1518, September 1993 1009 [5] Rekhter, Y., Topolcic, C. "Exchanging Routing Information Across 1010 Provider/Subscriber Boundaries in the CIDR Environment", RFC1520, 1011 September 1993 1013 [6] ISO/IEC IS 10747 - Information Processing Systems - 1014 Telecommunications and Information Exchange between Systems - 1015 Protocol for Exchange of Inter-domain Routeing Information among 1016 Intermediate Systems to Support Forwarding of ISO 8473 PDUs, 1993. 1018 [7] Hares, S., Scudder, J., "IDRP for IP", Internet Draft, Merit 1019 Network Inc., September 1993. 1021 [8] ISO/IEC JTC 1 "Protocol for Exchanging of Inter-Domain Routeing 1022 Information among Intermediate Systems to Support Forwarding of ISO 1023 8473 PDUs", IS10747 1993 1025 Security Considerations 1027 Security issues are not discussed in this memo. 1029 Authors' Addresses 1031 Yakov Rekhter 1032 T.J. Watson Research Center IBM Corporation 1033 P.O. Box 218 1034 Yorktown Heights, NY 10598 1036 Phone: (914) 945-3896 1037 EMail: yakov@watson.ibm.com 1039 Susan Hares 1040 Merit, Inc 1041 1071 Beal Avenue 1042 Ann Arbor, MI 4810x 1044 Phone: (313)936-2095 1045 Email: skh@merit.edu 1047 IETF BGP WG mailing list: bgp@ans.net 1048 To be added: bgp-request@ans.net 1050 IETF IDRP for IP WG mailing list: idrp-for-ip@merit.edu 1051 To be added: idrp-request@merit.edu