doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

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]
+