RFC 1998 (rfc1998) - Page 2 of 9

An Application of the BGP Community Attribute in Multi-home Routing

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