Skip to main content

Deterministic Route Redistribution into BGP
draft-chen-bgp-redist-01

The information below is for an old version of the document.
Document Type This is an older version of an Internet-Draft whose latest revision is Expired
Authors Enke Chen , Jenny Yuan
Last updated 2021-06-29
Stream (None)
Formats plain text htmlized pdfized bibtex
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-chen-bgp-redist-01
Internet Engineering Task Force                                  E. Chen
Internet Draft                                                   J. Yuan
Updates: 4271 (if approved)                           Palo Alto Networks
Intended status: Standards Track                           June 28, 2021
Expires: December 29, 2021

              Deterministic Route Redistribution into BGP
                      draft-chen-bgp-redist-01.txt

Abstract

   In this document we present several examples of non-deterministic
   routing behavior involving route redistribution into BGP.  In order
   to eliminate such non-deterministic behavior, we propose an
   enhancement to BGP route selection that would take into account the
   administrative distance under certain conditions.  We also recommend
   that the LOCAL_PREF value be reduced for the redistributed backup
   route, and be calculated automatically based on the administrative
   distance.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 29, 2021.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

Chen & Yuan                                                     [Page 1]

Internet Draft        draft-chen-bgp-redist-01.txt             June 2021

   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1. Introduction

   A routing protocol usually downloads its best (or active) route to
   the routing table, also known as Routing Information Base (RIB),
   which in turn selects the best (or active) route to program the
   forwarding table.

   When comparing routes from different routing protocols, RIB typically
   uses the "administrative distance" [ADMIN-DIS] (abbreviated as
   "admin-distance" hereafter) as the tie breaker.  The convention is
   that a route with a lower admin-distance is more preferred, and that
   is assumed in this document when specific admin-distance values are
   given as examples.  The admin-distance associated with a route in RIB
   is commonly used to implement various routing schemes such as
   designating primary and backup routes in a network.

   On the other hand, the route selection in BGP [RFC4271] involves
   comparing the LOCAL_PREF, AS_PATH and other BGP attributes. The
   bestpath in BGP usually becomes the candidate for downloading to the
   RIB, and for advertising to BGP neighbors.

   It is common to redistribute routes from other routing protocols
   (such as "static routing" [STATIC-R]) into BGP for route propagation.
   This topic is briefly discussed in [Sect. 9.4, RFC4271].  A
   redistributed route is usually assigned a fixed LOCAL_PREF value, and
   has an empty AS_PATH attribute.

   The interaction between RIB and BGP follows these general rules:

      o A local route may be redistributed into BGP only if it is active
        in RIB based on the admin-distance.

      o Only the bestpath in BGP is downloaded to RIB (if it is not a
        redistributed route).

   Currently the admin-distance does not play any role in BGP route
   selection.  Due to the lack of such correlation between RIB and BGP,
   when a backup route (based on the admin-distance) is redistributed
   into BGP as shown in the next section, routing may converge to
   different paths depending on the order of path arrivals.  Such non-
   deterministic routing behavior is clearly detrimental to network
   operations.

Chen & Yuan                                                     [Page 2]

Internet Draft        draft-chen-bgp-redist-01.txt             June 2021

   In order to eliminate such non-deterministic behavior, we propose an
   enhancement to BGP route selection that would take into account the
   admin-distance under certain conditions.  We also recommend that the
   LOCAL_PREF value be reduced for the redistributed backup route, and
   be calculated automatically based on the admin-distance.

   The proposed enhancement and recommendation are backward compatible,
   and can be deployed on an individual router basis.

1.1. Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2. The Problem

   In this section several examples are presented to illustrate the non-
   deterministic routing behavior involving route redistribution into
   BGP.

2.1. On a Single Router

   Consider an example in which there are two paths for the same
   destination on a single router. As shown in the following table, the
   primary path A is received from an external BGP neighbor, and the
   backup path B is a static route and is configured for redistribution
   into BGP.

       Path   Type     Admin_Distance   LOCAL_PREF   AS_PATH
       -----------------------------------------------------
       A      EBGP           20            100        65535
       B      Static        150            100         --

   Depending on the order of path arrivals, the path that arrives first
   would be selected as the bestpath in both RIB and BGP.

   More specifically, if Path A is received in BGP and is downloaded to
   RIB first, it would remain as the best in RIB (due to the admin-
   distance) even when Path B shows up in RIB later. In this case Path A
   would be the best one in both RIB and BGP.

Chen & Yuan                                                     [Page 3]

Internet Draft        draft-chen-bgp-redist-01.txt             June 2021

   If Path B shows up in RIB and is redistributed into BGP first, it
   would remain as the best in BGP (due to it being a local route or
   with a shorter AS-PATH) even when Path A is received in BGP later. In
   this case Path B would be the best one in both RIB and BGP.

2.2. Network-wide Behavior

   A common routing setup for a multi-homed customer is to treat one
   connection as the primary, and another as the backup. Consider the
   following example in which Routers R1, R2 and R3 are part of a
   provider network and IBGP sessions are maintained among them.  There
   are two customer connections, a primary connection on R1 and a backup
   connection on R2.  The customer route X is statically routed on both
   R1 and R2, and is redistributed into BGP.  On R2, the backup path for
   X is configured with a less preferred admin-distance than the one for
   IBGP paths.

                                +----+
                                | R3 |
                                +----+
                               /      \
                              /  ibgp  \
                        +----+          +----+
                        | R1 |----------| R2 |
                        +----+          +----+
                          |                |
                          |                |
                          |                |
                          X                X

   While R1 consistently selects the local static route as the best one,
   the route selection on R2 would be non-deterministic.  As shown in
   the following figure, there are potentially two BGP paths A and B for
   X on R2, with Path A learned from R1 and Path B locally
   redistributed.

       Path   Type     Admin_Distance   LOCAL_PREF   AS_PATH
       -----------------------------------------------------
       A      IBGP          200            100         --
       B      Local         230            100         --

   Depending on the order of arrivals of these two paths, the path that
   arrives first would be selected as the bestpath in both RIB and BGP.

Chen & Yuan                                                     [Page 4]

Internet Draft        draft-chen-bgp-redist-01.txt             June 2021

   More specifically, if Path A is received in BGP and is downloaded to
   RIB first, it would remain as the best in RIB (due to the admin-
   distance) even when Path B shows up in RIB later. In this case A
   would be the best one in both RIB and BGP.

   If Path B shows up in RIB and is redistributed into BGP first, it
   would remain as the best in BGP (due to it being a local route or
   with a lower IGP metric) even when Path A is received in BGP later.
   In this case Path B would be the best one in both RIB and BGP.

   The non-deterministic route selection on R2 may cause other nodes
   (like R3) to converge to different paths as well. The routing
   behavior in the network would be non-deterministic, and inconsistent
   with the intended routing design.

   A network using BGP route reflection [RFC4456] (or BGP confederation
   [RFC5065]) may experience additional cases of network-wide "non-
   deterministic" routing behavior.  For example in the following
   figure, when both R1 and R2 advertise their respective local routes
   to the route reflector (RR) simultaneously, the RR would use the "IGP
   metric" to choose the bestpath between the two IBGP paths.  As a
   result the network may or may not converge to the primary path.

                                +----+
                                | RR |
                                +----+
                               /      \
                              /        \
                        +----+          +----+
                        | R1 |          | R2 |
                        +----+          +----+
                          |                |
                          |                |
                          |                |
                          X                X

Chen & Yuan                                                     [Page 5]

Internet Draft        draft-chen-bgp-redist-01.txt             June 2021

3. The Proposed Solution

   In order to eliminate the non-deterministic routing behavior
   involving route redistribution into BGP, we propose an enhancement to
   BGP route selection that would take into account the admin-distance
   under certain conditions.  We also recommend that the LOCAL_PREF
   value be reduced for the redistributed backup route, and calculated
   automatically based on the admin-distance.

3.1. Enhancement to BGP Route Selection

   To make it deterministic on a single router regarding the route being
   sourced and advertised to the network, we propose that the following
   procedure be added prior to the step that compares the degrees of
   preference of routes and identifies the route that has the highest
   degree of preference, as described in Sect. 9.1.2 [RFC4271] for BGP
   route selection:

      When comparing a locally redistributed route with another route
      that is either locally aggregated or received from an external
      neighbor, favor the one with a more preferred admin-distance. The
      admin-distance for a BGP route is obtained as follows:

          For a locally redistributed route, it is inherited from the
          route being redistributed from RIB.

          For a non-redistributed route, it is of the same value as the
          admin-distance assigned to the route for the purpose of RIB
          installation (regardless of whether it is actually installed
          in RIB).

   It should be noted that IBGP paths are deliberately excluded from the
   algorithm.  As the admin-distance is not propagated by BGP, involving
   IBGP paths in the admin-distance comparison can easily result in
   unintended routing behavior and even route churns.  To influence
   route selection in a network, use the LOCAL_PREF attribute as
   described in the next section.

3.2. Setting the LOCAL_PREF Value

   When a non-BGP route is designated as a backup route in the network,
   it should be assigned a less preferred admin-distance than the value
   for IBGP routes. When such a route is redistributed into BGP, it is
   RECOMMENDED that the LOCAL_PREF value for the redistributed route be
   set lower than the default LOCAL_PREF value for IBGP routes.

Chen & Yuan                                                     [Page 6]

Internet Draft        draft-chen-bgp-redist-01.txt             June 2021

   The LOCAL_PREF value for the redistributed route can be calculated
   automatically as described by the following pseudo-code:

        if (redist_admin_distance > ibgp_admin_distance) {
            delta = redist_admin_distance - ibgp_admin_distance;
            if (default_local_pref > delta)
                redist_local_pref = default_local_pref - delta;
            else
                redist_local_pref = 0;
        }

   As an example, there are three paths in the network and they are
   designated as the primary, secondary and tertiary. The routing scheme
   can be implemented by assigning the proper admin-distance values, and
   then calculate the LOCAL_PREF values automatically.

          Default Local_Pref for IBGP:  100
              Admin-distance for IBGP:  200

         Path         Admin_Distance   LOCAL_PREF
         ----------------------------------------
         Primary         10              100
         Secondary      230               70
         Tertiary       240               60

   In addition to lowering the LOCAL_PREF value, it may be necessary to
   modify the parameters for the aforementioned redistributed route
   pertaining to any vendor-specific route selection criteria preceding
   the LOCAL_PREF comparison.  For example, the "weight" parameter
   exists in a number of implementations in which case the "weight" for
   the aforementioned redistributed route should be made equal to the
   default "weight" for IBGP routes.

3.3. Configuration Option

   Configuration can be used to achieve the equivalent outcome by
   setting the appropriate LOCAL_PREF value (and also the "weight"
   parameter if applicable) for the redistributed backup route. It can
   also be used to override the LOCAL_PREF value calculated based on the
   admin-distance value of the redistributed route as proposed in this
   document.

   When route redistribution is part of a more complex routing scheme
   beyond what can be automated with the proposed solution,
   configuration can also be used following the general principles

Chen & Yuan                                                     [Page 7]

Internet Draft        draft-chen-bgp-redist-01.txt             June 2021

   discussed in this document.

4. IANA Considerations

   This document has no request for IANA.

5. Security Considerations

   The solution proposed in this document does not change the underlying
   security or confidentiality issues inherent in the existing BGP
   [RFC4271].

6. Acknowledgments

   The authors would like to thank Naiming Shen and Acee Lindem for
   inputs and discussions.

7. References

7.1. Normative References

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119,
               DOI 10.17487/RFC2119, March 1997,
               <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4271]   Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
               Border Gateway Protocol 4 (BGP-4)", RFC 4271,
               DOI 10.17487/RFC4271, January 2006,
               <http://www.rfc-editor.org/info/rfc4271>.

   [RFC8174]   Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
               2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
               May 2017, <https://www.rfc-editor.org/info/rfc8174>.

7.2. Informative References

   [STATIC-R]  Static routing, Wikipedia,
               https://en.wikipedia.org/wiki/Static_routing

   [ADMIN-DIS] Administrative distance, Wikipedia,
               https://en.wikipedia.org/wiki/Administrative_distance.

Chen & Yuan                                                     [Page 8]

Internet Draft        draft-chen-bgp-redist-01.txt             June 2021

   [RFC4456]   Bates, T., Chen, E., and R. Chandra, "BGP Route
               Reflection: An Alternative to Full Mesh Internal BGP
               (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
               <http://www.rfc-editor.org/info/rfc4456>.

   [RFC5065]   Traina, P., McPherson, D., and J. Scudder, "Autonomous
               System Confederations for BGP", RFC 5065,
               DOI 10.17487/RFC5065, August 2007,
               <http://www.rfc-editor.org/info/rfc5065>.

Authors' Addresses

   Enke Chen
   Palo Alto Networks

   Email: enchen@paloaltonetworks.com

   Jenny Yuan
   Palo Alto Networks

   Email: jyuan@paloaltonetworks.com

Chen & Yuan                                                     [Page 9]