From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6774.txt | 1235 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1235 insertions(+) create mode 100644 doc/rfc/rfc6774.txt (limited to 'doc/rfc/rfc6774.txt') diff --git a/doc/rfc/rfc6774.txt b/doc/rfc/rfc6774.txt new file mode 100644 index 0000000..bc264de --- /dev/null +++ b/doc/rfc/rfc6774.txt @@ -0,0 +1,1235 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Raszuk, Ed. +Request for Comments: 6774 NTT MCL +Category: Informational R. Fernando +ISSN: 2070-1721 K. Patel + Cisco Systems + D. McPherson + Verisign + K. Kumaki + KDDI Corporation + November 2012 + + + Distribution of Diverse BGP Paths + +Abstract + + The BGP4 protocol specifies the selection and propagation of a single + best path for each prefix. As defined and widely deployed today, BGP + has no mechanisms to distribute alternate paths that are not + considered best path between its speakers. This behavior results in + a number of disadvantages for new applications and services. + + The main objective of this document is to observe that by simply + adding a new session between a route reflector and its client, the + Nth best path can be distributed. This document also compares + existing solutions and proposed ideas that enable distribution of + more paths than just the best path. + + This proposal does not specify any changes to the BGP protocol + definition. It does not require a software upgrade of provider edge + (PE) routers acting as route reflector clients. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6774. + + + + +Raszuk, et al. Informational [Page 1] + +RFC 6774 Diverse-BGP-Path Distribution November 2012 + + +Copyright Notice + + Copyright (c) 2012 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 + 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. History .........................................................3 + 2.1. BGP Add-Paths Proposal .....................................3 + 3. Goals ...........................................................5 + 4. Multi-Plane Route Reflection ....................................6 + 4.1. Co-located Best- and Backup-Path RRs .......................8 + 4.2. Randomly Located Best- and Backup-Path RRs ................10 + 4.3. Multi-Plane Route Servers for Internet Exchanges ..........12 + 5. Discussion on Current Models of IBGP Route Distribution ........13 + 5.1. Full Mesh .................................................13 + 5.2. Confederations ............................................14 + 5.3. Route Reflectors ..........................................15 + 6. Deployment Considerations ......................................15 + 7. Summary of Benefits ............................................17 + 8. Applications ...................................................18 + 9. Security Considerations ........................................19 + 10. Contributors ..................................................19 + 11. Acknowledgments ...............................................20 + 12. References ....................................................20 + 12.1. Normative References ....................................20 + 12.2. Informative References ..................................20 + +1. Introduction + + The current BGP4 protocol specification [RFC4271] allows for the + selection and propagation of only one best path for each prefix. As + defined today, the BGP protocol has no mechanism to distribute paths + other than best path between its speakers. This behavior results in + a number of problems in the deployment of new applications and + services. + + + + +Raszuk, et al. Informational [Page 2] + +RFC 6774 Diverse-BGP-Path Distribution November 2012 + + + This document presents a mechanism for solving the problem based on + the conceptual creation of parallel route-reflector planes. It also + compares existing solutions and proposes ideas that enable + distribution of more paths than just the best path. The parallel + route-reflector planes solution brings very significant benefits at a + negligible capex and opex deployment price as compared to the + alternative techniques (full BGP mesh or add-paths [ADD-PATHS]) and + is being considered by a number of network operators for deployment + in their networks. + + This proposal does not specify any changes to the BGP protocol + definition. It does not require upgrades to provider edge or core + routers, nor does it need network-wide upgrades. The only upgrade + required is the new functionality on the new or current route + reflectors. + +2. History + + The need to disseminate more paths than just the best path is + primarily driven by three issues. The first is the problem of BGP + oscillations [RFC3345]. The second is the desire for faster + reachability restoration in the event of failure of the network link + or network element. The third is a need to enhance BGP load- + balancing capabilities. These issues have led to the proposal of BGP + add-paths [ADD-PATHS]. + +2.1. BGP Add-Paths Proposal + + As it has been proven that distribution of only the best path of a + route is not sufficient to meet the needs of the continuously growing + number of services carried over BGP, the add-paths proposal was + submitted in 2002 to enable BGP to distribute more than one path. + This is achieved by including an additional four-octet value called + the "Path Identifier" as a part of the Network Layer Reachability + Information (NLRI). + + The implication of this change on a BGP implementation is that it + must now maintain a per-path, instead of per-prefix, peer + advertisement state to track to which of the peers a given path was + advertised. This new requirement comes with its own memory and + processing cost. + + An important observation is that distribution of more than one best + path by the Autonomous System Border Routers (ASBRs) with multiple + External BGP (EBGP) peers attached where no "next-hop self" is set + may result in inconsistent best-path selection within the autonomous + system. Therefore, it is also required to attach the possible + tiebreakers in the form of a new attribute and propagate those within + + + +Raszuk, et al. Informational [Page 3] + +RFC 6774 Diverse-BGP-Path Distribution November 2012 + + + the domain. The example of such an attribute for the purpose of fast + connectivity restoration to address that very case of ASBR injecting + multiple external paths into the Internal BGP (IBGP) mesh has been + presented and discussed in "Advertisement of Multiple Paths in BGP" + [ADD-PATHS]. Based on the additionally propagated information, best- + path selection is recommended to be modified to make sure that best- + and backup-path selection within the domain stays consistent. More + discussion on this particular point is contained in Section 6, + "Deployment Considerations". In the proposed solution in this + document, we observe that to address most of the applications, just + use of the best external advertisement is required. For ASBRs that + are peering to multiple upstream domains, setting "next-hop self" is + recommended. + + The add-paths protocol extensions have to be implemented by all the + routers within an Autonomous System (AS) in order for the system to + work correctly. Analyzing the benefits or risks associated with + partial add-paths deployments remains quite a topic for research. + The risk becomes even greater in networks not using some form of + edge-to-edge encapsulation. + + The required code modifications can offer the foundation for + enhancements, such as the "Fast Connectivity Restoration Using BGP + Add-path" [FAST-CONN]. The deployment of such technology in an + entire service-provider network requires software, and perhaps + sometimes, in the case of End-of-Engineering or End-of-Life + equipment, even hardware upgrades. Such an operation may or may not + be economically feasible. Even if add-path functionality was + available today on all commercial routing equipment and across all + vendors, experience indicates that it may easily take years to + achieve 100% deployment coverage within any medium or large global + network. + + While it needs to be clearly acknowledged that the add-path mechanism + provides the most general way to address the problem of distributing + many paths between BGP speakers, this document provides a solution + that is much easier to deploy and requires no modification to the BGP + protocol where only a few additional paths may be required. The + alternative method presented is capable of addressing critical + service-provider requirements for disseminating more than a single + path across an AS with a significantly lower deployment cost. That, + in light of the number of general network scaling concerns documented + in RFC 4984 [RFC4984], "Report from the IAB Workshop on Routing and + Addressing", may provide a significant advantage. + + + + + + + +Raszuk, et al. Informational [Page 4] + +RFC 6774 Diverse-BGP-Path Distribution November 2012 + + +3. Goals + + The proposal described in this document is not intended to compete + with add-paths. It provides an interim solution until add-paths are + standardized and implemented and until support for that function can + be deployed across the network. + + It is presented to network operators as a possible choice and + provides those operators who need additional paths today an + alternative from the need to transition to a full mesh. The Nth best + path describes a set of N paths with different BGP next hops with no + implication of ordering or preference among said N paths. + + It is intended as a way to buy more time, allowing for a smoother and + gradual migration where router upgrades will be required for, + perhaps, different reasons. It will also allow the time required so + that standard RP/RE memory size can easily accommodate the associated + overhead with other techniques without any compromises. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Raszuk, et al. Informational [Page 5] + +RFC 6774 Diverse-BGP-Path Distribution November 2012 + + +4. Multi-Plane Route Reflection + + The idea contained in the proposal assumes the use of route + reflection within the network. + + Let's observe today's picture of a simple route-reflected domain: + + ASBR3 + *** + * * + +------------* *-----------+ + | AS1 * * | + | *** | + | | + | | + | | + | RR1 *** RR2 | + | *** * * *** | + |* * * P * * *| + |* * * * * *| + | *** *** *** | + | | + | IBGP | + | | + | | + | *** *** | + | * * * * | + +-----* *---------* *----+ + * * * * + *** *** + ASBR1 ASBR2 + EBGP + Figure 1: Simple route reflection + + Abbreviations used: + RR - Route Reflector + P - Core router + + Figure 1 shows an AS that is connected via EBGP peering at ASBR1 and + ASBR2 to an upstream AS or set of ASes. For a given destination "D", + ASBR1 and ASBR2 may have an external path P1 and P2, respectively. + The AS network uses two route reflectors, RR1 and RR2, for redundancy + reasons. The route reflectors propagate the single BGP best path for + each route to all clients. All ASBRs are clients of RR1 and RR2. + + + + + + + +Raszuk, et al. Informational [Page 6] + +RFC 6774 Diverse-BGP-Path Distribution November 2012 + + + Following are the possible cases of the path information that ASBR3 + may receive from route reflectors RR1 and RR2: + + 1. When the best-path tiebreaker is the IGP distance: When paths P1 + and P2 are considered to be equally good best-path candidates, + the selection will depend on the distance of the path's next hops + from the route reflector making the decision. Depending on the + positioning of the route reflectors in the IGP topology, they may + choose the same best path or a different one. In such a case, + ASBR3 may receive either the same path or different paths from + each of the route reflectors. + + 2. When the best-path tiebreaker is MULTI_EXIT_DISC (MED) or + LOCAL_PREF: In this case, only one path from the preferred exit + point ASBR will be available to RRs since the other peering ASBR + will consider the IBGP path as best and will not announce (or if + already announced will withdraw) its own external path. The + exception here is the use of the BGP Best-External proposal + [EXT-PATH], which will allow a stated ASBR to still propagate to + the RRs on its own external path. Unfortunately, RRs will not be + able to distribute it any further to other clients, as only the + overall best path will be reflected. + + There is no requirement of path ordering. The "Nth best path" really + describes set of N paths with different BGP next hops. + + The proposed solution is based on the use of additional route + reflectors or new functionality enabled on the existing route + reflectors that, instead of distributing the best path for each + route, will distribute an alternative path other than best. The + best-path (main) reflector plane distributes the best path for each + route as it does today. The second plane distributes the second best + path for each route, and so on. Distribution of N paths for each + route can be achieved by using N reflector planes. + + As diverse-path functionality may be enabled on a per-peer basis, one + of the deployment models can be realized to continue advertisement of + the overall best path from both route reflectors, while in addition a + new session can be provisioned to get an additional path. This will + allow the uninterrupted use of the best path, even if one of the RRs + goes down, provided that the overall best path is still a valid one. + + Each plane of the route reflectors is a logical entity and may or may + not be co-located with the existing best-path route reflectors. + Adding a route-reflector plane to a network may be as easy as + enabling a logical router partition, new BGP process, or just a new + configuration knob on an existing route reflector and configuring an + additional IBGP session from the current clients if required. There + + + +Raszuk, et al. Informational [Page 7] + +RFC 6774 Diverse-BGP-Path Distribution November 2012 + + + are no code changes required on the route-reflector clients for this + mechanism to work. It is easy to observe that the installation of + one or more additional route-reflector control planes is much cheaper + and is easier than upgrading hundreds of route-reflector clients in + the entire network to support different BGP protocol encoding. + + Diverse-path route reflectors need the new ability to calculate and + propagate the Nth best path instead of the overall best path. An + implementation is encouraged to enable this new functionality on a + per-neighbor basis. + + While this is an implementation detail, the code to calculate the Nth + best path is also required by other BGP solutions. For example, in + the application of fast connectivity restoration, BGP must calculate + a backup path for installation into the Routing Information Base + (RIB) and Forwarding Information Base (FIB) ahead of the actual + failure. + + To address the problem of external paths not being available to route + reflectors due to LOCAL_PREF or MED factors, it is recommended that + ASBRs enable [EXT-PATH] functionality in order to always inject their + external paths to the route reflectors. + +4.1. Co-located Best- and Backup-Path RRs + + To simplify the description, let's assume that we only use two route- + reflector planes (N=2). When co-located, the additional second-best- + path reflectors are connected to the network at the same points from + the perspective of the IGP as the existing best-path RRs. Let's also + assume that best-external functionality is enabled on all ASBRs. + + + + + + + + + + + + + + + + + + + + + +Raszuk, et al. Informational [Page 8] + +RFC 6774 Diverse-BGP-Path Distribution November 2012 + + + ASBR3 + *** + * * + +------------* *-----------+ + | AS1 * * | + | *** | + | | + | RR1 RR2 | + | *** *** | + |* * *** * *| + |* * * * * *| + | *** * P * *** | + |* * * * * *| + |* * *** * *| + | *** *** | + | RR1' IBGP RR2'| + | | + | | + | *** *** | + | * * * * | + +-----* *---------* *----+ + * * * * + *** *** + ASBR1 ASBR2 + + EBGP + + Figure 2: Co-located Second-Best-Path RR Plane + + The following is a list of configuration changes required to enable + the second-best-path route-reflector plane: + + 1. Unless the same RR1/RR2 platform is being used, adding RR1' and + RR2' either as the logical or physical new control-plane RRs in + the same IGP points as RR1 and RR2, respectively. + + 2. Enabling best-external functionality on ASBRs. + + 3. Enabling RR1' and RR2' for second plane route reflection. + Alternatively, instructing existing RR1 and RR2 to calculate the + second-best path also. + + 4. Unless one of the existing RRs is set to advertise only diverse + path to its current clients, configuring new ASBRs-RR' IBGP + sessions. + + + + + + +Raszuk, et al. Informational [Page 9] + +RFC 6774 Diverse-BGP-Path Distribution November 2012 + + + The expected behavior is that under any BGP condition, the ASBR3 and + P routers will receive both paths P1 and P2 for destination D. The + availability of both paths will allow them to implement a number of + new services as listed in Section 8 ("Applications"). + + As an alternative to fully meshing all RRs and RRs', an operator that + has a large number of reflectors deployed today may choose to peer + newly introduced RRs' to a hierarchical RR', which would be an IBGP + interconnect point within the second plane as well as between planes. + + One deployment model of this scenario can be achieved by simply + upgrading the existing route reflectors without deploying any new + logical or physical platforms. Such an upgrade would allow route + reflectors to service both peers that have upgraded to add-paths, as + well as those peers that cannot be immediately upgraded while at the + same time allowing distribution of more than a single best path. The + obvious protocol benefit of using existing RRs to distribute towards + their clients' best and diverse BGP paths over different IBGP + sessions is the automatic assurance that such a client would always + get different paths with their next hop being different. + + The way to accomplish this would be to create a separate IBGP session + for each Nth BGP path. Such a session should be preferably + terminated at a different loopback address of the route reflector. + At the BGP OPEN stage of each such session, a different bgp_router_id + may be used. Correspondingly, the route reflector should also allow + its clients to use the same bgp_router_id on each such session. + +4.2. Randomly Located Best- and Backup-Path RRs + + Now let's consider a deployment case in which an operator wishes to + enable a second RR' plane using only a single additional router in a + different network location from his current route reflectors. This + model would be of particular use in networks in which some form of + end-to-end encapsulation (IP or MPLS) is enabled between provider- + edge routers. + + Note that this model of operation assumes that the present best-path + route reflectors are only control-plane devices. If the route + reflector is in the data-forwarding path, then the implementation + must be able to clearly separate the Nth best-path selection from the + selection of the paths to be used for data forwarding. The basic + premise of this mode of deployment assumes that all reflector planes + have the same information to choose from, which includes the same set + of BGP paths. It also requires the ability to ignore the step of + comparison of the IGP metric to reach the BGP next hop during best- + path calculation. + + + + +Raszuk, et al. Informational [Page 10] + +RFC 6774 Diverse-BGP-Path Distribution November 2012 + + + ASBR3 + *** + * * + +------------* *-----------+ + | AS1 * * | + | IBGP *** | + | | + | *** | + | * * | + | RR1 * P * RR2 | + | *** * * *** | + |* * *** * *| + |* * * *| + | *** RR' *** | + | *** | + | * * | + | * * | + | *** | + | *** *** | + | * * * * | + +-----* *---------* *----+ + * * * * + *** *** + ASBR1 ASBR2 + + EBGP + + Figure 3: Experimental Deployment of Second-Best-Path RR Plane + + The following is a list of configuration changes required to enable + the second-best-path route reflector RR' as a single platform or to + enable one of the existing control-plane RRs for diverse-path + functionality: + + 1. If needed, adding RR' logical or physical as a new route + reflector anywhere in the network. + + 2. Enabling best-external functionality on ASBRs. + + 3. Disabling IGP metric check in BGP best path on all route + reflectors. + + 4. Enabling RR' or any of the existing RR for second plane path + calculation. + + 5. If required, fully meshing newly added RRs' with all the other + reflectors in both planes. This condition does not apply if the + newly added RR'(s) already have peering to all ASBRs/PEs. + + + +Raszuk, et al. Informational [Page 11] + +RFC 6774 Diverse-BGP-Path Distribution November 2012 + + + 6. Configure new BGP sessions between ASBRs and RRs (unless one of + the existing RRs is set to advertise only diverse path to its + current clients). + + In this scenario, the operator has the flexibility to introduce the + new additional route-reflector functionality on any existing or new + hardware in the network. Any existing routers that are not already + members of the best-path route-reflector plane can be easily + configured to serve the second plane either by using a + logical/virtual router partition or by having their BGP + implementation compliant to this specification. + + Even if the IGP metric is not taken into consideration when comparing + paths during the best-path calculation, an implementation still has + to consider paths with unreachable next hops invalid. It is worth + pointing out that some implementations today already allow for + configuration that results in no IGP metric comparison during the + best-path calculation. + + The additional planes of route reflectors do not need to be fully + redundant as the primary plane does. If we are preparing for a + single network failure event, a failure of a non-backed-up Nth best- + path route reflector would not result in a connectivity outage of the + actual data plane. The reason is that this would, at most, affect + the presence of a backup path (not an active one) on the same parts + of the network. If the operator chooses to create the Nth best-path + plane redundantly by installing not one, but two or more route + reflectors serving each additional plane, the additional robustness + will be achieved. + + As a result of this solution, ASBR3 and other ASBRs peering to RR' + will be receiving the second best path. + + Similarly to Section 4.1, as an alternative to fully meshing all RRs + and diverse path RRs', operators may choose to peer newly introduced + RRs' to a hierarchical RR', which would be an IBGP interconnect point + between planes. + + It is recommended that an implementation advertise the overall best + path over the Nth diverse-path session if there is no other BGP path + with a different next hop present. This is equivalent to today's + case where the client is connected to more than one RR. + +4.3. Multi-Plane Route Servers for Internet Exchanges + + Another group of devices in which the proposed multi-plane + architecture may be of particular applicability is the EBGP route + servers used at many Internet exchange points. + + + +Raszuk, et al. Informational [Page 12] + +RFC 6774 Diverse-BGP-Path Distribution November 2012 + + + In such cases, hundreds of ISPs are interconnected on a common LAN. + Instead of having hundreds of direct EBGP sessions on each exchange + client, a single peering is created to the transparent route server. + The route server can only propagate a single best path. Mandating + the upgrade for hundreds of different service providers in order to + implement add-path may be much more difficult as compared to asking + them to provision one new EBGP session to an Nth best path route + server plane. This allows the distribution of more than the single + best BGP path from a given route server to such an Internet exchange + point (IX) peer. + + The solution proposed in this document fits very well with the + requirement of having broader EBGP path diversity among the members + of any Internet exchange point. + +5. Discussion on Current Models of IBGP Route Distribution + + In today's networks, BGP4 operates as specified in [RFC4271]. + + There are a number of technology choices for intra-AS BGP route + distribution: + + 1. Full mesh + + 2. Confederations + + 3. Route reflectors + +5.1. Full Mesh + + A full mesh, the most basic IBGP architecture, exists when all BGP + speaking routers within the AS peer directly with all other BGP + speaking routers within the AS, irrespective of where a given router + resides within the AS (e.g., P router, PE router, etc.). + + While this is the simplest intra-domain path-distribution method, + historically, there have been a number of challenges in realizing + such an IBGP full mesh in a large-scale network. While some of these + challenges are no longer applicable, the following (as well as + others) may still apply: + + 1. Number of TCP sessions: The number of IBGP sessions on a single + router in a full-mesh topology of a large-scale service provider + can easily reach hundreds. Such numbers could be a concern on + hardware and software used in the late 70s, 80s, and 90s. Today, + customer requirements for the number of BGP sessions per box are + reaching thousands. This is already an order of magnitude more + than the potential number of IBGP sessions. Advancements in the + + + +Raszuk, et al. Informational [Page 13] + +RFC 6774 Diverse-BGP-Path Distribution November 2012 + + + hardware and software used in production routers means that + running a full mesh of IBGP sessions should not be dismissed due + to the resulting number of TCP sessions alone. + + 2. Provisioning: When operating and troubleshooting large networks, + one of the topmost requirements is to keep the design as simple + as possible. When the autonomous system's network is composed of + hundreds of nodes, it becomes very difficult to manually + provision a full mesh of IBGP sessions. Adding or removing a + router requires reconfiguration of all other routers in the AS. + While this is a real concern today, there is already work in + progress in the IETF to define IBGP peering automation through an + IBGP Auto Discovery mechanism [AUTO-MESH]. + + 3. Number of paths: Another concern when deploying a full IBGP mesh + is the number of BGP paths for each route that have to be stored + at every node. This number is very tightly related to the number + of external peerings of an AS, the use of LOCAL_PREF or MED + techniques, and the presence of best-external [EXT-PATH] + advertisement configuration. If we make a rough assumption that + the BGP4-path data structure consumes about 80-100 bytes, the + resulting control-plane memory requirement for 500,000 IPv4 + routes with one additional external path is 38-48 MB, while for 1 + million IPv4 routes, it grows linearly to 76-95 MB. It is not + possible to reach a general conclusion if this condition is + negligible or if it is a show stopper for a full-mesh deployment + without direct reference to a given network. + + To summarize, a full-mesh IBGP peering can offer natural + dissemination of multiple external paths among BGP speakers. When + realized with the help of IBGP Auto Discovery peering automation, + this seems like a viable deployment, especially in medium- and small- + scale networks. + +5.2. Confederations + + For the purpose of this document, let's observe that confederations + [RFC5065] can be viewed as a hierarchical full-mesh model. + + Within each sub-AS, BGP speakers are fully meshed, and as discussed + in Section 2.1, all full-mesh characteristics (number of TCP + sessions, provisioning, and potential concern over number of paths + still apply in the sub-AS scale). + + + + + + + + +Raszuk, et al. Informational [Page 14] + +RFC 6774 Diverse-BGP-Path Distribution November 2012 + + + In addition to the direct peering of all BGP speakers within each + sub-AS, all sub-AS border routers must also be fully meshed with each + other. Sub-AS border routers configured with best-external + functionality can inject additional (diverse) paths within a sub-AS. + + To summarize, it is technically sound to use confederations with the + combination of best-external to achieve distribution of more than a + single best path per route in a large autonomous systems. + + In topologies where route reflectors are deployed within the + confederation sub-ASes, the technique described here applies. + +5.3. Route Reflectors + + The main motivation behind the use of route reflectors [RFC4456] is + the avoidance of the full-mesh session management problem described + above. Route reflectors, for good or for bad, are the most common + solution today for interconnecting BGP speakers within an internal + routing domain. + + Route-reflector peerings follow the advertisement rules defined by + the BGP4 protocol. As a result, only a single best path per prefix + is sent to client BGP peers. This is the main reason many current + networks are exposed to a phenomenon called BGP path starvation, + which essentially results in the inability to deliver a number of + applications discussed later. + + When interconnecting BGP speakers between domains, the route + reflection equivalent is popularly called the "Route Server" and is + globally deployed today in many Internet exchange points. + +6. Deployment Considerations + + Distribution of the diverse-BGP-paths proposal allows the + dissemination of more paths than just the best path to the route- + reflector or route-server clients of today's BGP4 implementations. + As a deployment recommendation, it needs to be mentioned that fast + connectivity restoration as well as a majority of intra-domain BGP- + level load balancing needs can be accommodated with only two paths + (overall best and second best). Therefore, as a deployment + recommendation, this document suggests use of N=2 with diverse-path. + + From the client's point of view, receiving additional paths via + separate IBGP sessions terminated at the new route-reflector plane is + functionally equivalent to constructing a full-mesh peering without + the problems such a full mesh would come with, as discussed in + earlier section. + + + + +Raszuk, et al. Informational [Page 15] + +RFC 6774 Diverse-BGP-Path Distribution November 2012 + + + By precisely defining the number of reflector planes, network + operators have full control over the number of redundant paths in the + network. This number can be defined to address the needs of the + service(s) being deployed. + + The Nth-plane route reflectors should act as control-plane network + entities. While they can be provisioned on the current production + routers, selected Nth-best BGP paths should not be used directly in + the date plane with the exception of such paths being BGP multipath + eligible and such functionality is enabled. Regarding RRs being in + the data plane unless multipath is enabled, the second best path is + expected to be a backup path and should be installed as such into the + local RIB/FIB. + + The use of the term "planes" in this document is more of a conceptual + nature. In practice, all paths are still kept in the single table + where normal best path is calculated. This means that tools like the + looking glass should not observe any changes or impact when + diverse-path has been enabled. + + The proposed architecture deployed along with the BGP best-external + functionality covers all three cases where the classic BGP route- + reflection paradigm would fail to distribute alternate (diverse) + paths. These are + + 1. ASBRs advertising their single best-external paths with no + LOCAL_PREF or MED present. + + 2. ASBRs advertising their single best-external paths with + LOCAL_PREF or MED present and with BGP best-external + functionality enabled. + + 3. ASBRs with multiple external paths. + + This section focuses on discussion of case 3 above in more detail. + This describes the scenario of a single ASBR connected to multiple + EBGP peers. In practice, this peering scenario is quite common. It + is mostly due to the geographic location of EBGP peers and the + diversity of those peers (for example, peering to multiple tier-1 + ISPs, etc.). It is not designed for failure-recovery scenarios, as + single failure of the ASBR would simultaneously result in loss of + connectivity to all of the peers. In most medium and large + geographically distributed networks, there is always another ASBR or + multiple ASBRs providing peering backups, typically in other + geographically diverse locations in the network. + + + + + + +Raszuk, et al. Informational [Page 16] + +RFC 6774 Diverse-BGP-Path Distribution November 2012 + + + When an operator uses ASBRs with multiple peerings, setting next-hop + self will effectively allow local repair of the atomic failure of any + external peer without any compromise to the data plane. + Traditionally, the most common reason for not setting next-hop self + is the associated drawback of losing the ability to signal the + external failures of peering ASBRs or links to those ASBRs by fast + IGP flooding. Such a potential drawback can be easily avoided by + using a different peering address from the address used for next-hop + mapping and removing the next-hop from the IGP at the last possible + BGP path failure. + + Herein, one may correctly observe that in the case of setting next- + hop self on an ASBR, attributes of other external paths such that the + ASBR is peering with may be different from the attributes of its best + external path. Therefore, not injecting all of those external paths + with their corresponding attributes cannot be compared to equivalent + paths for the same prefix coming from different ASBRs. + + While such observation, in principle, is correct, one should put + things in perspective of the overall goal, which is to provide data- + plane connectivity upon a single failure with minimal + interruption/packet loss. During such transient conditions, using + even potentially suboptimal exit points is reasonable, so long as + forwarding information loops are not introduced. In the mean time, + the BGP control plane will on its own re-advertise the newly elected + best external path, and route-reflector planes will calculate their + Nth best paths and propagate them to its clients. The result is that + after seconds, even if potential suboptimality were encountered, it + will be quickly and naturally healed. + +7. Summary of Benefits + + Distribution of the diverse-BGP-paths proposal provides the following + benefits when compared to the alternatives: + + 1. No modifications to the BGP4 protocol. + + 2. No requirement for upgrades to edge and core routers (as required + in [ADD-PATHS]). It is backward compatible with the existing BGP + deployments. + + 3. Can be easily enabled by the introduction of a new route + reflector, a route server plane dedicated to the selection and + distribution of Nth best-path, or just by new configuration of + the upgraded current route reflector(s). + + + + + + +Raszuk, et al. Informational [Page 17] + +RFC 6774 Diverse-BGP-Path Distribution November 2012 + + + 4. Does not require major modification to BGP implementations in the + entire network, which would result in an unnecessary increase of + memory and CPU consumption due to the shift from today's per- + prefix to a per-path advertisement state tracking. + + 5. Can be safely deployed gradually on an RR cluster basis. + + 6. The proposed solution is equally applicable to any BGP address + family as described in "Multiprotocol Extensions for BGP-4" + [RFC4760]. In particular, it can be used "as is" without any + modifications to both IPv4 and IPv6 address families. + +8. Applications + + This section lists the most common applications that require the + presence of redundant BGP paths: + + 1. Fast connectivity restoration in which backup paths with + alternate exit points would be pre-installed as well as + pre-resolved in the FIB of routers. This allows for a local + action upon reception of a critical event notification of + network/node failure. This failure recovery mechanism that is + based on the presence of backup paths is also suitable for + gracefully addressing scheduled maintenance requirements as + described in [BGP-SHUTDOWN]. + + 2. Multi-path load balancing for both IBGP and EBGP. + + 3. BGP control-plane churn reduction for both intra-domain and + inter-domain. + + An important point to observe is that all of the above intra-domain + applications are based on the use of reflector planes but are also + applicable in the inter-domain Internet exchange point examples. As + discussed in Section 4.3, an Internet exchange can conceptually + deploy shadow route server planes, each responsible for distribution + of an Nth best path to its EBGP peers. In practice, it may just be + equal to a new short configuration and establishment of new BGP + sessions to IX peers. + + + + + + + + + + + + +Raszuk, et al. Informational [Page 18] + +RFC 6774 Diverse-BGP-Path Distribution November 2012 + + +9. Security Considerations + + The new mechanism for diverse BGP path dissemination proposed in this + document does not introduce any new security concerns as compared to + the base BGP4 specification [RFC4271] and especially when compared + against full-IBGP-mesh topology. + + In addition, the authors observe that all BGP security issues as + described in [RFC4272] apply to the additional BGP session or + sessions as recommended by this specification. Therefore, all + recommended mitigation techniques to BGP security are applicable + here. + +10. Contributors + + The following people contributed significantly to the content of the + document: + + Selma Yilmaz + Cisco Systems + 170 West Tasman Drive + San Jose, CA 95134 + US + Email: seyilmaz@cisco.com + + + Satish Mynam + Juniper Networks + 1194 N. Mathilda Ave + Sunnyvale, CA 94089 + US + Email: smynam@juniper.net + + + Isidor Kouvelas + Cisco Systems + 170 West Tasman Drive + San Jose, CA 95134 + US + Email: kouvelas@cisco.com + + + + + + + + + + + +Raszuk, et al. Informational [Page 19] + +RFC 6774 Diverse-BGP-Path Distribution November 2012 + + +11. Acknowledgments + + The authors would like to thank Bruno Decraene, Bart Peirens, Eric + Rosen, Jim Uttaro, Renwei Li, Wes George, and Adrian Farrel for their + valuable input. + + The authors would also like to express a special thank you to a + number of operators who helped optimize the provided solution to be + as close as possible to their daily operational practices. In + particular, many thanks to Ted Seely, Shane Amante, Benson + Schliesser, and Seiichi Kawamura. + +12. References + +12.1. Normative References + + [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A + Border Gateway Protocol 4 (BGP-4)", RFC 4271, January + 2006. + + [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route + Reflection: An Alternative to Full Mesh Internal BGP + (IBGP)", RFC 4456, April 2006. + + [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, + "Multiprotocol Extensions for BGP-4", RFC 4760, January + 2007. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + +12.2. Informative References + + [ADD-PATHS] Walton, D., Chen, E., Retana, A., and J. Scudder, + "Advertisement of Multiple Paths in BGP", Work in + Progress, June 2012. + + [AUTO-MESH] Raszuk, R., "IBGP Auto Mesh", Work in Progress, January + 2004. + + [BGP-SHUTDOWN] + Decraene, B., Francois, P., Pelsser, C., Ahmad, Z., and + A. Armengol, "Requirements for the Graceful Shutdown of + BGP Sessions", Work in Progress, September 2009. + + + + + + +Raszuk, et al. Informational [Page 20] + +RFC 6774 Diverse-BGP-Path Distribution November 2012 + + + [EXT-PATH] Marques, P., Fernando, R., Chen, E., Mohapatra, P., and + H. Gredler, "Advertisement of the Best External Route in + BGP", Work in Progress, January 2012. + + [FAST-CONN] Mohapatra, P., Fernando, R., Filsfils, C., and R. Raszuk, + "Fast Connectivity Restoration Using BGP Add-path", Work + in Progress), October 2011. + + [RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana, + "Border Gateway Protocol (BGP) Persistent Route + Oscillation Condition", RFC 3345, August 2002. + + [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC + 4272, January 2006. + + [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous + System Confederations for BGP", RFC 5065, August 2007. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Raszuk, et al. Informational [Page 21] + +RFC 6774 Diverse-BGP-Path Distribution November 2012 + + +Authors' Addresses + + Robert Raszuk (editor) + NTT MCL + 101 S Ellsworth Avenue Suite 350 + San Mateo, CA 94401 + United States + + EMail: robert@raszuk.net + + + Rex Fernando + Cisco Systems + 170 West Tasman Drive + San Jose, CA 95134 + United States + + EMail: rex@cisco.com + + + Keyur Patel + Cisco Systems + 170 West Tasman Drive + San Jose, CA 95134 + United States + + EMail: keyupate@cisco.com + + + Danny McPherson + Verisign, Inc. + 12061 Bluemont Way + Reston, VA 20190 + United States + + EMail: dmcpherson@verisign.com + + + Kenji Kumaki + KDDI Corporation + Garden Air Tower + Iidabashi, Chiyoda-ku, Tokyo 102-8460 + Japan + + EMail: ke-kumaki@kddi.com + + + + + + +Raszuk, et al. Informational [Page 22] + -- cgit v1.2.3