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, . [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, . 9.2. Informative References [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, . 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]