Document 2: Symmetric Routing

[Tony Bates <[e-mail]>]

INTERNET-DRAFT                                                 Enke Chen
<draft-ietf-idr-bgp-mpp-00.txt>                               Tony Bates
                                                                     MCI
                                                              April 1995


                Multi-Provider Preference Attribute for BGP
                      <draft-ietf-idr-bgp-mpp-00.txt>




Status of this Memo

   This document is an Internet Draft. Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   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
   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
   Draft directory to learn the current status of this or any other
   Internet Draft.


Abstract

   The Border Gateway Protocol [1] is an inter-autonomous system routing
   protocol designed for TCP/IP internets.

   This document describes an extension to BGP which can be used by a
   single autonomous system with multiple direct providers to specify
   preference among these providers.  This preference would aid in the
   implementation of  symmetric routing, which has become an important
   issue in the multi-provider Internet.


Introduction

   In the multi-provider Internet, it is common for an entity to have
   multiple connections to the Internet.  For example,

   o    A Regional Service Provider (RSP) may be connected to multiple



Chen & Bates                                                    [Page 1]

INTERNET-DRAFT            MPP Attribute for BGP               April 1995


        transit Internet Service Providers (ISPs).

   o    A service subscriber may be connected to multiple RSPs or ISPs.

   o    Subscribers of different providers may wish to backup each
        other.

   The multiple connections may be used equally for load sharing;  or
   some connections used as the primary path and others as backup path.
   The Internet is a mesh of ISPs, RSPs and service subscribers and is
   generally sparsely connected.

   Symmetric routing is generally preferred as it facilitates problem
   resolution, and provides for better resource (especially network
   capacity) planning and utilization.  Routing symmetry is also desir-
   able in achieving optimal traffic flow in terms of reliability, delay
   characteristic, cost and other QoS metrics.  In the multi-provider
   Internet, routing asymmetry, especially at the inter-domain level,
   may have serious economic and legal ramifications.

   As discussed in [3,4], currently it is difficult to implement symmet-
   ric routing in the multi-provider Internet as there does not exist a
   globally transitive metric.  The current BGP specification does not
   enable an AS to specify a preference among multiple direct providers.
   Current practices for implementing routing symmetry include: NLRI-
   based preference at the ISP level, splitting one AS into multiple ASs
   and using non-standard AS path manipulation.  There are many draw-
   backs to these practices [3].

   In this paper, we propose a simple extension to BGP in order to
   facilitate symmetric routing in the multi-provider Internet.  More
   specifically, this extension includes a globally transitive metric
   that can be specified by the first AS that originates a provider
   preference.  Only the AS that originates this preference may need to
   work at the NLRI level to specify this preference.  As illustrated in
   [4] through several examples, this metric, combined with AS-based
   "local_pref" offers much greater flexibility and manageability in
   implementing symmetric inter-domain routing.

   It is highly recommended that one be familiar with the problems and
   issued discussed in [3].










Chen & Bates                                                    [Page 2]

INTERNET-DRAFT            MPP Attribute for BGP               April 1995


Multi-Provider Preference (MPP) Attribute


   This document proposes the MPP path attribute, which is an optional
   transitive attribute of fixed length.  The attribute is represented
   by a pair <AS#, MPP value>.  The AS# is a two octet non-negative
   integer, which denotes the AS that originates or sets the preference.
   The MPP value is a four octet non-negative integer.

   The MPP attribute has Type Code 10. Code 10 is chosen so as not to
   conflict with existing and other proposed codes.


Route Selection Process

   The MPP attribute, if present, shall be used as a selection criteria,
   after the "local_pref" is evaluated, and before the evaluation of the
   AS path length and the multi-exit-discriminator (MED).

   The higher the MPP attribute value, the more preferred the route.

   A route with missing MPP attribute must be treated as having an MPP
   attribute with value zero.


Operation

   The MPP attribute should only be set when needed. It should not be
   used a replacement for MED.  MED should still be used when an AS has
   multiple connections to a single provider.

   An AS with multiple direct providers may originate (or set) this
   attribute for a route, if this attribute is not already present.  The
   AS that sets this preference must include its AS number in the
   attribute.  Once the attribute is set, it must be passed along with-
   out any modification.

   A BGP speaker may use the "local_pref" attribute to prefer a differ-
   ent path other than the one specified by the MPP attribute value.

   In the uncommon cases when the MPP attribute for a route has been set
   and further preference is desired for this route by a different AS,
   then the AS-based "local_pref" attributes should be coordinated among
   the direct providers of the AS.







Chen & Bates                                                    [Page 3]

INTERNET-DRAFT            MPP Attribute for BGP               April 1995


Aggregation


   Careful coordination with both upstream and downstream neighbors must
   be taken when aggregating routes with the MPP attribute set.


    o   Generally the AS that originates the preference shall only
        aggregate routes with the same MPP attribute.

    o   In general an AS should not aggregate routes whose MPP attribute
        has been set by another AS.  If aggregation has to be done, the
        resultant aggregate should not have the MPP attribute set.


Limitations

   The MPP attribute would aid in implementing symmetric inter-domain
   routing for the majority of Internet connections.  It should be
   noted, however, that the use of the MPP path attribute does not guar-
   antee symmetry.  In the uncommon cases where the MPP attribute has
   been set and further preference is desired the provider should con-
   sult the AS which sets the MPP attribute to understand why this was
   set before making further policy preferences.


Conclusion

   Due to the distributed nature of the Internet, in general there is no
   guarantee for inter-domain routing symmetry using BGP.  The function-
   ality of this extension is no exception.  Nevertheless, as illus-
   trated through examples in [4], the proposed extension would simplify
   the implementation of symmetric inter-domain routing.  This extension
   is simple and requires little change to the current practice and
   operation of BGP4.  It would offer the flexibility of shifting more
   influence on route selection to where the route originates, which has
   become increasingly meaningful as the Internet becomes more complex
   and dynamic. At the same time, the autonomy of an AS is preserved as
   the "local_pref" feature remains unchanged.


Applicability

   The MPP path attribute may be used with BGP version 2 and all subse-
   quent versions of BGP unless specifically noted otherwise.






Chen & Bates                                                    [Page 4]

INTERNET-DRAFT            MPP Attribute for BGP               April 1995


Security Considerations

   Security considerations are not discussed in this memo.


References

   [1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)",
   RFC1771, March 1995.

   [2] Y. Rekhter, and P. Gross, "Application of the Border Gateway Pro-
   tocol in the Internet", RFC1772, March 1995.

   [3] Chen, E., and Bates, T., "Analysis and Critique of the Current
   Practice of Implementing Symmetric Routing in the Multi-Provider
   Internet", INTERNET-DRAFT, <draft-ietf-idr-symm-multi-prov-00.txt>,
   April 1995.

   [4] Chen, E., and Bates, T., "Application of the BGP Multi-Provider
   Preference Attribute in Implementing Symmetric Routing", INTERNET-
   DRAFT, <draft-ietf-idr-mpp-application-00.txt>, April 1995.

   [5] Antonov, V., "BGP AS Path Metrics", INTERNET DRAFT, <draft-ietf-
   idr-bgp-metrics-00.txt>, March 1995.

   [6] Rekhter, Y., "Routing in a Multi-provider Internet", RFC1787,
   April 1995.


Author's Addresses

   Enke Chen
   MCI
   2100 Reston Parkway
   Reston, VA 22094

   phone: [phone]
   email: [e-mail]

   Tony Bates
   MCI
   2100 Reston Parkway
   Reston, VA 22094

   phone: [phone]
   email: [e-mail]





Chen & Bates                                                    [Page 5]