draft-ietf-idr-community-usage-00.txt   rfc1998.txt 
INTERNET-DRAFT Enke Chen Network Working Group E. Chen
<draft-ietf-idr-community-usage-00.txt> Tony Bates Request for Comments: 1998 MCI
MCI Category: Informational T. Bates
March 1996 cisco Systems
August 1996
An Application of the BGP Community Attribute
in Multi-home Routing
<draft-ietf-idr-community-usage-00.txt>
Status of this Memo
This document is an Internet Draft. Internet Drafts are working An Application of the BGP Community Attribute
documents of the Internet Engineering Task Force (IETF), its Areas, in Multi-home Routing
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six Status of This Memo
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress".
Please check the I-D abstract listing contained in each Internet This memo provides information for the Internet community. This memo
Draft directory to learn the current status of this or any other does not specify an Internet standard of any kind. Distribution of
Internet Draft. this memo is unlimited.
Abstract Abstract
This document presents an application of the BGP community attribute This document presents an application of the BGP community attribute
[2] in simplifying the implementation and configuration of routing [2] in simplifying the implementation and configuration of routing
policies in the multi-provider Internet. It shows how the community policies in the multi-provider Internet. It shows how the community
based configuration can be used to replace the AS-based customization based configuration can be used to replace the AS-based customization
of the BGP "LOCAL_PREF" attribute, a common method used today. Not of the BGP "LOCAL_PREF" attribute, a common method used today. Not
only does the technique presented simplifies configuration and only does the technique presented simplifies configuration and
management at the provider level, it also represents a paradigm shift management at the provider level, it also represents a paradigm shift
skipping to change at page 2, line 19 skipping to change at page 1, line 46
arrangements for redundant connectivity to the global connected arrangements for redundant connectivity to the global connected
Internet. As discussed in [3], routing strategies in these cases Internet. As discussed in [3], routing strategies in these cases
usually require coordination between the service subscriber and its usually require coordination between the service subscriber and its
providers, which typically leads to customization of router providers, which typically leads to customization of router
configurations (e.g., BGP "LOCAL_PREF") not only by the subscriber, configurations (e.g., BGP "LOCAL_PREF") not only by the subscriber,
but also by its providers. Due to the large number of customers a but also by its providers. Due to the large number of customers a
provider serves, customization of router configurations at the provider serves, customization of router configurations at the
provider level may present management and scalability problems. provider level may present management and scalability problems.
This document presents an application of the BGP community attribute This document presents an application of the BGP community attribute
in simplifying the implementation of routing strategies in the multi- in simplifying the implementation of routing strategies in the
provider Internet. More specifically, the technique presented uses a multi-provider Internet. More specifically, the technique presented
community-based, rather than the common AS-based, configuration of uses a community-based, rather than the common AS-based,
the BGP "LOCAL_PREF". It essentially removes the need for customized configuration of the BGP "LOCAL_PREF". It essentially removes the
configuration of the BGP "LOCAL_PREF" attribute at the provider level need for customized configuration of the BGP "LOCAL_PREF" attribute
while maintaining the same level of routing functionality and at the provider level while maintaining the same level of routing
flexibility. functionality and flexibility.
It also represents a paradigm shift in that it gives the potential It also represents a paradigm shift in that it gives the potential
for the customer to control its own routing policy with respect to for the customer to control its own routing policy with respect to
its service provider, as well as providing the ability for policy its service provider, as well as providing the ability for policy
configuration to be done at a prefix based granularity rather than configuration to be done at a prefix based granularity rather than
the more common AS based granularity in use today. the more common AS based granularity in use today.
2. AS-based Configuration and its Drawbacks 2. AS-based Configuration and its Drawbacks
As discussed in [3], in today's multi-provider Internet, customized As discussed in [3], in today's multi-provider Internet, customized
skipping to change at page 5, line 43 skipping to change at page 5, line 35
o The value '100' is the default value used within our network o The value '100' is the default value used within our network
configuration. configuration.
o In most cases, the MED attribute set by a customer is o In most cases, the MED attribute set by a customer is
sufficient for customer backup routes (e.g., T1 backs up T3). sufficient for customer backup routes (e.g., T1 backs up T3).
However, in certain cases configuration of "LOCAL_PREF" will However, in certain cases configuration of "LOCAL_PREF" will
still be necessary until the BGP DPA attribute is available. still be necessary until the BGP DPA attribute is available.
To make use of the BGP community attribute, several community values To make use of the BGP community attribute, several community values
(MCI's AS number: 3561 = 0x0DE9) have been defined that can be used (MCI's AS number: 3561 = 0x0DE9) have been defined that can be used
by customers to tag routes so that the appropriate "LOCAL_PREF" val- by customers to tag routes so that the appropriate "LOCAL_PREF"
ues are configured. Table 2 lists the appropriate community attribute values are configured. Table 2 lists the appropriate community
values (and the mappings of community to LOCAL_PREF): attribute values (and the mappings of community to LOCAL_PREF):
+---------------------+------------+ +---------------------+------------+
| community | LOCAL_PREF | | community | LOCAL_PREF |
+---------------------+------------+ +---------------------+------------+
|3561:70 (0x0DE90046) | 70 | |3561:70 (0x0DE90046) | 70 |
|3561:80 (0x0DE90050) | 80 | |3561:80 (0x0DE90050) | 80 |
|3561:90 (0x0DE9005A) | 90 | |3561:90 (0x0DE9005A) | 90 |
+---------------------+------------+ +---------------------+------------+
Table 2: Community to LOCAL_PREF Mapping Table 2: Community to LOCAL_PREF Mapping
A customer requiring MCI to configure BGP "LOCAL_PREF" values other A customer requiring MCI to configure BGP "LOCAL_PREF" values other
than the default can tag their routes with the defined communities. than the default can tag their routes with the defined communities.
The community values can be configured either based on an AS path The community values can be configured either based on an AS path
list or an IP address access list. A cisco systems software specific 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 configuration example is given in Appendix A to show how this can be
achieved. achieved.
A uniform BGP configuration (see Appendix B, again cisco systems A uniform BGP configuration (see Appendix B, again cisco systems
software specific) is applied by MCI to peers with customers that software specific) is applied by MCI to peers with customers that
configure the appropriate "LOCAL_PREF" values based on the communi- configure the appropriate "LOCAL_PREF" values based on the
ties received. communities received.
This technique has been tested and is in use with several customers, 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 and the response has been very positive. We are in the process of
migrating all other customized BGP "LOCAL_PREF" configurations to migrating all other customized BGP "LOCAL_PREF" configurations to
this uniform community based configuration approach. this uniform community based configuration approach.
5. References 5. References
[1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", [1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)",
RFC1771, March 1995. RFC 1771, March 1995.
[2] Chandra, R., Traina, P., and Li, T., "BGP Communities Attribute", [2] Chandra, R., Traina, P., and T. Li, "BGP Communities
INTERNET-DRAFT, <draft-chandra-bgp-communities-00.txt>, April 1995. Attribute", RFC 1997, August 1996.
[3] Chen, E., and Bates, T., "Current Practice of Implementing Sym- [3] Chen, E., and T. Bates, "Current Practice of Implementing
metric Routing and Load Sharing in the Multi-Provider Internet", Symmetric Routing and Load Sharing in the Multi-Provider
INTERNET-DRAFT, <draft-ietf-idr-symm-multi-prov-02.txt>, January Internet", Work in Progress.
1996.
[4] Chen, E., and Bates, T., "Destination Preference Attribute for [4] Chen, E., and T. Bates, "Destination Preference Attribute for
BGP", INTERNET-DRAFT, <draft-ietf-idr-bgp-dpa-05.txt>, February 1996. BGP", Work in Progress.
[5] Chen, E., and Bates, T., "Application of the BGP Destination [5] Chen, E., and T. Bates, "Application of the BGP Destination
Preference Attribute in Implementing Symmetric Routing", INTERNET- Preference Attribute in Implementing Symmetric Routing",
DRAFT, <draft-ietf-idr-dpa-application-02.txt>, January 1996. Work in Progress.
[6] cisco systems, cisco IOS Software Version 10.3 Router Products [6] cisco systems, cisco IOS Software Version 10.3 Router Products
Configuration Guide (Addendum), May 1995. Configuration Guide (Addendum), May 1995.
6. Security Considerations 6. Security Considerations
Security considerations are not discussed in this memo. Security issues are not discussed in this memo.
7. Acknowledgments 7. Acknowledgments
The authors would specifically like to thank Ravi Chandra, Tony Li The authors would specifically like to thank Ravi Chandra, Tony Li
and Paul Traina of cisco systems for devising and implementing the and Paul Traina of cisco systems for devising and implementing the
community attribute. community attribute.
8. Author's Addresses 8. Authors' Addresses
Enke Chen Enke Chen
MCI MCI
2100 Reston Parkway 2100 Reston Parkway
Reston, VA 22091 Reston, VA 22091
phone: +1 703 715 7087 Phone: +1 703 715 7087
email: enke@mci.net EMail: enke@mci.net
Tony Bates Tony Bates
MCI cisco Systems
2100 Reston Parkway 170 West Tasman Drive
Reston, VA 22091 San Jose, CA 95134
phone: +1 703 715 7521 Phone: +1 408 527 2470
email: Tony.Bates@mci.net EMail: tbates@cisco.com
Appendix Appendix
These appendices list cisco systems software specific configuration These appendices list cisco systems software specific configuration
examples for configuring communities, and for uniform route-map defi- examples for configuring communities, and for uniform route-map
nition that sets up the appropriate "LOCAL_PREF" values based on the definition that sets up the appropriate "LOCAL_PREF" values based on
corresponding community values. These examples are given purely to the corresponding community values. These examples are given purely
show a working example of how the desired effect discussed in this to show a working example of how the desired effect discussed in this
document can be achieved. Please refer to [6] for more specific document can be achieved. Please refer to [6] for more specific
information on cisco configuration and syntax. information on cisco configuration and syntax.
Appendix A. community Configuration Appendix A. Community Configuration
The community values can be configured either based upon an AS path 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 list or based an IP address access list. Here is an example that
includes both cases: includes both cases:
!! !!
router bgp xxxx router bgp xxxx
neighbor x.x.x.x remote-as 3561 neighbor x.x.x.x remote-as 3561
neighbor x.x.x.x filter-list 20 out neighbor x.x.x.x filter-list 20 out
neighbor x.x.x.x route-map config-community out neighbor x.x.x.x route-map config-community out
skipping to change at page 9, line 19 skipping to change at page 9, line 19
! !
route-map config-community permit 10 route-map config-community permit 10
match ip address 101 match ip address 101
set community 0x0DE90046 set community 0x0DE90046
route-map config-community permit 20 route-map config-community permit 20
match as-path 1 match as-path 1
! !
Appendix B. Uniform Route-map Configuration Appendix B. Uniform Route-map Configuration
Here is the uniform route-map that can be used for all BGP customers: Here is the uniform route-map that can be used for all BGP
customers:
!!# routes primary via another ISP !!# routes primary via another ISP
ip community-list 70 permit 0x0DE90046 ip community-list 70 permit 0x0DE90046
ip community-list 70 deny ip community-list 70 deny
! !
!!# routes also homed to another ISP, but with DPA or !!# routes also homed to another ISP, but with DPA or
!!# AS-path length as the tie-breaker !!# AS-path length as the tie-breaker
ip community-list 80 permit 0x0DE90050 ip community-list 80 permit 0x0DE90050
ip community-list 80 deny ip community-list 80 deny
! !
 End of changes. 21 change blocks. 
62 lines changed or deleted 51 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/