From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2519.txt | 731 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 731 insertions(+) create mode 100644 doc/rfc/rfc2519.txt (limited to 'doc/rfc/rfc2519.txt') diff --git a/doc/rfc/rfc2519.txt b/doc/rfc/rfc2519.txt new file mode 100644 index 0000000..3eea39d --- /dev/null +++ b/doc/rfc/rfc2519.txt @@ -0,0 +1,731 @@ + + + + + + +Network Working Group E. Chen +Request for Comments: 2519 Cisco +Category: Informational J. Stewart + Juniper + February 1999 + + + A Framework for Inter-Domain Route Aggregation + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +Abstract + + This document presents a framework for inter-domain route aggregation + and shows an example router configuration which 'implements' this + framework. This framework is flexible and scales well as it + emphasizes the philosophy of aggregation by the source, both within + routing domains as well as towards upstream providers, and it also + strongly encourages the use of the 'no-export' BGP community to + balance the provider-subscriber need for more granular routing + information with the Internet's need for scalable inter-domain + routing. + +1. Introduction + + The need for route aggregation has long been recognized. Route + aggregation is good as it reduces the size, and slows the growth, of + the Internet routing table. Thus, the amount of resources (e.g., CPU + and memory) required to process routing information is reduced and + route calculation is sped up. Another benefit of route aggregation + is that route flaps are limited in number, frequency and scope, which + saves resources and makes the global Internet routing system more + stable. + + Since CIDR (Classless Inter-Domain Routing) [2] was introduced, + significant progress has been made on route aggregation, particularly + in the following two areas: + + - Formulation and implementation of IP address allocation policies + by the top registries that conform to the CIDR principles [1]. + + + +Chen & Stewart Informational [Page 1] + +RFC 2519 Inter-Domain Route Aggregation February 1999 + + + This policy work is the cornerstone which makes efficient route + aggregation technically possible. + + - Route aggregation by large (especially "Tier 1") providers. To + date, the largest reductions in the size of the routing table + have resulted from efficient aggregation by large providers. + + However, the ability of various levels of the global routing system + to implement efficient aggregation schemes varies widely. As a + result, the size and growth rate of the Internet routing table, as + well as the associated route computation required, remain major + issues today. To support Internet growth, it is important to + maximize the efficiency of aggregation at all levels in the routing + system. + + Because of the current size of the routing system and its dynamic + nature, the first step towards this goal is to establish a clearly + defined framework in which scaleable inter-domain route aggregation + can be realized. The framework described in this document is based + on the predominant and current experience in the Internet. It + emphasizes the philosophy of aggregation by the source, both within + routing domains as well as towards upstream providers. The framework + also strongly encourages the use of the "no-export" BGP community to + balance the providersubscriber need for more granular routing + information with the Internet's need for scalable inter-domain + routing. The advantages of this framework include the following: + + - Route aggregation is done in a distributed fashion, with + emphasis on aggregation by the party or parties injecting the + aggregatable routing information into the global mesh. + + - The flexibility of a routing domain to be able to inject more + granular routing information to an adjacent domain to control + the resulting traffic patterns, without having an impact on the + global routing system. + + In addition to describing the philosophy, we illustrate it by + presenting sample configurations. IPv4 prefixes, BGP4 and ASs + are used in examples, though the principles are applicable to + inter-domain route aggregation in general. + + Address allocation policies and technologies to renumber entire + networks, while very relevant to the realization of successful + and sustained inter-domain routing, are not the focus of this + document. The references section contains pointers to relevant + documents [8, 9, 11, 12]. + + + + + +Chen & Stewart Informational [Page 2] + +RFC 2519 Inter-Domain Route Aggregation February 1999 + + +2. Route Aggregation Framework + + The framework of inter-domain route aggregation we are proposing can + be summarized as follows: + + - Aggregation from the originating AS + + That is, in its outbound route announcements, each AS aggregates + the BGP routes originated by itself, by dedicated AS and by + private-ASs [10]. ("Routes originated by an AS" refers to + routes which have that AS first in the AS path attribute. For + example, routes statically configured and injected into BGP fall + into this category.) + + This framework does not depend on "proxy aggregation" which + refers to route aggregation done by an AS other than the + originating AS. This preserves the capability of a multi-homed + site to control the granularity of routing information injected + into the global routing system. Since proxy aggregation involves + coordination among multiple organizations, the complexity of + doing proxy aggregation increases with the number of parties + involved in the coordination. The complexity, in turn, impacts + the practicality of proxy aggregation. + + An AS shall always originate via a stable mechanism (e.g., + static route configuration) the BGP routes for the large + aggregates from which it allocates addresses to customers. This + ensures that it is safe for its customers to use BGP "no- + export". + + - Using BGP community "no-export" toward upstream providers + + That is, in its route announcements toward its upstream + provider, an AS tags the BGP community "no-export" to routes it + originates that do not need to be propagated beyond its upstream + provider (e.g., prefixes allocated by the upstream provider). + + This framework is illustrated in Figure 1. A "Tier 1" provider does + not use "no-export" in its announcement as it does not have an + upstream provider. However, it shall aggregate the routes it + originates in its outbound announcements towards both peer providers + and customers. An AS with an upstream provider shall aggregate the + routes it originates and use "no-export" toward its upstream provider + for routes that do not need to be propagated beyond its provider's + AS. This recursion shall apply to all levels of the routing + hierarchy. + + + + + +Chen & Stewart Informational [Page 3] + +RFC 2519 Inter-Domain Route Aggregation February 1999 + + + Tier 1 + +-- Provider <--+ + | | +o aggregates routes | | o announces customer routes + it originates | | o aggregates routes it originates + | ^ o uses "no-export" if appropriate + | + +---> Tier 2 <--+ + Provider | + V | + | | +o aggregates routes | | o announces customer routes + it originates | | o aggregates routes it originates + | | o uses "no-export" if appropriate + | | + | ^ + -> Customer AS + + + Figure 1 + + This framework scales well as aggregation is done at all levels of + the routing system. It is flexible because the originating AS + controls whether routes of finer granularity are injected to, and/or + propagated by, its upstream provider. It facilitates multi-homing + without compromising route aggregation. + + This framework is detailed in the following sections. + +3. Aggregation from the Originating AS + + It has been well recognized that address allocation and address + renumbering are keys to containing the growth of the Internet routing + table [1, 2, 8, 9, 11, 12]. + + Although the strategies discussed in this document do not assume a + perfect address allocation, it is strongly urged that an AS receive + allocation from its upstream service providers' address block. + +3.1 Intra-Domain Aggregation + + To reduce the number of routes that need to be injected into an AS, + there are a couple of principles that shall be followed: + + + + + + + + +Chen & Stewart Informational [Page 4] + +RFC 2519 Inter-Domain Route Aggregation February 1999 + + + - Carry in its BGP table the large route block allocated from its + upstream provider or an address registry (e.g., InterNIC, RIPE, + APNIC). This can be done by either static configuration of the + large block or by aggregating more specific BGP routes. The + former is recommended as it does not depend on other routes. + + - Allocate sub-blocks to the access routers where further + allocation is done. That is, the address allocation shall be + done such that only a few, less specific routes (instead of many + more, specific ones) need to be known to the other routers + within the AS. + + For example, a prefix of /17 can be further allocated to + different access routers as /20s which can then be allocated to + customers connected to different interfaces on that router (as + shown in Figure 2). Then in general only the /20 needs to be + injected into the whole AS. Exceptions need to be made for + multi-homed static routes. + + access router + +------------+ + | x.x.x.x/20 | + +------------+ + | | | + | | | + /24 /22 /25 + + + Figure 2 + + It is noted that rehoming of customers without renumbering even + within the same AS may lead to injection of more specific routes. + However, in general the more-specifics do not need to be advertised + outside of that AS. Such routes can either be tagged with the BGP + community "no-export" or filtered out by a prefix-based filter to + prevent them from being advertised out. + +3.2 Inter-Domain Aggregation + + There are at least two types of routes that need to be advertised by + an AS: routes originated by the AS and routes originated by its BGP + customers. An AS may need to advertise full routes to certain BGP + customers, in which case the routing announcements include routes + originated by non-customer ASs. Clearly an AS can, and should, + safely aggregate the routes originated by itself and by its BGP + customers multi-homed only to it (using, e.g., the dedicated-AS and + + + + + +Chen & Stewart Informational [Page 5] + +RFC 2519 Inter-Domain Route Aggregation February 1999 + + + by the private-AS mechanism [10]) in its outbound announcement. But + it is far more dangerous to aggregate routes originated by customer + ASs due to multi-homing. + + However, there are several cases in which a route originated by a BGP + customer (other than using the dedicated AS or private AS) does not + need to be advertised out by its upstream providers. For example, + + - The route is a more-specific of the upstream provider's block. + However, the customer is either singly homed; or its connection + to this particular upstream provider is used for backup only. + + - The more-specifics of a larger block are announced by the + customer in order to balance traffic over the multiple links to + the upstream provider. + + Our approach to suppress such routes is to give control to the ASs + that originate the more-specifics (as seen by its upstream providers) + and let them tag the BGP community "no-export" to the appropriate + routes. + + The BGP community "no-export" is a well known BGP community [6, 7]. + A route with this attribute is not propagated beyond an AS boundary. + So, if a route is tagged with this community in its announcement to + an upstream provider and is accepted by the upstream provider, the + route will not be announced beyond the upstream provider's AS. This + achieves the goal of suppressing the more-specifics in the upstream + provider's outbound announcement. + + In this framework, the BGP community "no-export" shall be tagged to + routes that are to be advertized to, but not propagated by, its + upstream provider. They may include routes allocated out of its + upstream provider's block or the more specific routes announced to + its upstream provider for the purpose of load balancing. This + aggregation strategy can be implemented via prefix-based filtering as + shown in the example of Section 5. + + For its own protection, a downstream AS shall announce only its own + routes and its customer routes to its upstream providers. Thus, the + outbound routing announcement and aggregation policy can be expressed + as follows: + + For routes originated by itself/dedicated-AS/private-AS: + tag with "no-export" when appropriate, and advertise the + large block and suppress the more-specifics + + For routes originated by customer ASs: + advertise to upstream ASs + + + +Chen & Stewart Informational [Page 6] + +RFC 2519 Inter-Domain Route Aggregation February 1999 + + + For any other routes: + do not advertise to upstream ASs + + This approach is flexible and scales well as it gives control to the + party with the special needs, distributes the workload and avoids the + coordination overhead required by proxy aggregation. + +4. Aggregation by a Provider + + A provider shall aggregate all the routes it originates, as + documented in Section 3. The only difference is that the provider + may be providing full routes to certain BGP customers where no + outbound filtering is presently in place. Experience has shown that + inconsistent route announcement (e.g., aggregate at the interconnects + but not toward certain customers) can cause serious routing problems + for the Internet as a whole because of longest-match routing. In + certain cases announcing the more-specifics to customers might + provide for more accurate IGP metrics and could be useful for better + load-balancing. However, the potential risk seems to outweigh the + benefit, especially given the increasing complexity of connectivity + that a customer may have. As a result, every effort shall be made to + ensure consistent route aggregation for all BGP peers. This means + deploying filters for the BGP peers which receive full routes. + + In summary, the aggregation strategy for a provider shall be: + + - In announcing customer routes: + + For routes originated by itself/dedicated-AS/private-AS: + tag with "no-export" when appropriate, and advertise the + large block and suppress the more-specifics + + For routes originated by other customer ASs: + advertise + + For any other routes: + do not advertise + + - In announcing full routes: + + For routes originated by itself/dedicated-AS/private-AS: + tag with "no-export" when appropriate, and advertise the + large block and suppress the more-specifics + + For any other routes: + advertise + + + + + +Chen & Stewart Informational [Page 7] + +RFC 2519 Inter-Domain Route Aggregation February 1999 + + +5. An Example + + Consider the example shown in Figure 3 where AS 1000 is a "Tier 1" + provider with two large aggregates 208.128.0.0/12 and 166.55.0.0/16, + and AS 2000 is a customer of AS 1000 with a "portable address" + 160.75.0.0/16 and an address 208.128.0.0/19 allocated from AS 1000. + Assume that 208.128.0.0/19 does not need to be propagated beyond AS + 1000. + + +----------------+ + | AS 1000 | + | 208.128.0.0/12 | + | 166.55.0.0/16 | + +----------------+ + | + | BGP + | + | + +----------------+ + | AS 2000 | + | 208.128.0.0/19 | + | 160.75.0.0/16 | + +----------------+ + + Figure 3 + + Then, based on the framework presented, AS 1000 would + + - originate and advertise the BGP routes 208.128.0.0/12 and + 166.55.0.0/16, and suppress more-specifics originated by + itself/private-ASs/dedicated-ASs + + - advertise the routes received from the customer AS 2000 + + and AS 2000 would + + - originate BGP route 208.128.0.0/19 and 160.75.0.0/16 + + - advertise both 160.75.0.0/16 and 208.128.0.0/19 to its provider + AS 1000 and suppress the more specifics originated by + itself/private-AS/dedicated-AS, tagging the route 208.128.0.0/19 + with "no-export" + + - advertise both 160.75.0.0/16 and 208.128.0.0/19 to its BGP + customers (if any) and suppress the more-specifics originated by + itself/private-AS/dedicated-AS, plus any other routes the + customers may desire to receive + + + + +Chen & Stewart Informational [Page 8] + +RFC 2519 Inter-Domain Route Aggregation February 1999 + + + The sample configuration which implement these policies (in Cisco + syntax) is given in Appendix A. + +6. Acknowledgments + + The authors would like to thank Roy Alcala of MCI for a number of + interesting hallway discussions related to this work. The IETF's IDR + Working Group also provided many helpful comments and suggestions. + +7. References + + [1] Rekhter, Y. and T. Li, "An Architecture for IP Address Allocation + with CIDR", RFC 1518, September 1993. + + [2] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter- + Domain Routing (CIDR): an Address Assignment and Aggregation + Strategy", RFC 1519, September 1993. + + [3] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", + RFC 1771, March 1995. + + [4] Rekhter, Y. and P., Gross, "Application of the Border Gateway + Protocol in the Internet", RFC 1772, March 1995. + + [5] Rekhter, Y., "Routing in a Multi-provider Internet", RFC 1787, + April 1995. + + [6] Chandra, R., Traina, P. and T. Li, "BGP Communities Attribute", + RFC 1997, August 1996. + + [7] Chen, E. and T. Bates, "An Application of the BGP Community + Attribute in Multi-home Routing", RFC 1998, August 1996. + + [8] Ferguson, P. and H. Berkowitz, "Network Renumbering Overview: Why + would I want it and what is it anyway?", RFC 2071, January 1997. + + [9] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January + 1997. + + [10] Stewart, J., Bates, T., Chandra, R., and Chen, E., "Using a + Dedicated AS for Sites Homed to a Single Provider", RFC 2270, + January 1998. + + [11] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address + Behaviour Today", RFC 2101, February 1997. + + [12] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC + 1900, February 1996. + + + +Chen & Stewart Informational [Page 9] + +RFC 2519 Inter-Domain Route Aggregation February 1999 + + + [13] Cisco systems, Cisco IOS Software Version 10.3 Router Products + Configuration Guide (Addendum), May 1995. + +8. Authors' Addresses + + Enke Chen + Cisco Systems + 170 West Tasman Drive + San Jose, CA 95134-1706 + + Phone: +1 408 527 4652 + EMail: enkechen@cisco.com + + + John W. Stewart, III + Juniper Networks, Inc. + 385 Ravendale Drive + Mountain View, CA 94043 + + Phone: +1 650 526 8000 + EMail: jstewart@juniper.net + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Chen & Stewart Informational [Page 10] + +RFC 2519 Inter-Domain Route Aggregation February 1999 + + +A. Appendix A: Example Cisco Configuration + + This appendix lists the Cisco configurations for AS 2000 of the + examples presented in Section 5. The configuration here uses the + AS-path for outbound filtering although it can also be based on BGP + community. Several route-maps are defined that can be used for + peering with the upstream provider, and for peering with customers + (announcing full routes or customer routes). + +!!# inject aggregates +ip route 160.75.0.0 255.255.0.0 Null0 254 +ip route 208.128.0.0 255.255.224.0 Null0 254 +! +router bgp 2000 +network 160.75.0.0 mask 255.255.0.0 +network 208.128.0.0 mask 255.255.224.0 +neighbor x.x.x.x remote-as 1000 +neighbor x.x.x.x route-map export-routes-to-provider out +neighbor x.x.x.x send-community +! +!!# match all +ip as-path access-list 1 permit .* +! +!!# List of internal AS and private ASs that are safe to aggregate +ip as-path access-list 10 permit ^$ +ip as-path access-list 10 permit ^64999_ +ip as-path access-list 10 deny .* +! +!!# list of other customer ASs +ip as-path access-list 20 permit ^3000_ + +!!# List of prefixes to be tagged with "no-export" +access-list 101 permit ip 208.128.0.0 0.0.0.0 255.255.224.0 0.0.0.0 +!!# Filter out the more specifics of large aggregates, and permit the rest +access-list 102 permit ip 160.75.0.0 0.0.0.0 255.255.0.0 0.0.0.0 +access-list 102 deny ip 160.75.0.0 0.0.255.255 255.255.128.0 0.0.127.255 +access-list 102 permit ip 208.128.0.0 0.0.0.0 255.255.224.0 0.0.0.0 +access-list 102 deny ip 208.128.0.0 0.0.31.255 255.255.240.0 0.0.16.255 +access-list 102 permit ip any any +! + +!!# route-map with the upstream provider +route-map export-routes-to-provider permit 10 +match ip address 101 +set community no-export +route-map export-routes-to-provider permit 20 +match as-path 10 +match ip address 102 + + + +Chen & Stewart Informational [Page 11] + +RFC 2519 Inter-Domain Route Aggregation February 1999 + + +route-map export-routes-to-provider permit 30 +match as-path 20 +! +!!# route-map with BGP customers that desire only customer routes +route-map export-customer-routes permit 10 +match as-path 10 +match ip address 102 +route-map export-customer-routes permit 20 +match as-path 20 +! +!!# route-map with BGP customers that desire full routes +route-map export-full-routes permit 10 +match as-path 10 +match ip address 102 +route-map export-full-routes permit 20 +match as-path 1 +! + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Chen & Stewart Informational [Page 12] + +RFC 2519 Inter-Domain Route Aggregation February 1999 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Chen & Stewart Informational [Page 13] + -- cgit v1.2.3