| RFC 9494 | Long-Lived Graceful Restart | November 2023 |
| Uttaro, et al. | Standards Track | [Page] |
This document introduces a BGP capability called the "Long-LivedGraceful Restart Capability" (or "LLGR Capability"). The benefit of this capability is that stale routes can be retained for alonger time upon session failure than is provided for by BGP Graceful Restart (as described in RFC 4724). A well-known BGP community called"LLGR_STALE" is introduced for marking stale routes retained for alonger time. A second well-known BGP community called "NO_LLGR" is introducedfor marking routes for which these procedures should not be applied.We also specify that such long-lived stale routes be treated asthe least preferred and that their advertisements be limited to BGP speakersthat have advertised the capability. Use of this extension is notadvisable in all cases, and we provide guidelines to help determine if itis.¶
This memo updates RFC 6368 by specifying that the LLGR_STALE community must be propagated into, or out of, the path attributes exchanged between the Provider Edge (PE) and Customer Edge (CE) routers.¶
This is an Internet Standards Track document.¶
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). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9494.¶
Copyright (c) 2023 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.¶
Routing protocols in general, and BGP in particular, have historically beendesigned with a focus on "correctness", where a key part of correctness isfor each network element's forwarding state to converge to the currentstate of the network as quickly as possible. For this reason, the protocolwas designed to remove state advertised by routers that went down (from aBGP perspective) as quickly as possible. Over time, this has been relaxedsomewhat, notably by BGP Graceful Restart (GR)[RFC4724]; however, the paradigmhas remained one of attempting to rapidly remove stale state from the network.¶
Over time, two phenomena have arisen that call into question the underlying assumptions of this paradigm.¶
The observations above motivate a desire to offer network operators the ability to choose to retain BGP data for a longer period than has hitherto been possible when the BGP control plane fails for some reason. Althoughthe semantics of BGP Graceful Restart[RFC4724] are close to those desired,several gaps exist, most notably in the maximum time for which stale informationcan be retained: Graceful Restart imposes a 4095-second upper bound.¶
In this document, we introduce a BGP capability called the "Long-Lived GracefulRestart Capability". The goal of this capability is that stale information can be retained for a longer time across a session reset. We also introduce two BGP well-known communities:¶
Long-lived stale information is to be treated as least preferred, and its advertisement limited to BGP speakers that support thecapability. Where possible, we reference the semantics of BGP GracefulRestart[RFC4724] rather than specifying similar semantics in this document.¶
The expected deployment model for this extension is that it will only be invokedfor certain address families. This is discussed in more detail inSection 5.The use of this extension may be combined with that of conventionalGraceful Restart; in such a case, it is invoked after the conventionalGraceful Restart interval has elapsed. When not combined, LLGR is invoked immediately.Apart from the potential to greatly extend the timer, the mostobvious difference between LLGR and conventional Graceful Restart is thatin LLGR, routes are "depreferenced"; that is, they are treated as least preferred. Contrarily, in conventional GR, route preference is not affected.The design choice to treat long-lived stale routes as least preferred was informed bythe expectation that they might be retained for (potentially) an almostunbounded period of time; whereas, in the conventional Graceful Restartcase, stale routes are retained for only a brief interval. In the case of Graceful Restart, the trade-off between advertising new route status (at the cost of routing churn) and not advertising it (at the cost of suboptimal or incorrect route selection)is resolved in favor of not advertising. In the case of LLGR, it is resolved in favor of advertising new state, using stale information only as a last resort.¶
Section 7 provides some simple examples illustrating the operation of this extension.¶
Further note that, for brevity, in this document when we reference conventional Graceful Restart, we cite its base specification,[RFC4724]. That specification has been updated by[RFC8538]. The citation to[RFC4724] is not intended to be limiting.¶
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.¶
A BGP capability and two BGP communities are introduced in the subsections that follow.¶
The "Long-Lived Graceful Restart Capability", or "LLGR Capability",(value: 71) is a BGP capability[RFC5492]that can be used by a BGP speaker to indicate its ability to preserveits state according to the procedures of this document. If the LLGR capability is advertised, the Graceful Restart capability[RFC4724]MUST also be advertised; seeSection 4.1.¶
The capability value consists of zero or more tuples <AFI, SAFI,Flags, LLST> as follows:¶
+--------------------------------------------------+| Address Family Identifier (16 bits) |+--------------------------------------------------+| Subsequent Address Family Identifier (8 bits) |+--------------------------------------------------+| Flags for Address Family (8 bits) |+--------------------------------------------------+| Long-Lived Stale Time (24 bits) |+--------------------------------------------------+| ... |+--------------------------------------------------+| Address Family Identifier (16 bits) |+--------------------------------------------------+| Subsequent Address Family Identifier (8 bits) |+--------------------------------------------------+| Flags for Address Family (8 bits) |+--------------------------------------------------+| Long-Lived Stale Time (24 bits) |+--------------------------------------------------+¶
The meaning of the fields are as follows:¶
The AFI and SAFI, taken in combination, indicate that the BGP speaker has the ability to preserve its forwarding state for the address family during a subsequent BGP restart. Routes may be either:¶
0 1 2 3 4 5 6 7+-+-+-+-+-+-+-+-+|F| Reserved |+-+-+-+-+-+-+-+-+¶
The well-known BGP community LLGR_STALE (value: 0xFFFF0006) can be used to mark stale routesretained for a longer period of time (see[RFC1997] for more information on BGP communities). Such long-lived stale routes are tobe handled according to the procedures specified inSection 4.¶
An implementationMAY allow users to configure policies that accept,reject, or modify routes based on the presence or absence of this community.¶
The well-known BGP community NO_LLGR (value: 0xFFFF0007) can beused to mark routes that a BGP speaker does not want to be treated according to these procedures, as detailed inSection 4.¶
An implementationMAY allow users to configure policies that accept,reject, or modify routes based on the presence or absence of this community.¶
If a BGP speaker is configured to support the procedures of thisdocument, itMUST useBGP CapabilitiesAdvertisement [RFC5492] to advertise the Long-Lived Graceful RestartCapability. The setting of the parameters for an AFI/SAFI depends onthe properties of the BGP speaker, network scale, and localconfiguration.¶
In the presence of the Long-Lived Graceful Restart Capability, theprocedures specified in[RFC4724] continue to applyunless explicitly revised by this document.¶
If the LLGR Capability is advertised, the Graceful Restart capabilityMUST also be advertised. If it is not so advertised, the LLGR CapabilityMUST be disregarded. The purpose for mandating this is to enable the reuse of certain base mechanisms that are common to both "flavors" notably: origination, collection, and processing of EoR as well as the finite-state-machine modifications and connection-reset logic introduced by GR.¶
We observe that, if support for conventional Graceful Restart is not desiredfor the session, the conventional GR phase can be skipped by omitting allAFIs/SAFIs from the GR Capability, advertising a Restart Time of zero, orboth.Section 4.2discusses the interaction of conventional and LLGR.¶
BGP Graceful Restart [RFC4724] defines conditionsunder which a BGP session can reset and have its associated routesretained. If such a reset occurs for a session in which the LLGR Capability has also been exchanged, the following procedures apply:¶
The following text inSection 4.2 of [RFC4724] no longer applies:¶
If the session does not get re-established within the "Restart Time" that the peer advertised previously, the Receiving SpeakerMUST delete all the stale routes from the peer that it is retaining.¶
and the following procedures are specified instead:¶
After the session goes down, and before the session is re-established,the stale routes for an AFI/SAFIMUST be retained. The interval forwhich they are retained islimited by the sum of the Restart Time in the received Graceful Restart Capabilityand the Long-Lived Stale Time in the received Long-Lived GracefulRestart Capability. The timers received in the Long-Lived Graceful Restart CapabilitySHOULD be modifiable by local configuration, which may impose an upper bound, a lower bound, or both on their respective values.¶
If the value of the Restart Time or the Long-Lived Stale Time is zero,the duration of the corresponding period would be zero seconds. Forexample, if the Restart Time is zero and the Long-Lived Stale Time isnonzero, only the procedures particular to LLGR would apply. Conversely, ifthe Long-Lived Stale Time is zero and the Restart Time is nonzero, onlythe procedures of GR would apply. If both are zero, none of these procedureswould apply, only those of the base BGP specification[RFC4271] (although EoR wouldstill be used as detailed in[RFC4724]). And finally, if bothare nonzero, then the procedures would be applied serially: first those of GR and then those of LLGR. During the first interval, we observe that, while the procedures of GR are in effect, route preference would not be affected. During the second interval, while LLGR procedures are in effect, routeswould be treated as least preferred as specified elsewhere in this document.¶
Once the Restart Time period ends (including the case in which the RestartTime is zero), the LLGR period is said to have begun and the following proceduresMUST be performed:¶
Once the session is re-established, the procedures specified in[RFC4724]apply for the stale routes irrespective of whether the stale routes areretained during the Restart Time period or the Long-Lived Stale Time period.However, in the case of consecutive restarts, the previously marked stale routesMUST NOTbe deleted before the timer for the Long-Lived Stale Time expires.¶
Similar to[RFC4724], once the LLGR Period begins, the HelperMUST immediately remove all the stale routes from the peer that it is retaining for that address family if any of the following occur:¶
If a Long-Lived Stale Time timer is running for routes with a givenAFI/SAFI received from a peer, itMUST NOT be updated (other than bymanual operator intervention) until the peer has established andsynchronized a new session. The session is termed "synchronized" for agiven AFI/SAFI once the EoR for that AFI/SAFI has been received from thepeer or once the Selection_Deferral_Timer discussed in[RFC4724] expires.¶
The value of a Long-Lived Stale Time in the capability receivedfrom a neighborMAY be reduced by local configuration.¶
While the session is down, the expiration of a Long-Lived Stale Timetimer is treated analogously to the expiration of the Restart Timetimer in[RFC4724], other than applying only to the AFI/SAFI itaccompanies. However, the timer continues to run once the session hasre-established. The timer is neither stopped nor updated until the EoR marker isreceived for the relevant AFI/SAFI from the peer. If the timer expiresduring synchronization with the peer, any stale routes that the peer hasnot refreshed are removed. If the session subsequently resets prior tobecoming synchronized, any remaining routes (for the AFI/SAFI whose LLSTtimer expired)MUST be removed immediately.¶
A BGP speaker that has advertised the Long-Lived Graceful RestartCapability to a neighborMUST perform the following uponreceiving a route from that neighbor with the LLGR_STALE communityor upon attaching the LLGR_STALE community itself perSection 4.2:¶
A least preferred routeMUST be treated as less preferred than any other route that is not also least preferred. When performing route selection between two routes when bothare least preferred, normal tiebreaking applies. Note that thiswould only be expected to happen if the only routes available for selectionwere least preferred; in all other cases, such routes would have beeneliminated from consideration.¶
If the LLGR Capability is received without an accompanying GR Capability,the LLGR CapabilityMUST be ignored, that is, the implementationMUST behaveas though no LLGR Capability has been received.¶
Ideally, all routers in an Autonomous System (AS) would support thisspecification before it were enabled. However, to facilitate incrementaldeployment, stale routesMAY be advertised to neighbors that have notadvertised the Long-Lived Graceful Restart Capability under the followingconditions:¶
If this strategy for partial deployment is used, the network operator shouldset the LOCAL_PREF to zero for all long-lived stale routes throughout the Autonomous System.This trades off a small reduction in flexibility (ordering may not bepreserved between competing long-lived stale routes) for consistency between routersthat do, and do not, support this specification. Since the consistency of routeselection can be important for preventing forwarding loops, the latterconsideration dominates.¶
In VPN deployments (for example,[RFC4364]), External BGP (EBGP) isoften used as a PE-CE protocol. It may be a practical necessity in suchdeployments to accommodate interoperation with peer routers that cannot easily beupgraded to support specifications such as this one. This leads to a problem: the procedures defined elsewhere in this document generally prevent LLGR stale routes from being sent acrossEBGP sessions that don't support LLGR, but this could prevent theVPN routes from being used for their intended purpose.¶
We observe that the principal motivation for restricting the propagation of"stale" routing information is the desire to prevent it from spreadingwithout limit once it exits the "safe" perimeter. We further observe thatVPN deployments are typically topologically constrained, making thisconcern moot. For this reason, an implementationMAY advertise stale routesover a PE-CE session, when explicitly configured to do so. That is, thesecond rule listed inSection 4.3MAY bedisregarded in such cases. All other rules continue to apply. Finally,if this exception is used, the implementationSHOULD, by default, attachthe NO_EXPORT community to the routes in question, as an additional protection against stale routes spreading without limit. Attachment ofthe NO_EXPORT communityMAY be disabled by explicit configuration in order to accommodate exceptional cases.¶
See further discussion of using an explicitly configured policy tomitigate this issue inSection 5.1.¶
If IBGP is used as the PE-CE protocol, following the procedures of[RFC6368], then when a PE router imports a VPNroute that contains the ATTR_SET attribute into a destination VRF andsubsequently advertises that route to a CE router:¶
If the CE router supports the procedures of this document (in other words, if the CE router has advertised the LLGR Capability):¶
Inaddition to including the path attributesderived from the ATTR_SET attribute in the advertised route as per[RFC6368], thePE routerMUST also include the LLGR_STALE community if it is presentin the path attributes of the imported route, even if it is notpresent in the ATTR_SET attribute.¶
If the CE router does not support the procedures of this document:¶
Then the optional procedures ofSection 4.6MAY be followed, attaching the NO_EXPORTcommunity and setting the value of LOCAL_PREF to zero, overriding thevalue found in the ATTR_SET.¶
Similarly, when a PE router receives a route from a CE into its VRFand subsequently exports that route to a VPN address family:¶
If the PE router supports the procedures of this document (inother words, if the PE router has advertised the LLGR Capability):¶
In addition to including in the VPN route the ATTR_SET derived fromthe path attributes as per[RFC6368], the PE routerMUST also include the LLGR_STALE community in the VPN route if it ispresent in the path attributes of the route as received from the CE.¶
If the PE router does not support the procedures of this document:¶
There exists no ideal solution. The CE could advertise a route withLLGR_STALE, with the understanding that the LLGR_STALE marking willonly be honored by the provider network if appropriate policyconfiguration exists on the PE (seeSection 5.1).It is at least guaranteed that LLGR_STALE will be propagated whenthe route is propagated beyond the provider network, or the CEcould refrain from advertising the LLGR_STALE route to the incapablePE.¶
The deployment considerations discussed in[RFC4724] apply to thisdocument. In addition, network operators are cautioned to carefullyconsider the potential disadvantages of deploying these procedures for agiven AFI/SAFI. Most notably, if used for an AFI/SAFI that conveysconventional reachability information, the use of a long-lived stale route couldresult in a loss of connectivity for the covered prefix. This specificationtakes pains to mitigate this risk where possible by making such routesleast preferred and by restricting the scope of such routes to routers thatsupport these procedures (or, optionally, a single Autonomous System, seeSection 4.6). However, if a stale route is chosen as best for a given prefix,then according to the normal rules of IP forwarding, that route willbe used for matching destinations, even if a non-stale less specific matching route is also available. Networks in which the deployment of these procedureswould be especially concerning include those that do not use "tunneled"forwarding (in other words, those using conventional hop-by-hop forwarding).¶
ImplementationsMUST NOT enable these procedures by default. TheyMUSTrequire affirmative configuration per AFI/SAFI in order to enable them.¶
The procedures of this document do not alter the route resolvabilityrequirement ofSection 9.1.2.1 of [RFC4271]. Because of this, it will commonly bethe case that "stale" IBGP routes will only continue to be used if therouter depicted in the next hop remains resolvable, even if its BGPcomponent is down. Details of IGPfault-tolerance strategies are beyond the scope of this document. Inaddition to the foregoing, it may be advisable to check the viability ofthe next hop through other means, for example,Bidirectional Forwarding Detection (BFD) [RFC5880]. This may be especiallyuseful in cases where the next hop is known directly at the network layer,notably EBGP.¶
As discussed in this document, after a BGP session goes down and before thesession is re-established, stale routes may be retained for up to twoconsecutive periods, controlled by the Restart Time and the Long-LivedStale Time, respectively:¶
The setting of the relevant parameters for a particular application should take into account trade-offs, network dynamics, and potential failure scenarios. If needed,the first period can be bypassed either by local configuration or by settingthe Restart Time in the Graceful Restart Capability to zero and/or notlisting the AFI/SAFI in that capability.¶
The setting of the F bit (and the Forwarding State bit of theaccompanying GR Capability) depends, in part, on deployment considerations.The F bit can be understood as an indication that the Helper should flushassociated routes (if the bit is left clear). As discussed inSection 1, an important use case for LLGR is for routes that are moreakin to configuration than to conventional routing. For such routes, it maymake sense to always set the F bit, regardless of other considerations. Likewise, for control-plane-only entities, such as dedicated routereflectors that do not participate in the forwarding plane, it makessense to always set the F bit. Overall, the rule of thumb is that if loss ofstate on the restarting router can reasonably be expected to cause aforwarding loop or persistent packet loss, the F bit should be set scrupulouslyaccording to whether state has been retained. Specifics of whether or not the F bitis set are implementation dependent and may also be controlledby configuration. Also, for every AFI/SAFI represented in the LLGR Capabilitythat is also represented in the GR Capability, there will be two correspondingF bits: the LLGR F bit and the GR F bit. If the LLGR F bit is set, the corresponding GR F bit should also be set, since to do otherwise would causethe state to be cleared on the Receiving Router per the normal rules of GR,violating the intent of the set LLGR bit.¶
As discussed inSection 4.7, it may be necessary for a PE toadvertise stale routes to a CE in some VPN deployments, even if the CEdoes not support this specification. In that case, the operatorconfiguring their PE to advertise such routes should notify the operatorof the CE receiving the routes, and the CE should be configured todepreference the routes.¶
Similarly, it may be necessary for a CE to advertise stale routes to aPE, even if the PE does not support this specification. In that case,the operator configuring their CE to advertise such routes should notifythe operator of the PE receiving the routes, and the PE should beconfigured to depreference the routes.¶
Typical BGP implementations will be able to be configured todepreference routes by matching on the LLGR_STALE community and settingthe LOCAL_PREF for matching routes to zero, similar to the proceduredescribed inSection 4.6.¶
Depreferencing EBGP routes is considered safe, no different from the common practice of applying a routing policy to an EBGP session. However, the same is not always true of IBGP.¶
Consistent route selection is a fundamental tenet of IBGP correctness andsafe operation in hop-by-hop routed networks. When routers within an AS apply different criteria inselecting routes, they can arrive at inconsistent route selections. This can lead to the formation of forwarding loops unless someform of tunneled forwarding is used to prevent "core" routers from making a (potentially inconsistent) forwarding decision based on theIP header.¶
This specification uses the state of a peering session as an inputto the selection criteria, depreferencing routes that are associatedwith a session that has gone down but that have not yet aged out. Sincedifferent routers within an AS might have different notions as to whether their respective sessions with a given peer are up or down, they might apply different selection criteria to routes from that peer. This could result in a forwarding loop forming between such routers.¶
For an example of such a forwarding loop, consider the following simple topology:¶
A ---- B ---- C ------------------------- D^ ^| |R1 R2
In this example, A - D are routers with a full mesh of IBGP sessionsbetween them (the sessions are not shown). The short links have unit cost, the long link has cost 5.Routers A and D are AS border routers, each advertising some route, R, with the same LOCAL_PREF intothe AS: denoted R1 and R2 in the diagram. In ordinaryoperation, it can be seen that routers B and C will select R1 forforwarding and will forward toward A.¶
Suppose that the session between A and B goes down for some reason, andit stays down long enough for LLGR processing to be invoked on B. Then, on B,route R1 will be depreferenced, leading to the selection of R2 by B.However, C will continue to prefer R1. In this case, it can be seen that aforwarding loop for packets destined to R would form between B and C. (Wenote that other forwarding loop scenarios can be constructed forconventional GR, but these are generally considered less severe since GR canremain in effect for a much more limited interval.)¶
The potential benefits of this specification can outweigh the risks discussed above, as long as care is exercised in deployment. The cardinal rule to be followed is that if a given set of routes isbeing used within an AS for hop-by-hop forwarding, enabling LLGR procedures is notrecommended. If tunneled forwarding (suchas MPLS) is used within the AS, or if routes are being used for purposes other than hop-by-hop forwarding, less caution is needed;however, the operator should still carefully consider the consequencesof enabling LLGR.¶
The security implications of the LLGR mechanism defined in this document are akin to those incurred by the maintenance ofstale routing information within a network. However, since theretention time may be much longer, the window duringwhich certain attacks are feasible may substantially increase. This is particularlyrelevant when considering the maintenance of routing information thatis used for service segregation, such as MPLS label entries.¶
For MPLS VPN services, the effectiveness of the traffic isolationbetween VPNs relies on the correctness of the MPLS labels betweeningress and egress PEs. In particular, when an egress PE withdraws alabel L1 allocated to a VPN1 route, this label must not be assignedto a VPN route of a different VPN until all ingress PEs stop usingthe old VPN1 route using L1.¶
Such a corner case may happen today if the propagation of VPN routesby BGP messages between PEs takes more time than the label reallocation delay on a PE. Given that we can generally bound the worst-case BGP propagation time to a few minutes (for example, 2-5 minutes), the securitybreach will not occur if PEs are designed to not reallocate apreviously used and withdrawn label before a few minutes.¶
The problem is made worse with BGP GR between PEs because VPN routes canbe stalled for a longer period of time (for example, 20 minutes).¶
This is further aggravated by the LLGR extension specifiedin this document because VPN routes can be stalled for a much longerperiod of time (for example, 2 hours, 1 day).¶
In order to exploit the vulnerability described above, an attackerneeds to engineer a specific LLGR state between two PE devices andalso cause the label reallocation to occur such that the twotopologies overlap. To avoid the potential for a VPN breach, theoperator should ensure that the lower bound for label reuse is greaterthan the upper bound on the LLST before enabling LLGR for a VPNaddress family.Section 4.2 discusses theprovision of an upper bound on LLST. Details of features for settinga lower bound on label reuse time are beyond the scope of this document;however, factors that might need to be taken into account when settingthis value include:¶
Note that[RFC4781], which defines the Graceful Restart Mechanismfor BGP with MPLS, is also applicable to LLGR.¶
For illustrative purposes, we present a few examples of how thisspecification might be used in practice. These examples are neitherexhaustive nor normative.¶
Consider the following scenario: A border router, ASBR1, has an IBGP peering witha route reflector, RR1, from which it learns routes. It has an EBGP peeringwith an external peer, EXT, to which it advertises those routes. The external peerhas advertised the GR and LLGR Capabilities to ASBR1. ASBR1 is configuredto support GR and LLGR on its sessions with RR1 and EXT. RR1 advertises a GR Restart Timeof 1 (second) and an LLST of 3600 (seconds):¶
| Time | Event |
|---|---|
| t | ASBR1's IBGP session with RR fails. ASBR1 retains RR's routes according to the rules of GR[RFC4724]. |
| t+1 | GR Restart Time expires. ASBR1 transitions RR's routes to long-lived stale routes by attaching the LLGR_STALE community and depreferencing them. However, since it has no backup routes, it continues to make use of them. It re-announces them to EXT with the LLGR_STALE community attached. |
| t+1+3600 | LLST expires. ASBR1 removes RR's stale routes from its own RIB and sends BGP updates to withdraw them from EXT. |
Next, imagine the same scenario, but suppose RR1 advertised a GR Restart Time of zero, effectively disabling GR. Equally, ASBR1 could have useda local configuration to override RR1's offered Restart Time, setting it toa locally configured value of zero:¶
| Time | Event |
|---|---|
| t | ASBR1's IBGP session with RR fails. ASBR1 transitions RR's routes to long-lived stale routes by attaching the LLGR_STALE community and depreferencing them. However, since it has no backup routes, it continues to make use of them. It re-announces them to EXT with the LLGR_STALE community attached. |
| t+0+3600 | LLST expires. ASBR1 removes RR's stale routes from its own RIB and sends BGP updates to withdraw them from EXT. |
Next, imagine the original scenario, but consider that the ASBR1-RR1session comes back up and becomes synchronized 180 seconds after the failure wasdetected:¶
| Time | Event |
|---|---|
| t | ASBR1's IBGP session with RR fails. ASBR1 retains RR's routes according to the rules of GR[RFC4724]. |
| t+1 | GR Restart Time expires. ASBR1 transitions RR's routes to long-lived stale routes by attaching the LLGR_STALE community and depreferencing them. However, since it has no backup routes, it continues to make use of them. It re-announces them to EXT with the LLGR_STALE community attached. |
| t+1+179 | Session is re-established and resynchronized. ASBR1 removes the LLGR_STALE community from RR1's routes and re-announces them to EXT with the LLGR_STALE community removed. |
Finally, imagine the original scenario, but consider that EXT has not advertised the LLGR Capability to ASBR1:¶
| Time | Event |
|---|---|
| t | ASBR1's IBGP session with RR fails. ASBR1 retains RR's routes according to the rules of GR[RFC4724]. |
| t+1 | GR Restart Time expires. ASBR1 transitions RR's routes to long-lived stale routes by attaching the LLGR_STALE community and depreferencing them. However, since it has no backup routes, it continues to make use of them. It withdraws them from EXT. |
| t+1+3600 | LLST expires. ASBR1 removes RR's stale routes from its own RIB. |
This document defines a BGP capability called the "Long-Lived Graceful RestartCapability". IANA has assigned a value of 71 from the "Capability Codes"registry.¶
This document introduces two BGP well-known communities:¶
IANA has assigned thesewell-known community values 0xFFFF0006 and 0xFFFF0007, respectively, from the"BGP Well-known Communities" registry.¶
IANA has established a registry called the "Long-Lived GracefulRestart Flags for Address Family" registry under the "Border Gateway Protocol (BGP) Parameters" group. The registration procedures are Standards Action (see[RFC8126]). The registry is initially populated as follows:¶
| Bit Position | Name | Short Name | Reference |
|---|---|---|---|
| 0 | Preservation of state | F | RFC 9494 |
| 1-7 | Unassigned |
We would like to thankNabil Bitar,Martin Djernaes,Roberto Fragassi,Jeffrey Haas,Jakob Heitz,Daniam Henriques,Nicolai Leymann,Mike McBride,Paul Mattes,John Medamana,Pranav Mehta,Han Nguyen,Saikat Ray,Valery Smyslov, andBo Wu for theirvaluable input and contributions to the discussion and solution.¶