RFC 5882
Generic Application of Bidirectional Forwarding Detection (BFD)
RFC 5882: Generic Application of Bidirectional Forwarding Detection (BFD) 🎀
Okay so bestie, this is RFC 5882 and it's giving Standards Track energy 👑 It was written by D. Katz and D. Ward from Juniper Networks, and it was published in June 2010 by the IETF. It's categorised as a Standards Track document, which means it's an official Internet standard, and the ISSN is 2070-1721. 🦋
It doesn't obsolete anything and it doesn't update any other RFCs, so it's a fresh start, no drama 💅
The whole point of this doc is to explain how BFD (Bidirectional Forwarding Detection) can be used by all the different "clients" that want to know if a path is alive. Rather than writing a bunch of tiny documents, the authors decided to describe the big picture in one go ✨
Here's the original title block, kept exactly as written:
Internet Engineering Task Force (IETF) D. Katz
Request for Comments: 5882 D. Ward
Category: Standards Track Juniper Networks
ISSN: 2070-1721 June 2010Abstract 🌸
This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol. Basically, it's the "how do I actually use BFD in my life" guide 🧚
Status of This Memo 💜
This is an Internet Standards Track document. Like, it's official, it's been reviewed by the community, and it's been approved by the IESG. If you want more info on Internet Standards, check out Section 2 of RFC 5741 🫶
Info about the current status, any errata, and how to give feedback can be found at http://www.rfc-editor.org/info/rfc5882.
Copyright Notice 🌈
Copyright (c) 2010 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. Please read those carefully, because they spell out your rights and restrictions. Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 📜
Table of Contents 🍓
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Overview ........................................................3
3. Basic Interaction between BFD Sessions and Clients ..............4
3.1. Session State Hysteresis ...................................4
3.2. AdminDown State ............................................5
3.3. Hitless Establishment/Reestablishment of BFD State .........5
4. Control Protocol Interactions ...................................6
4.1. Adjacency Establishment ....................................6
4.2. Reaction to BFD Session State Changes ......................7
4.2.1. Control Protocols with a Single Data Protocol .......7
4.2.2. Control Protocols with Multiple Data Protocols ......8
4.3. Interactions with Graceful Restart Mechanisms ..............8
4.3.1. BFD Fate Independent of the Control Plane ...........9
4.3.2. BFD Shares Fate with the Control Plane ..............9
4.4. Interactions with Multiple Control Protocols ..............10
5. Interactions with Non-Protocol Functions .......................10
6. Data Protocols and Demultiplexing ..............................11
7. Multiple Link Subnetworks ......................................11
7.1. Complete Decoupling .......................................12
7.2. Layer N-1 Hints ...........................................12
7.3. Aggregating BFD Sessions ..................................12
7.4. Combinations of Scenarios .................................12
8. Other Application Issues .......................................13
9. Interoperability Issues ........................................13
10. Specific Protocol Interactions (Non-Normative) ................13
10.1. BFD Interactions with OSPFv2, OSPFv3, and IS-IS ..........14
10.1.1. Session Establishment .............................14
10.1.2. Reaction to BFD State Changes .....................14
10.1.3. OSPF Virtual Links ................................15
10.2. Interactions with BGP ....................................15
10.3. Interactions with RIP ....................................15
11. Security Considerations .......................................16
12. References ....................................................16
12.1. Normative References .....................................16
12.2. Informative References ...................................161. Introduction ✨
Okay so the Bidirectional Forwarding Detection [BFD] protocol is a liveness detection mechanism. Other network components can use it when their own built-in liveness checks are too slow, not a good fit, or just don't exist at all 💅 Other documents already cover using BFD with specific encapsulations ([BFD-1HOP] [BFD-MULTI] [BFD-MPLS]). As BFD got more popular, people kept asking for BFD to work with more and more network functions. Instead of writing a long pile of short documents, the authors thought it made more sense to describe how BFD and those other network functions ("BFD clients") interact in one broad sweep 🦋
This document describes the generic application of BFD. Specific protocol applications are included just to illustrate the ideas 🌸
1.1. Conventions Used in This Document 💖
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 [KEYWORDS]. 🎀
2. Overview 🌈
The BFD specification defines a protocol with simple and specific semantics. Its one and only job is to verify connectivity between a pair of systems, for a particular data protocol, across a path. That path can be any technology, any length, and any OSI layer 🧚 How fast a path failure gets detected can be tuned by trading off protocol overhead and system load against detection times ⭐
BFD is not meant to give you control protocol liveness info directly. Those protocols have their own methods and their own quirks 🙈 Instead, control protocols can use what BFD provides to guide how they operate. You can think of BFD as a service offered by the layer it runs in 💅
The service interface is pretty straightforward. The application supplies session parameters (neighbor address, time parameters, protocol options), and BFD reports the session state. The most interesting transitions are to and from the Up state. The application is expected to bootstrap the BFD session, because BFD has no discovery mechanism 🫶
An implementation SHOULD establish only a single BFD session per data protocol path, no matter how many applications want to use it. Having multiple BFD sessions to the same endpoints adds no extra value 💜 If multiple applications request different session parameters, how to resolve those conflicts is a local decision. BFD will notify all applications bound to a session whenever a session state change happens 🔥
BFD should be seen as having an advisory role toward the protocols or other network functions it works with. Those then use their own mechanisms to make any state transitions. The interaction is very much at arm's length, which keeps things simple and decoupled 🍓 In particular, BFD explicitly does not carry application-specific information. That's partly for architectural reasons, and partly because BFD may have curious and unpredictable latency characteristics, which makes it a poor transport mechanism 😭
It's important to remember that the interaction between BFD and its client applications has essentially no interoperability issues. BFD is acting in an advisory nature (like hardware signaling the loss of light on a fiber optic circuit, for example), and the existing mechanisms in the client applications are what get used in reaction to BFD events. In fact, BFD may interact with only one of a pair of systems for a particular client application without any ill effect 👑
3. Basic Interaction between BFD Sessions and Clients 🦋
The interaction between a BFD session and its associated client applications is, for the most part, an implementation issue that's outside the scope of this specification. That said, it's useful to describe some mechanisms implementors may use to build full-featured implementations 💖 One way to model this interaction is to create an adaptation layer between the BFD state machine and the client applications. The adaptation layer is aware of both the internals of the BFD implementation and the requirements of the clients ✨
3.1. Session State Hysteresis 🌸
A BFD session can be tightly coupled to its client applications. For example, any transition out of the Up state could signal the clients to take failure action. But sometimes that's not always the best move 🙈
Implementors may choose to hide rapid Up/Down/Up transitions of the BFD session from its clients. This is useful for supporting process restarts without needing complex protocol mechanisms, for example 🧚
So, a system MAY choose not to notify clients if a BFD session transitions from Up to Down and then back to Up, as long as it does so within a reasonable period of time (the length of which is outside the scope of this specification). If the BFD session does not return to Up within that time frame, the clients SHOULD be notified that a session failure has occurred 😭
3.2. AdminDown State 💅
The AdminDown mechanism in BFD is meant to signal that the BFD session is being taken down for administrative purposes. In that case the session state doesn't tell you anything about the liveness of the data path 🫶
So, a system SHOULD NOT indicate a connectivity failure to a client if either the local session state or the remote session state (if known) transitions to AdminDown, as long as that client has its own independent means of liveness detection (typically, control protocols) 💜
If a client does not have any independent means of liveness detection, a system SHOULD indicate a connectivity failure to the client and assume the semantics of Down state if either the local or remote session state transitions to AdminDown. Otherwise, the client won't be able to figure out whether the path is viable, and unfortunate results may occur 💀
3.3. Hitless Establishment/Reestablishment of BFD State 🎀
It's really useful to be able to configure a BFD session between a pair of systems without affecting the state of any clients associated with that session. Similarly, it's useful for BFD state to be reestablished without disturbing associated clients when all BFD state gets lost (like in process restart situations). This ties into the clients' ability to establish their state independently of BFD 🌈
The BFD state machine transitions that happen while bringing up a BFD session in these situations SHOULD NOT cause a connectivity failure notification to the clients 🔥
A client that is able to establish its state before the BFD session is configured or restarted MAY do so if that's appropriate. How to do that is outside the scope of this specification 👑
Part 1 of 4 is done, bestie 🥹 Keep an eye out for the next part, because the good stuff (control protocol interactions) is coming up next 💖
4. Control Protocol Interactions ✨
okay so the big reason BFD is a thing is control protocols, like routing protocols 🛣️. when BFD and a control protocol work together, the control protocol gets told "hey, the data path is dead," so it can reroute traffic around the broken path WAY faster than its own native detection would. main character energy fr 💅
4.1. Adjacency Establishment
if the session state on either the local or remote system (when it's known) is AdminDown, that means BFD has been administratively turned off. in that case, the control protocol adjacency MUST be allowed to come up 🫶.
BFD sessions are usually bootstrapped by the control protocol itself, using whatever mechanism (discovery, configuration) it already uses to find its neighbors 🔍. ngl there's a sneaky failure case here: the network can be in a state where the control protocol comes up just fine, but the BFD session can't be established, so data can't actually be forwarded 💀. to dodge that, it would be beneficial to not let the control protocol form a neighbor adjacency at all. the catch is that this would also stop the control protocol from working in an environment where not every system supports BFD 😭.
so the establishment of control protocol adjacencies SHOULD be blocked if both systems are willing to establish a BFD session but a BFD session cannot be established. one way to know both systems are willing is if the control protocol explicitly signals it 🙌. if there's no explicit signaling, the willingness to establish a BFD session may be determined by means outside the scope of this specification.
if it's believed the neighboring system doesn't support BFD, the establishment of a control protocol adjacency SHOULD NOT be blocked 🌸.
the setting of BFD's timing parameters and modes is not subject to standardization. note that all protocols sharing a session will operate using the same parameters. the mechanism for choosing the parameters among those desired by the various protocols is outside the scope of this specification. it's generally useful to choose the parameters that give the shortest Detection Time, and a particular client application can always apply hysteresis to the notifications from BFD if it wants longer Detection Times 🧚.
one more tea ☕: many control protocols assume full connectivity between all systems on multiaccess media, like LANs. if BFD runs on only a subset of systems on that kind of network, and adjacency establishment gets blocked by the absence of a BFD session, the control protocol's assumptions may be violated, with unpredictable results 💀.
4.2. Reaction to BFD Session State Changes
if a BFD session goes from Up to AdminDown, or goes from Up to Down because the remote system is indicating AdminDown, clients SHOULD NOT take any control protocol action. not me doing extra work when someone just turned BFD off on purpose 🙅♀️.
for other Up-to-Down transitions, how the control protocol reacts to a path failure signaled by BFD depends on what that protocol can do, as covered in the subsections below 🎀.
4.2.1. Control Protocols with a Single Data Protocol
a control protocol that's tightly bound to a single failing data protocol SHOULD take action to make sure data traffic is no longer directed to the failing path. quick heads up though: this should not be read as BFD replacing the control protocol's liveness mechanism (if it has one). the control protocol may rely on mechanisms BFD doesn't verify, like multicast, so BFD most likely can't detect every failure that would impact the control protocol 🙈. BUT a control protocol MAY choose to use BFD session state to spot an impending control protocol failure more quickly, especially if the control protocol runs in-band over the data protocol ✨.
so when a BFD session transitions from Up to Down, action SHOULD be taken in the control protocol to signal the lack of connectivity for the path BFD is running over. if the control protocol has an explicit mechanism for announcing path state, a system SHOULD use that mechanism instead of hurting the control protocol's own connectivity, especially when the control protocol runs out-of-band from the failed data protocol 💖. if no such mechanism is available, a control protocol timeout SHOULD be emulated for the associated neighbor.
4.2.2. Control Protocols with Multiple Data Protocols
slightly different mechanisms apply if the control protocol supports routing multiple data protocols. it depends on whether the control protocol supports separate topologies for each data protocol 🌈.
4.2.2.1. Shared Topologies
with a shared topology, if one of the data protocols fails (as signaled by its BFD session), the path has to be considered failed for all data protocols. otherwise the control protocol has no way to turn away traffic for the failed data protocol, and that traffic would get black-holed indefinitely 🕳️😭.
so when a BFD session transitions from Up to Down, action SHOULD be taken in the control protocol to signal the lack of connectivity for the path in the topology that matches the BFD session. if this can't be signaled any other way, a control protocol timeout SHOULD be emulated for the associated neighbor.
4.2.2.2. Independent Topologies
with separate routing topologies for each data protocol, only the failed data protocol needs to be rerouted around the failed path 🦋.
so when a BFD session transitions from Up to Down, action SHOULD be taken in the control protocol to signal the lack of connectivity for the path in the topology the BFD session runs over. generally this can be done without impacting the connectivity of the other topologies, because otherwise it's super hard to support separate topologies for multiple data protocols 🧠.
4.3. Interactions with Graceful Restart Mechanisms
a bunch of control protocols support Graceful Restart mechanisms, including IS-IS [ISIS-GRACE], OSPF [OSPF-GRACE], and BGP [BGP-GRACE]. these are designed so a control protocol can restart without disturbing the network's connectivity state, because otherwise it would look like the whole system (and/or all of its links) had failed 😱. they're built on the idea of a separate forwarding plane that doesn't necessarily share fate with the control plane where the routing protocols live. basically, the assumption is that the forwarding plane keeps working while the protocols restart and sort things out 🫧.
BFD implementations announce, via the Control Plane Independent "C" bit, whether or not BFD shares fate with the control plane. that info is used to decide what to do alongside Graceful Restart. if BFD does not share fate with the control plane on either system, it can be used to figure out whether Graceful Restart in a control protocol is not viable (because the forwarding plane isn't operating) 🚫.
if the control protocol has a Graceful Restart mechanism, BFD may be used in conjunction with it. the interaction between BFD and the control protocol depends on the control protocol's capabilities and on whether BFD shares fate with the control plane. in particular, it may be desirable for a BFD session failure to abort the Graceful Restart process and let the failure be visible to the network 👀.
4.3.1. BFD Fate Independent of the Control Plane
if BFD is implemented in the forwarding plane and does not share fate with the control plane on either system (the "C" bit is set in the BFD Control packets in both directions), control protocol restarts should not affect the BFD session. in this case, a BFD session failure means data can no longer be forwarded, so any Graceful Restart in progress at the time of the failure SHOULD be aborted to avoid black holes, and a topology change SHOULD be signaled in the control protocol 🍓.
4.3.2. BFD Shares Fate with the Control Plane
if BFD shares fate with the control plane on either system (the "C" bit is clear in either direction), a BFD session failure can't be untangled from other events happening in the control plane. in lots of cases, the BFD session fails as a side effect of the restart taking place 🌀. so it would be best to avoid aborting any Graceful Restart that's happening, if possible (since otherwise BFD and Graceful Restart can't coexist) 🤝.
there's some risk in doing this, since a simultaneous failure or restart of the forwarding plane won't be detected. but that's always an issue when BFD shares fate with the control plane 😬.
4.3.2.1. Control Protocols with Planned Restart Signaling
some control protocols can signal a planned restart before the restart happens. in that case, if a BFD session failure occurs during the restart, such a planned restart SHOULD NOT be aborted, and the session failure SHOULD NOT result in a topology change being signaled in the control protocol 💅✨.
4.3.2.2. Control Protocols without Planned Restart Signaling
control protocols that can't signal a planned restart depend on the recently restarted system to signal the Graceful Restart before the control protocol adjacency timeout. in most cases, whether the restart is planned or unplanned, the BFD session will time out before the Graceful Restart starts. in that case, a topology change SHOULD be signaled in the control protocol as specified in Section 3.2 🫠.
however, if the restart is actually planned, an implementation MAY adjust the BFD session timing parameters before restarting, so that the Detection Time in each direction is longer than the restart period of the control protocol. that gives the restarting system the same chance to enter Graceful Restart as it would have had without BFD 🙌. the restarting system SHOULD NOT send any BFD Control packets until there's a high likelihood that its neighbors know a Graceful Restart is taking place, because the first BFD Control packet will cause the BFD session to fail 🚨.
4.4. Interactions with Multiple Control Protocols
if multiple control protocols want to establish BFD sessions with the same remote system for the same data protocol, they all MUST share a single BFD session 🫶🔥.
if hierarchical or dependent layers of control protocols are in use (say, OSPF and Internal BGP (IBGP)), it may not be useful for more than one of them to interact with BFD. in this example, IBGP depends on OSPF for its routing information, so the faster failure detection relayed to IBGP may actually be detrimental. the cost of a peer state transition is high in BGP, and OSPF will naturally heal the path through the network if it were to receive the failure detection itself 🧩.
in general, it's best for the protocol at the lowest point in the hierarchy to interact with BFD, and then use the existing interactions between the control protocols to make changes as necessary. this gives the fastest possible failure detection and recovery in a network 🏆✨.
5. Interactions with Non-Protocol Functions ✨
okay so BFD session status doesn't only have to talk to protocols 🙈 it can also change other system stuff that isn't protocol based, like static routes 🛣️ if the path to a remote system dies, you probably don't want to keep sending traffic into that black hole 🕳️ so the local system can take internal steps to make that happen, like pulling a static route and pulling that route out of routing protocols too 💅
if the remote system is known (or presumed) to be BFD capable and the BFD session is not in Up state, appropriate action SHOULD be taken, like withdrawing a static route 💖
if the remote system is known (or presumed) to not support BFD, then action like withdrawing a static route SHOULD NOT be taken 🙅♀️ no sudden moves on a system that can't even tell you what's up 😭
bootstrapping a BFD session in the non-protocol case is most likely going to come from configuration info 🧚
and honestly? there's no need to swap endpoints or discriminator values through any mechanism other than configuration (Operational Support Systems or any other means) 🎀 the endpoints have to be known and configured by the same means anyway, so it's giving "just configure it, bestie" 💜
6. Data Protocols and Demultiplexing 🦋
BFD is meant to protect a single "data protocol" 💅 and it gets encapsulated inside that protocol. a pair of systems can have multiple BFD sessions over the same topology as long as they support (and are encapsulated by) different protocols 🌈 for example, if two systems are running IPv4 and IPv6 across the same link, those count as two separate paths, so they need two separate BFD sessions 👑 two lanes, two sessions, no mixing 🚗
the same trick works for more fine-grained paths too ✨ like, if multiple differentiated services [DIFFSERV] are running over IPv4, you can run an independent BFD session for each service level 🍓
the BFD Control packets must be marked in the same way as the data packets 🔥 partly so BFD and data traffic share as much fate as possible, and partly so the initial packet can be demultiplexed if the discriminator values haven't been exchanged yet 🫶
7. Multiple Link Subnetworks 🌸
there are a bunch of technologies that bundle multiple parallel links at layer N-1 and treat them like one single link at layer N 🧩 BFD can protect the path at layer N in a bunch of different ways 🦋 the exact mechanism is outside the scope of this specification, but this section gives some examples of possible deployment scenarios 💅 other scenarios are totally possible too, and they aren't ruled out 💖
7.1. Complete Decoupling 🫧
the simplest approach is to just run BFD over the layer N path, with zero interaction with the layer N-1 mechanisms 😌 this assumes the layer N-1 mechanism will handle connectivity issues in individual layer N-1 links, so BFD only declares a failure in the layer N path when the session times out ⏰
this approach works whether or not the layer N-1 neighbor is the same as the layer N neighbor 🙌
7.2. Layer N-1 Hints 💡
a slightly more intelligent approach than complete decoupling is to have the layer N-1 mechanism tell the layer N BFD when the aggregated link is no longer viable 🚨 then the BFD session can detect the failure way faster, because it doesn't have to wait for the session to time out 🏃♀️ this is basically like triggering a session failure based on a hardware-detected failure of a single link 🔧
this approach also works whether or not the layer N-1 neighbor is the same as the layer N neighbor 🥰
7.3. Aggregating BFD Sessions 🧁
another option is to run BFD on each layer N-1 link and then aggregate the state of those multiple sessions into a single indication for the layer N clients 🎀 the big perk is that it doesn't care what layer N-1 technology you're using 🙌 BUT (ngl this is the catch 😬) this only works if the layer N neighbor is the same as the layer N-1 neighbor, meaning a single hop at layer N-1 💅
7.4. Combinations of Scenarios 🍭
you can mix more than one of the scenarios above (or others) and it can be super useful in some cases 🧠 for example, if the layer N neighbor isn't directly connected at layer N-1, a system might run a BFD session across each layer N-1 link to the immediate layer N-1 neighbor, and then run another BFD session to the layer N neighbor 🪜 the aggregate state of those layer N-1 BFD sessions could be used to trigger a layer N BFD session failure 💜
8. Other Application Issues 🌷
BFD can provide liveness detection for Operations, Administration, and Maintenance (OAM) functions in tunneling and pseudowire protocols 🛠️ running BFD inside the tunnel is recommended, because it exercises more aspects of the path 🌈 one way to make that work is to address BFD packets based on the tunnel endpoints, assuming they're numbered 🔢
if a planned outage is going to happen on a path where BFD is running, it's better to take the BFD session down by going into AdminDown state before the outage 🚧 the system asserting AdminDown SHOULD do so for at least one Detection Time, so the remote system actually knows about it 📣
similarly, if BFD is being deconfigured from a system, you really don't want to set off any client application action 😩 if you just stop sending BFD Control packets, the remote system will detect a session failure, and we don't want that drama 🙃 to avoid it, the system deconfiguring BFD SHOULD put the session into AdminDown state and keep that state for a Detection Time so the remote system is aware of it 🫶
9. Interoperability Issues 🤝
the BFD protocol itself is designed so it will always interoperate at a basic level ✨ asynchronous mode is mandatory and always available, and other modes and functions get negotiated at run time 🧑🤝🧑 since the service BFD provides is identical no matter which variants are used, the particular choice of BFD options has no bearing on interoperability 💅
the interaction between BFD and other protocols and control functions is very loosely coupled 🧶 the actions taken are based on mechanisms that already exist in those protocols and functions, so interoperability problems are very unlikely unless BFD gets applied in contradictory ways 😵💫 (like a BFD session failure making one implementation go down while another implementation comes up, which is a whole mess 🙈) in fact, BFD might be advising one system for a particular control function but not the other 🤔 the only impact of that would be potentially asymmetric control protocol failure detection 🪞
10. Specific Protocol Interactions (Non-Normative) 📚
as mentioned above, there are no interoperability concerns regarding interactions between BFD and control protocols 💖 but there's enough concern and confusion in this area that it's worth giving examples of interactions with specific protocols 🫠
since these interactions don't affect interoperability, they're non-normative 🧾
10.1. BFD Interactions with OSPFv2, OSPFv3, and IS-IS 🛤️
both versions of OSPF ([OSPFv2] and [OSPFv3]), as well as IS-IS [ISIS], have the same architectural limitation 😤 their Hello protocols are limited in the granularity of their failure detection times 🐢 specifically, OSPF has a minimum detection time of two seconds, and IS-IS has a minimum detection time of one second ⏱️
BFD can achieve arbitrarily small detection times for these protocols by supplementing the Hello protocols used in each case 🚀
10.1.1. Session Establishment 🌱
the most obvious choice for triggering BFD session establishment with these protocols is to use the discovery mechanism that's built into the Hello protocols in OSPF and IS-IS to bootstrap the BFD session 🥾 any BFD sessions set up to support OSPF and IS-IS across a single IP hop must operate in accordance with [BFD-1HOP] 📏
10.1.2. Reaction to BFD State Changes 🎢
the basic mechanisms are covered in Section 3 above 📖 right now, OSPFv2 and OSPFv3 carry routing information for a single data protocol (IPv4 and IPv6, respectively), so when you want to signal a topology change after a BFD session failure, you should do that by tearing down the corresponding OSPF neighbor 💥
IS-IS can support only one data protocol, or multiple data protocols 🎭 [ISIS] specifies a common topology for multiple data protocols, but work is underway to support multiple topologies 🛠️ if multiple topologies are used to support multiple data protocols (or multiple classes of service of the same data protocol), the topology-specific path tied to a failing BFD session should no longer be advertised in IS-IS Label Switched Paths (LSPs) to signal a lack of connectivity 🙅♀️ otherwise, a failing BFD session should be signaled by simulating an IS-IS adjacency failure 🎬
OSPF has a planned restart signaling mechanism, but IS-IS doesn't 🥲 the appropriate mechanisms outlined in Section 3.3 should be used 📋
10.1.3. OSPF Virtual Links 🔗
if you want to use BFD for failure detection of OSPF Virtual Links, the mechanism described in [BFD-MULTI] MUST be used, because OSPF Virtual Links can traverse an arbitrary number of hops 🌍 BFD authentication SHOULD be used, and it's strongly encouraged 🔐
10.2. Interactions with BGP 🌐
BFD may be useful with External Border Gateway Protocol (EBGP) sessions [BGP] to more rapidly trigger topology changes when a path fails 🏎️ as noted in Section 4.4, it's generally unwise for IBGP sessions to interact with BFD if the underlying IGP is already doing so 🙃
EBGP sessions being advised by BFD may establish either a one-hop [BFD-1HOP] or a multihop [BFD-MULTI] session, depending on whether or not the neighbor is immediately adjacent 📍 the BFD session should be established to the BGP neighbor (as opposed to any other Next Hop advertised in BGP) 🎯 BFD authentication SHOULD be used, and it's strongly encouraged 🔒
[BGP-GRACE] describes a Graceful Restart mechanism for BGP 🌷 if Graceful Restart isn't taking place on an EBGP session and the corresponding BFD session fails, the EBGP session should be torn down in accordance with Section 3.2 💔 if Graceful Restart is taking place, the basic procedures in Section 4.3 apply 📜 BGP Graceful Restart doesn't signal planned restarts, so Section 4.3.2.2 applies 🧾 and if Graceful Restart is aborted due to the rules described in Section 4.3, the "receiving speaker" should act as if the "restart timer" expired (as described in [BGP-GRACE]) ⏳
10.3. Interactions with RIP 🪄
the Routing Information Protocol (RIP) [RIP] is kinda unique in that, at least as specified, neighbor adjacency state isn't stored per se 🧐 instead, installed routes contain a next hop address, which in most cases is the address of the advertising neighbor (but it may not be) 📬
with RIP, when the BFD session associated with a neighbor fails, an expiration of the "timeout" timer for each route installed from that neighbor (for which the neighbor is the next hop) should be simulated ⏰
ngl, here's the sneaky part 👀 if a BFD session fails, and a route is received from that neighbor with a next hop address that isn't the address of the neighbor itself, the route will linger until it naturally times out (after 180 seconds) 😱 however, if an implementation keeps track of all of the routes received from each neighbor, then all of the routes from the neighbor corresponding to the failed BFD session should be timed out, regardless of the next hop specified in them, and that avoids the lingering route problem 🧹✨
11. Security Considerations ✨
okay bestie, the security part is actually short and sweet 🔒 this spec doesn't add any new security issues of its own. Whatever security stuff applies comes from the specs it leans on in the normative references, so those are the ones to go check 🫶
12. References 📚
12.1. Normative References
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", RFC 5880, June 2010. 💖
[BFD-1HOP] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010. 🦋
[BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010. 🌸
[BFD-MULTI] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, June 2010. 🧚
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 👑
12.2. Informative References
[BGP] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. 🌈
[BGP-GRACE] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, January 2007. ⭐
[DIFFSERV] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. 🍓
[ISIS] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. 🫶
[ISIS-GRACE] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", RFC 5306, October 2008. 💅
[OSPFv2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 🔥
[OSPFv3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. ✨
[OSPF-GRACE] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003. 🎀
[RIP] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998. 💜
Authors' Addresses 🎀
Dave Katz
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089-1206
USA
Phone: +1-408-745-2000
EMail: dkatz@juniper.net
Dave Ward
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089-1206
USA
Phone: +1-408-745-2000
EMail: dward@juniper.net📦 where this page comes from
- ietf: rfc5882 2010-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms