doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc1998.txt b/doc/rfc/rfc1998.txt
new file mode 100644
index 0000000..4a6254d
--- /dev/null
+++ b/doc/rfc/rfc1998.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                            E. Chen
+Request for Comments: 1998                                           MCI
+Category: Informational                                         T. Bates
+                                                           cisco Systems
+                                                             August 1996
+
+
+             An Application of the BGP Community Attribute
+                         in Multi-home Routing
+
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   This document presents an application of the BGP community attribute
+   [2] in simplifying the implementation and configuration of routing
+   policies in the multi-provider Internet. It shows how the community
+   based configuration can be used to replace the AS-based customization
+   of the BGP "LOCAL_PREF" attribute, a common method used today.  Not
+   only does the technique presented simplifies configuration and
+   management at the provider level, it also represents a paradigm shift
+   in that it gives the potential for the customer to control its own
+   routing policy with respect to its service provider, as well as
+   providing the ability for policy configuration to be done at a prefix
+   based granularity rather than the more common AS based granularity.
+
+1. Introduction
+
+   In the multi-provider Internet, it is common for a service subscriber
+   (i.e., customer) to have more than one service provider, or to have
+   arrangements for redundant connectivity to the global connected
+   Internet. As discussed in [3], routing strategies in these cases
+   usually require coordination between the service subscriber and its
+   providers, which typically leads to customization of router
+   configurations (e.g., BGP "LOCAL_PREF") not only by the subscriber,
+   but also by its providers.  Due to the large number of customers a
+   provider serves, customization of router configurations at the
+   provider level may present management and scalability problems.
+
+   This document presents an application of the BGP community attribute
+   in simplifying the implementation of routing strategies in the
+   multi-provider Internet.  More specifically, the technique presented
+   uses a community-based, rather than the common AS-based,
+
+
+
+Chen & Bates                 Informational                      [Page 1]
+
+RFC 1998                    Use of Community                 August 1996
+
+
+   configuration of the BGP "LOCAL_PREF". It essentially removes the
+   need for customized configuration of the BGP "LOCAL_PREF" attribute
+   at the provider level while maintaining the same level of routing
+   functionality and flexibility.
+
+   It also represents a paradigm shift in that it gives the potential
+   for the customer to control its own routing policy with respect to
+   its service provider, as well as providing the ability for policy
+   configuration to be done at a prefix based granularity rather than
+   the more common AS based granularity in use today.
+
+2. AS-based Configuration and its Drawbacks
+
+   As discussed in [3], in today's multi-provider Internet, customized
+   configuration of the BGP "LOCAL_PREF" attribute is often required to
+   implement common routing strategies such as load-sharing or backup.
+   There are two main reasons:
+
+     o Lack of available implementations and deployment of routing
+       software that supports the "Destination Preference Attribute"
+       (DPA) as specified in [4].
+
+       DPA allows one to specify a globally transitive preference so
+       that return traffic favors certain path. As discussed in [3],
+       the attribute will be very useful in influencing route selection
+       for routes with identical "LOCAL_PREF" and equal AS-path length.
+
+     o In the multi-provider Internet, it is common for a provider
+       to assign higher BGP "LOCAL_PREF" values for routes from its
+       customers than from other service providers. This practice
+       provides some degree of protection for its customer routes,
+       and it facilitates implementation of certain routing
+       strategies.  It, however, also complicates other routing
+       implementations such as backup arrangement, thus, requiring
+       customized "LOCAL_PREF" configuration.
+
+   Figure 1 shows a typical case of a backup arrangement in the multi-
+   provider Internet. In Figure 1, AS1 and AS2 are both providers, and
+   AS3 and AS4 are customers of AS1 and AS2, respectively. AS3 has
+   entered a bilateral agreement with AS4 to provide backup to each
+   other.  That is, AS3 would use its direct link to AS4 to reach only
+   AS4 in the normal circumstance, and for transit in the case of a
+   failure between AS3 and AS1.  To realize this routing agreement, AS3
+   requests that its provider AS1 adjust its BGP "LOCAL_PREF"
+   configuration so that AS1 reaches AS4 via AS2.
+
+
+
+
+
+
+Chen & Bates                 Informational                      [Page 2]
+
+RFC 1998                    Use of Community                 August 1996
+
+
+                          +------+      +------+
+                          | AS1  |------| AS2  |
+                          +------+      +------+
+                             |             |
+                          +------+      +------+
+                          | AS3  |------|  AS4 |
+                          +------+      +------+
+
+                     Figure 1: Typical Backup Scenario
+
+
+   Primarily due to scalability and management concerns, most providers
+   only perform "LOCAL_PREF" customization based on ASs, not on IP
+   prefixes.  If IP prefix-based "LOCAL_PREF" configuration is needed, a
+   technique known as as the BGP AS-path manipulation can be used.
+   However, it is currently only available in certain vendor's products.
+
+   There are several drawbacks with the the practice of AS-based BGP
+   "LOCAL_PREF" configuration at the provider level:
+
+      o The implementation tends to less efficient due to the process
+        of coordination and configuration.  More importantly, the
+        process needs to be repeated each time a change (e.g., adding
+        a new AS) occurs.
+
+      o The AS-based customization complicates router configuration
+        and increases complexity of network operation. It has become
+        a serious scalability issue for providers.
+
+      o It can not implement prefix-based configuration without the
+        AS-path manipulation (i.e., using fake AS).
+
+      o Keeping configuration up-to-date is some times problematic.
+
+3. How the BGP Community Attribute Can Help
+
+3.1 Overview of the Community Attribute
+
+   The BGP community path attribute is an optional transitive attribute
+   of variable length [1,2]. The attribute consists of a set of four
+   octet values, each of which specify a community.  The community
+   attribute values are encoded using an AS number in the first two
+   octets, with the remaining two octets defined by the AS. As defined
+   in [2], a community is a group of destinations (i.e. prefixes) that
+   share some common attribute.  Each destination can belong to multiple
+   communities.  All prefixes with the community attribute belong to the
+   communities listed in the attribute.
+
+
+
+
+Chen & Bates                 Informational                      [Page 3]
+
+RFC 1998                    Use of Community                 August 1996
+
+
+   The BGP community  allows one to group a set of prefixes and perform
+   routing decisions based on the identity of the group.
+
+   The well-known communities NO_EXPORT (0xFFFFFF01) and NO_ADVERTISE
+   (0xFFFFFF02) are intuitive,  and can be used for optimizing routing
+   and for improving route aggregation.
+
+3.2 Community-based Configuration
+
+   With the BGP community attribute [2], a provider can now use
+   community-based, rather than AS-based, configuration of BGP
+   "LOCAL_PREF".  The provider first needs to coordinate with its
+   customers a set of communities to be mapped to certain BGP
+   "LOCAL_PREF" values.  The provider can then apply a uniform BGP
+   configuration to all its customers that would capture routes with the
+   community values, and set up the appropriate BGP "LOCAL_PREF" values
+   accordingly.  A customer that requires customization in its provider
+   BGP "LOCAL_PREF" configuration can simply send the appropriate
+   community values in its routing announcements.
+
+   The major advantages of using this technique include:
+
+      o The customer has full control in the process, which makes a
+        lot of sense as the customer is in a position to have better
+        understanding about its own topology and routing policy
+        requirement.
+
+      o The effect of route-based customization in BGP "LOCAL_PREF"
+        configuration by providers can now be achieved, thus, removing
+        the need of AS-Path manipulation in certain cases.
+
+      o It addresses the scalability issue facing providers as it
+        distributes the configuration work to the customer that
+        requires customization.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chen & Bates                 Informational                      [Page 4]
+
+RFC 1998                    Use of Community                 August 1996
+
+
+4. A Real-World Implementation Example
+
+   MCI currently makes heavy use of the BGP "LOCAL_PREF" attribute value
+   as part of its routing policy configuration process.  Different BGP
+   "LOCAL_PREF" values are assigned for routes from different sources.
+   Table 1 details these values:
+
+
+                  +-------------------------+------------+
+                  |        Category         | LOCAL_PREF |
+                  +-------------------------+------------+
+                  |Customer Routes          |        100 |
+                  |Customer backup Routes   |         90 |
+                  |Other ISP Routes         |         80 |
+                  |Customer-Provided backup |         70 |
+                  +-------------------------+------------+
+
+                    Table 1: Defined LOCAL_PREF Values
+
+
+   Note:
+
+       o The value '100' is the default value used within our network
+         configuration.
+
+       o In most cases, the MED attribute set by a customer is
+         sufficient for customer backup routes (e.g., T1 backs up T3).
+         However, in certain cases configuration of "LOCAL_PREF" will
+         still be necessary until the BGP DPA attribute is available.
+
+
+   To make use of the BGP community attribute, several community values
+   (MCI's AS number: 3561 = 0x0DE9) have been defined that can be used
+   by customers to tag routes so that the appropriate "LOCAL_PREF"
+   values are configured. Table 2 lists the appropriate community
+   attribute values (and the mappings of community to LOCAL_PREF):
+
+                    +---------------------+------------+
+                    |     community       | LOCAL_PREF |
+                    +---------------------+------------+
+                    |3561:70 (0x0DE90046) |         70 |
+                    |3561:80 (0x0DE90050) |         80 |
+                    |3561:90 (0x0DE9005A) |         90 |
+                    +---------------------+------------+
+
+                 Table 2: Community to LOCAL_PREF Mapping
+
+
+
+
+
+Chen & Bates                 Informational                      [Page 5]
+
+RFC 1998                    Use of Community                 August 1996
+
+
+   A customer requiring MCI to configure BGP "LOCAL_PREF" values other
+   than the default can tag their routes with the defined communities.
+   The community values can be configured either based on an AS path
+   list or an IP address access list. A cisco systems software specific
+   configuration example is given in Appendix A to show how this can be
+   achieved.
+
+   A uniform BGP configuration (see Appendix B, again cisco systems
+   software specific) is applied by MCI to peers with customers that
+   configure the appropriate "LOCAL_PREF" values based on the
+   communities received.
+
+   This technique has been tested and is in use with several customers,
+   and the response has been very positive. We are in the process of
+   migrating all other customized BGP "LOCAL_PREF" configurations to
+   this uniform community based configuration approach.
+
+5. References
+
+   [1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)",
+       RFC 1771, March 1995.
+
+   [2] Chandra, R., Traina, P., and T. Li, "BGP Communities
+       Attribute", RFC 1997, August 1996.
+
+   [3] Chen, E., and T. Bates, "Current Practice of Implementing
+       Symmetric Routing and Load Sharing in the Multi-Provider
+       Internet", Work in Progress.
+
+   [4] Chen, E., and T. Bates, "Destination Preference Attribute for
+       BGP", Work in Progress.
+
+   [5] Chen, E., and T. Bates, "Application of the BGP Destination
+       Preference Attribute in Implementing Symmetric Routing",
+       Work in Progress.
+
+   [6] cisco systems, cisco IOS Software Version 10.3 Router Products
+       Configuration Guide (Addendum), May 1995.
+
+6. Security Considerations
+
+   Security issues are not discussed in this memo.
+
+7. Acknowledgments
+
+   The authors would specifically like to thank Ravi Chandra, Tony Li
+   and Paul Traina of cisco systems for devising and implementing the
+   community attribute.
+
+
+
+Chen & Bates                 Informational                      [Page 6]
+
+RFC 1998                    Use of Community                 August 1996
+
+
+8. Authors' Addresses
+
+   Enke Chen
+   MCI
+   2100 Reston Parkway
+   Reston, VA 22091
+
+   Phone: +1 703 715 7087
+   EMail: enke@mci.net
+
+
+   Tony Bates
+   cisco Systems
+   170 West Tasman Drive
+   San Jose, CA 95134
+
+   Phone: +1 408 527 2470
+   EMail: tbates@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chen & Bates                 Informational                      [Page 7]
+
+RFC 1998                    Use of Community                 August 1996
+
+
+Appendix
+
+   These appendices list cisco systems software specific configuration
+   examples for configuring communities, and for uniform route-map
+   definition that sets up the appropriate "LOCAL_PREF" values based on
+   the corresponding community values. These examples are given purely
+   to show a working example of how the desired effect discussed in this
+   document can be achieved. Please refer to [6] for more specific
+   information on cisco configuration and syntax.
+
+Appendix A. Community Configuration
+
+   The community values can be configured either based upon an AS path
+   list or based an IP address access list. Here is an example that
+   includes both cases:
+
+   !!
+   router bgp xxxx
+   neighbor x.x.x.x remote-as 3561
+   neighbor x.x.x.x filter-list 20 out
+   neighbor x.x.x.x route-map config-community out
+   neighbor x.x.x.x send-community
+   !
+   !!# match all
+   ip as-path access-list 1 permit .*
+   !
+   !!# list of customer ASs
+   ip as-path access-list 20 permit ^$
+   ip as-path access-list 20 permit ^64700_
+   ip as-path access-list 20 deny .*
+   !
+   !!# AS path based matching, backup for another ISPs customer
+   ip as-path access-list 40 permit _64710_
+   ip as-path access-list 40 permit _64711_
+   ip as-path access-list 40 deny .*
+   !
+   !!# route-map
+   route-map config-community permit 10
+   match as-path 40
+   set community 0x0DE90046
+   route-map config-community permit 20
+   match as-path 1
+   !
+
+
+
+
+
+
+
+
+Chen & Bates                 Informational                      [Page 8]
+
+RFC 1998                    Use of Community                 August 1996
+
+
+   Note: The community can also be configured based on IP prefixes
+   instead of AS numbers.  For example,
+
+   !
+   access-list 101 permit ip 192.160.154.0 0.0.0.0 255.255.255.0 0.0.0.0
+   !
+   route-map config-community permit 10
+   match ip address 101
+   set community 0x0DE90046
+   route-map config-community permit 20
+   match as-path 1
+   !
+
+Appendix B. Uniform Route-map Configuration
+
+   Here is the uniform route-map that can be used for all BGP
+   customers:
+
+   !!# routes primary via another ISP
+   ip community-list 70 permit 0x0DE90046
+   ip community-list 70 deny
+   !
+   !!# routes also homed to another ISP, but with DPA or
+   !!# AS-path length as the tie-breaker
+   ip community-list 80 permit 0x0DE90050
+   ip community-list 80 deny
+   !
+   !!# customer backup routes
+   ip community-list 90 permit 0x0DE9005A
+   ip community-list 90 deny
+   !
+   !!# the route-map applied to BGP customers
+   route-map set-customer-local-pref permit 10
+   match community 70
+   set local-preference 70
+   route-map set-customer-local-pref permit 20
+   match community 80
+   set local-preference 80
+   route-map set-customer-local-pref permit 30
+   match community 90
+   set local-preference 90
+   route-map set-customer-local-pref permit 40
+   match as-path 1
+   set local-preference 100
+   !
+
+
+
+
+
+
+Chen & Bates                 Informational                      [Page 9]
+