Internet DRAFT - draft-anup-idr-bgp-frr-splithorizon

draft-anup-idr-bgp-frr-splithorizon







Inter-Domain Routing                                            T. Kumar
Internet-Draft                                                  Ericsson
Intended status: Standards Track                            May 23, 2017
Expires: November 24, 2017


   Split Horizon Considerations in Border Gateway Protocol (BGP) Fast
                             ReRoute (FRR)
                 draft-anup-idr-bgp-frr-splithorizon-00

Abstract

   This document describes the problems in certain types of BGP FRR
   deployments.  It also suggests a solution in such scenarios.  The
   described problem and solution are applicable to any distance vector
   routing protocol attempting FRR

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119] .

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 http://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 November 24, 2017.

Copyright Notice

   Copyright (c) 2017 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
   (http://trustee.ietf.org/license-info) in effect on the date of



Kumar                   Expires November 24, 2017               [Page 1]

Internet-Draft        BGP Fast-ReRoute SplitHorizon             May 2017


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Preamble  . . . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.1.  Sample Topology . . . . . . . . . . . . . . . . . . . . .   2
     2.2.  Label exchange in FRR scenario  . . . . . . . . . . . . .   3
   3.  Problem . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Summary of the Problem  . . . . . . . . . . . . . . . . .   5
   4.  Solution to the Problem . . . . . . . . . . . . . . . . . . .   5
   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   BGP computes bestpaths, downloads them to RIB and advertises them to
   peer routers.  When the bestpath is lost, BGP will recompute new
   bestpath, redownload to RIB and readvertise it to the peers.  To be
   more resilient during bestpath loss, many vendor Implementations
   support a configuration called "frr" under bgp.  When frr is enabled
   under bgp, bgp will compute a backup path for every bestpath and
   download the pair of paths to RIB, and advertise the pair of paths to
   peers (if allowed through another configuration called bgp add-paths
   advertise).  In short, BGP FRR computes a backup path and gives them
   to RIB and peer routers..

2.  Preamble

   The following sections describe the problems caused in certain BGP
   FRR deployments

2.1.  Sample Topology

   Sample Topology





Kumar                   Expires November 24, 2017               [Page 2]

Internet-Draft        BGP Fast-ReRoute SplitHorizon             May 2017


                                      |
              ----------- S --------- R ------------ P ----------- Q --------
                                      |

                         Figure1: Sample Topology

   The path exchange on each router is as explained below:

   o  Q - BGP router giving a path to peer router P for a destination D

   o  P - BGP router giving the path (received from Q) to peer router R
      for destination D

   o  S - BGP router giving a path to peer router R for destination D

   o  R - BGP router receiving paths from routers S and P for
      destination D.  Path from router S is chosen as bestpath.  Path
      from router P is chosen as alternate path for destination D.

2.2.  Label exchange in FRR scenario

   The label exchange on each router is as explained below:

   o  Suppose that BGP FRR is configured on R

   o  Suppose that R is also configured for label exchange in BGP

   o  R's bestpath is toward S, and backup path is towards P

   o  R allocates a label Lr and advertises Lr to its peers

   o  Since FRR is configured in bgp, internally R binds the label Lr to
      a pair of nexthops (S and P), from where bestpath and backup path
      were learnt respectively.  This binding ensures that all label
      traffic carrying Lr and arriving at R, has primary nexthop as S,
      but also has a backup nexthop P.

   o  R advertises its bestpath (S-R) and label Lr to all peers
      including P

   o  It is important to note that, R's bestpath advertisement to P
      carries label Lr, while Lr is bound to nexthop pair S and P.

3.  Problem

   This section explains the problem when two BGP peers having FRR
   configuration, compute eachother as backup nexthop.  Suppose that BGP




Kumar                   Expires November 24, 2017               [Page 3]

Internet-Draft        BGP Fast-ReRoute SplitHorizon             May 2017


   FRR is configured on both R and P.  Suppose that R and P are also
   configured for label exchange in BGP.

   The sequence of path updates is as explained below:

   o  Stage 1: R and P compute bestpath :

      *  R receives path from S, and considers it as bestpath and
         advertises it to all peers along with label Lr1 (bound to
         bestpath).

      *  P receives path from Q, and considers it as bestpath and
         advertises it to all peers along with label Lp1.

   o  Stage 2: R receives backup path for first time :

      *  R receives the above path from P, with a label Lp1, and
         considers it as backup path.

      *  R allocates a label Lr2 (bound to pair of nexthops, S and P),
         and advertises its bestpath and label Lr2 to all peers
         including P.

      *  Since Lr2 is bound to a pair of nexthops (S and P), it is
         called a double barrel label.

   o  Stage 3: P receives backup path for first time :

      *  P receives the above path from R, with label Lr2, and P
         considers it as backup path.

      *  P allocates a label Lp2 (bound to pair of nexthops - R and Q)
         and advertises its bestpath and label Lp2 to all peers
         including R.

      *  Since Lp2 is bound to a pair of nexthops (Q and R), it is
         called a double barrel label.

   o  Stage 4: R receives backup path for second time :

      *  R receives the 2nd advertisement from P with label Lp2

      *  R sees that new path from P is different from old path received
         during (c) since label is different.  So, R treats this as
         label change coming from P, and R will allocate a new label
         Lr3, and will advertise it to all peers, including P

   o  Stage 5: P receives backup path for second time



Kumar                   Expires November 24, 2017               [Page 4]

Internet-Draft        BGP Fast-ReRoute SplitHorizon             May 2017


      *  P receives the 3rd advertisement from R with label Lr3.

      *  P sees it will be different from (e) since label is different.
         So, P treats this as label change coming from R, and P
         allocates a new label Lp4, and advertises it to all peers,
         including R.

   o  Infinite loop :

      *  The above steps (Stage 2 to 5) repeat forever, and the two
         routers P and R will enter into a path advertisement loop.

      *  It is important to note that stage 2 is the trigger for the
         problem, as it introduces the first label change

3.1.  Summary of the Problem

   When two BGP routers, P and R are configured with bgp frr and bgp
   label exchange, and if they compute each other as backup nexthop,
   then they will enter into repeated label/path advertisement scenario,
   leading to route churn.  This churn can be avoided by implementing
   split horizon rule at stage 2 in bgp frr, as explained in next
   section.

4.  Solution to the Problem

   The advertisement churn explained in previous section occurs because
   of the way labels are bound and advertised in BGP when FRR is
   configured :

   o  the allocated label (double barrel label) is bound to both
      bestpath and backup path, and is advertised to all peers,
      including the peer giving the backup path.

   o  the double barrel label is unique to the 4-tuple : nexthop1, label
      from nexthop1, nexthop2, label from nexthop2

   o  if the label from any of the nexthops changes, then a new double
      barrel label will be allocated and advertised.  This happens in
      stage 2.

   o  due to the above label change, the peer router sees a new label
      advertisement coming from the other peer, and it allocates a new
      label.

   o  the above steps repeat forever





Kumar                   Expires November 24, 2017               [Page 5]

Internet-Draft        BGP Fast-ReRoute SplitHorizon             May 2017


   The above infinite loop triggered by stage 2 can be prevented in one
   of the following ways:

   o  a.  By not advertising the bestpath to the peer giving the backup
      nexthop in stage 2

   o  b.  By not advertising the double barrel label towards the backup
      nexthop in stage 2

   Option (a) is against base bgp protocol, as the bestpath
   advertisement cannot be selectively blocked except by an
   administrative routemap.  We prefer Option (b), i.e do not advertise
   double barrel label towards the backup nexthop.  This is called as
   Split horizon rule in BGP FRR.  Split horizon rule in BGP FRR can be
   defined as follows: "On a bgp router R having bgp frr configuration,
   when R computes bestpath towards S and backup path towards P, and
   allocates a double barrel label Lr for the pair of nexthops (S and
   P), R should not advertise the double barrel label Lr towards the
   backup nexthop P (since this label advertisement triggers the
   problem).  Instead, R should advertise towards P the label L1 bound
   to the bestpath nexthop S.  Further, R should advertise the double
   barrel label Lr to all peers, other than P."  With the above split
   horizon rule, the routers R and P will be stable state after
   advertising the backup paths to each other only once.

5.  Acknowledgments

   The authors would like to thank P. Muthu and team for their
   comments and review.

6.  Security Considerations

   There are no additional security considerations than the base BGP
   RFC.

7.  IANA Considerations

   This document has no actions for IANA.

8.  Contributors

9.  References

9.1.  Normative References







Kumar                   Expires November 24, 2017               [Page 6]

Internet-Draft        BGP Fast-ReRoute SplitHorizon             May 2017


   [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>.

9.2.  Informative References

   [RFC3107]  Rekhter, Y. and E. Rosen, "Carrying Label Information in
              BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001,
              <http://www.rfc-editor.org/info/rfc3107>.

Author's Address

   Anup Kumar T
   Ericsson India Pvt Ltd
   Ferns Icon, Doddanakkundi, Mahadevapura
   Bengaluru  560037
   India

   Email: anupkumar.t@ericsson.com


























Kumar                   Expires November 24, 2017               [Page 7]