| Internet-Draft | BGP Forwarding Route Reflector | February 2024 |
| Vairavakkalai & Venkataraman | Expires 19 August 2024 | [Page] |
The procedures in BGP Route Reflection (RR) spec [RFC4456] primarily deal with scenarios where the RR is reflecting BGP routes with next hop unchanged.¶
These procedures can sometimes result in traffic forwarding loops in deployments where the RR is in forwarding path, because of reflecting BGP routes with next hop set to self.¶
This document specifies approaches to minimize possiblity of such traffic forwarding loops. One of those approaches updates path selection procedures specified in Section 9 of BGP RR. [RFC4456]¶
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 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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 19 August 2024.¶
Copyright (c) 2024 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 to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The procedures in BGP Route Reflection (RR) spec [RFC4456] primarily deal with scenarios where the RR is reflecting BGP routes with next hop unchanged.¶
These procedures can sometimes result in traffic forwarding loops in deployments where the RR is in forwarding path, and is reflecting BGP routes with next hop set to self. RR with next hop self is used at ABR nodes in Inter-AS Option C (Section 10, [RFC4364]) deployments.¶
This document specifies approaches to minimize possiblity of such traffic forwarding loops. One of those approaches updates path selection procedures specified in Section 9 of BGP RR. [RFC4456]¶
ABR: Area Border Router¶
AS: Autonomous System¶
AFI: Address Family Identifier¶
BN: Border Node¶
EP: Endpoint, e.g. a loopback address in the network¶
MPLS: Multi Protocol Label Switching¶
PE: Provider Edge¶
SAFI: Subsequent Address Family Identifier¶
[RR26] [RR27] [RR16]
| | |
| | |
|+-[ABR23]--+|+--[ASBR21]---[ASBR13]-+|+--[PE11]--+
|| ||| ` / ||| |
[CE41]--[PE25]--[P28] [P29] `/ [P15] [CE31]
| | | /` | | |
| | | / ` | | |
| | | / ` | | |
+--[ABR24]--+ +--[ASBR22]---[ASBR14]-+ +--[PE12]--+
| AS2 | AS2 | |
AS4 + region-1 + region-2 + AS1 + AS3
| | | |
203.0.113.41 ------------ Traffic Direction ----------> 203.0.113.31
A pair of redundant ABRs (ABR23, ABR24 in Figure 1), each acting as an RR with next hop self, may choose each other as best path towards egress PE11, instead of the upstream ASBR (ASBR21 or ASBR22), causing a traffic forwarding loop.¶
This happens because of following the path selection rule specified in Section 9 of BGP RR [RFC4456] that tie-breaks on ORIGINATOR_ID before CLUSTER_LIST. RFC4456 considers pure RR functionality which leaves next hop unchanged.¶
When a RR inserts itself in forwarding path because of reflecting routes with next hop self, as is the case for ABR BNs in an Inter-AS Option C (Section 10 [RFC4364]) BGP transport network, this rule may cause loops.¶
This problem can happen for routes of any BGP address family, including BGP LU (1/4 or 2/4) and BGP CT (AFI/SAFIs: 1/76 or 2/76).¶
Using one or more of the following approaches softens the possibility of such loops in a network with redundant ABRs.¶
Implementations SHOULD provide a way to alter the tie-breaking rule specified in Section 9 of BGP RR [RFC4456] so as to tie-break on CLUSTER_LIST step before ORIGINATOR_ID step, when performing path selection for BGP routes.¶
This document suggests the following modification to the BGP Decision Process Tie Breaking rules (Section 9.1.2.2 of [RFC4271]) that can be applied to path selection of BGP routes:¶
The following rule SHOULD be inserted between Steps e) and f): a BGP Speaker SHOULD prefer a route with the shorter CLUSTER_LIST length. The CLUSTER_LIST length is zero if a route does not carry the CLUSTER_LIST attribute.¶
Some other deployment considerations, if feasible, can also help in avoiding this problem:¶
Configuring the same CLUSTER_ID at the redundant ABR nodes. CLUSTER_ID Loop check will make routes reflected by an ABR unusable at redundant ABRs.¶
IGP metric assignment, such that "ABR to redundant ABR" cost is inferior to "ABR to upstream ASBR" cost.¶
Using procedures described in [BGP-CT] , tunnels belonging to non 'best effort' Transport Classes not be provisioned between ABRs. This will ensure that the BGP CT route received from an ABR with next hop self will be unusable at a redundant ABR.¶
The path selection change mentioned in Section 3.1 can be deployed incrementally at the redundant ABRs, since the forwarding loop would break when one of the ABRs stops chosing the other as best path. Neverthless, it is recommended to consistently provision the path selection change on all redundant ABR/RR nodes in a domain. This provides consistent route selection at the transport layer ABRs in the IBGP domain.¶
The operator should carefully consider the overall impact of any of these options on a specific network deployment.¶
This document makes no new requests of IANA.¶
This document does not change the underlying security issues inherent in the existing BGP protocol, such as those described in [RFC4271], [RFC4272] and [RFC4456].¶
Mehanisms described in this document reduce possibility of loops within an IBGP domain. They do not affect routing across EBGP sessions.¶
The content in this document was introduced as part of [BGP-CT]. But because the described problem is not specific to BGP CT and is useful for other BGP families also, it is being extracted out to this separate document.¶
The authors thank Jeff Haas, Jon Hardwick, Keyur Patel, Robert Raszuk, Susan Hares for the discussions and review comments.¶