As per Relevance of the word provider, we have this rfc below:
Network Working Group E.
Request for Comments: 1998
Category: Informational T.
cisco
August 1996
An Application of the BGP Community
in Multi-home
Status of This
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This document presents an application of the BGP community
[2] in simplifying the implementation and configuration of
policies in the multi-provider Internet. It shows how the
based configuration can be used to replace the AS-based
of the BGP "LOCAL_PREF" attribute, a common method used today.
only does the technique presented simplifies configuration
management at the provider level, it also represents a paradigm
in that it gives the potential for the customer to control its
routing policy with respect to its service provider, as well
providing the ability for policy configuration to be done at a
based granularity rather than the more common AS based granularity
1.
In the multi-provider Internet, it is common for a service
(i.e., customer) to have more than one service provider, or to
arrangements for redundant connectivity to the global
Internet. As discussed in [3], routing strategies in these
usually require coordination between the service subscriber and
providers, which typically leads to customization of
configurations (e.g., BGP "LOCAL_PREF") not only by the subscriber
but also by its providers. Due to the large number of customers
provider serves, customization of router configurations at
provider level may present management and scalability problems
This document presents an application of the BGP community
in simplifying the implementation of routing strategies in
multi-provider Internet. More specifically, the technique
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
need for customized configuration of the BGP "LOCAL_PREF"
at the provider level while maintaining the same level of
functionality and flexibility
It also represents a paradigm shift in that it gives the
for the customer to control its own routing policy with respect
its service provider, as well as providing the ability for
configuration to be done at a prefix based granularity rather
the more common AS based granularity in use today
2. AS-based Configuration and its
As discussed in [3], in today's multi-provider Internet,
configuration of the BGP "LOCAL_PREF" attribute is often required
implement common routing strategies such as load-sharing or backup
There are two main reasons
o Lack of available implementations and deployment of
software that supports the "Destination Preference Attribute
(DPA) as specified in [4].
DPA allows one to specify a globally transitive preference
that return traffic favors certain path. As discussed in [3],
the attribute will be very useful in influencing route
for routes with identical "LOCAL_PREF" and equal AS-path length
o In the multi-provider Internet, it is common for a
to assign higher BGP "LOCAL_PREF" values for routes from
customers than from other service providers. This
provides some degree of protection for its customer routes
and it facilitates implementation of certain
strategies. It, however, also complicates other
implementations such as backup arrangement, thus,
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,
AS3 and AS4 are customers of AS1 and AS2, respectively. AS3
entered a bilateral agreement with AS4 to provide backup to
other. That is, AS3 would use its direct link to AS4 to reach
AS4 in the normal circumstance, and for transit in the case of
failure between AS3 and AS1. To realize this routing agreement, AS
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
Primarily due to scalability and management concerns, most
only perform "LOCAL_PREF" customization based on ASs, not on
prefixes. If IP prefix-based "LOCAL_PREF" configuration is needed,
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
"LOCAL_PREF" configuration at the provider level
o The implementation tends to less efficient due to the
of coordination and configuration. More importantly,
process needs to be repeated each time a change (e.g.,
a new AS) occurs
o The AS-based customization complicates router
and increases complexity of network operation. It has
a serious scalability issue for providers
o It can not implement prefix-based configuration without
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
3.1 Overview of the Community
The BGP community path attribute is an optional transitive
of variable length [1,2]. The attribute consists of a set of
octet values, each of which specify a community. The
attribute values are encoded using an AS number in the first
octets, with the remaining two octets defined by the AS. As
in [2], a community is a group of destinations (i.e. prefixes)
share some common attribute. Each destination can belong to
communities. All prefixes with the community attribute belong to
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
routing decisions based on the identity of the group
The well-known communities NO_EXPORT (0xFFFFFF01) and NO_
(0xFFFFFF02) are intuitive, and can be used for optimizing
and for improving route aggregation
3.2 Community-based
With the BGP community attribute [2], a provider can now
community-based, rather than AS-based, configuration of
"LOCAL_PREF". The provider first needs to coordinate with
customers a set of communities to be mapped to certain
"LOCAL_PREF" values. The provider can then apply a uniform
configuration to all its customers that would capture routes with
community values, and set up the appropriate BGP "LOCAL_PREF"
accordingly. A customer that requires customization in its
BGP "LOCAL_PREF" configuration can simply send the
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
lot of sense as the customer is in a position to have
understanding about its own topology and routing
requirement
o The effect of route-based customization in BGP "LOCAL_PREF
configuration by providers can now be achieved, thus,
the need of AS-Path manipulation in certain cases
o It addresses the scalability issue facing providers as
distributes the configuration work to the customer
requires customization
Chen & Bates Informational [Page 4]
RFC 1998 Use of Community August 1996
4. A Real-World Implementation
MCI currently makes heavy use of the BGP "LOCAL_PREF" attribute
as part of its routing policy configuration process. Different
"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
Note
o The value '100' is the default value used within our
configuration
o In most cases, the MED attribute set by a customer
sufficient for customer backup routes (e.g., T1 backs up T3).
However, in certain cases configuration of "LOCAL_PREF"
still be necessary until the BGP DPA attribute is available
To make use of the BGP community attribute, several community
(MCI's AS number: 3561 = 0x0DE9) have been defined that can be
by customers to tag routes so that the appropriate "LOCAL_PREF
values are configured. Table 2 lists the appropriate
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
Chen & Bates Informational [Page 5]
RFC 1998 Use of Community August 1996
A customer requiring MCI to configure BGP "LOCAL_PREF" values
than the default can tag their routes with the defined communities
The community values can be configured either based on an AS
list or an IP address access list. A cisco systems software
configuration example is given in Appendix A to show how this can
achieved
A uniform BGP configuration (see Appendix B, again cisco
software specific) is applied by MCI to peers with customers
configure the appropriate "LOCAL_PREF" values based on
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
migrating all other customized BGP "LOCAL_PREF" configurations
this uniform community based configuration approach
5.
[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
Attribute", RFC 1997, August 1996.
[3] Chen, E., and T. Bates, "Current Practice of
Symmetric Routing and Load Sharing in the Multi-
Internet", Work in Progress
[4] Chen, E., and T. Bates, "Destination Preference Attribute
BGP", Work in Progress
[5] Chen, E., and T. Bates, "Application of the BGP
Preference Attribute in Implementing Symmetric Routing",
Work in Progress
[6] cisco systems, cisco IOS Software Version 10.3 Router
Configuration Guide (Addendum), May 1995.
6. Security
Security issues are not discussed in this memo
7.
The authors would specifically like to thank Ravi Chandra, Tony
and Paul Traina of cisco systems for devising and implementing
community attribute
Chen & Bates Informational [Page 6]
RFC 1998 Use of Community August 1996
8. Authors'
Enke
2100 Reston
Reston, VA 22091
Phone: +1 703 715 7087
EMail: enke@mci.
Tony
cisco
170 West Tasman
San Jose, CA 95134
Phone: +1 408 527 2470
EMail: tbates@cisco.
Chen & Bates Informational [Page 7]
RFC 1998 Use of Community August 1996
These appendices list cisco systems software specific
examples for configuring communities, and for uniform route-
definition that sets up the appropriate "LOCAL_PREF" values based
the corresponding community values. These examples are given
to show a working example of how the desired effect discussed in
document can be achieved. Please refer to [6] for more
information on cisco configuration and syntax
Appendix A. Community
The community values can be configured either based upon an AS
list or based an IP address access list. Here is an example
includes both cases
!!
router bgp
neighbor x.x.x.x remote-as 3561
neighbor x.x.x.x filter-list 20
neighbor x.x.x.x route-map config-community
neighbor x.x.x.x send-
!
!!# match
ip as-path access-list 1 permit .*
!
!!# list of customer
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
ip as-path access-list 40 permit _64710_
ip as-path access-list 40 permit _64711_
ip as-path access-list 40 deny .*
!
!!# route-
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
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
Here is the uniform route-map that can be used for all
customers
!!# routes primary via another
ip community-list 70 permit 0x0DE90046
ip community-list 70
!
!!# routes also homed to another ISP, but with DPA
!!# AS-path length as the tie-
ip community-list 80 permit 0x0DE90050
ip community-list 80
!
!!# customer backup
ip community-list 90 permit 0x0DE9005
ip community-list 90
!
!!# the route-map applied to BGP
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]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
