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/rfc5882.txt | 955 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 955 insertions(+) create mode 100644 doc/rfc/rfc5882.txt (limited to 'doc/rfc/rfc5882.txt') diff --git a/doc/rfc/rfc5882.txt b/doc/rfc/rfc5882.txt new file mode 100644 index 0000000..2664442 --- /dev/null +++ b/doc/rfc/rfc5882.txt @@ -0,0 +1,955 @@ + + + + + + +Internet Engineering Task Force (IETF) D. Katz +Request for Comments: 5882 D. Ward +Category: Standards Track Juniper Networks +ISSN: 2070-1721 June 2010 + + + Generic Application of Bidirectional Forwarding Detection (BFD) + +Abstract + + This document describes the generic application of the Bidirectional + Forwarding Detection (BFD) protocol. + +Status of This Memo + + 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 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/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 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. + + + + + + + + + + +Katz & Ward Standards Track [Page 1] + +RFC 5882 Generic Application of BFD June 2010 + + +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 ...................................16 + + + + + + + + + + + + + +Katz & Ward Standards Track [Page 2] + +RFC 5882 Generic Application of BFD June 2010 + + +1. Introduction + + The Bidirectional Forwarding Detection [BFD] protocol provides a + liveness detection mechanism that can be utilized by other network + components for which their integral liveness mechanisms are either + too slow, inappropriate, or nonexistent. Other documents have + detailed the use of BFD with specific encapsulations ([BFD-1HOP] + [BFD-MULTI] [BFD-MPLS]). As the utility of BFD has become + understood, there have been calls to specify BFD interactions with a + growing list of network functions. Rather than producing a long + series of short documents on the application of BFD, it seemed + worthwhile to describe the interactions between BFD and other network + functions ("BFD clients") in a broad way. + + This document describes the generic application of BFD. Specific + protocol applications are provided for illustrative purposes. + +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 Bidirectional Forwarding Detection (BFD) specification defines a + protocol with simple and specific semantics. Its sole purpose is to + verify connectivity between a pair of systems, for a particular data + protocol across a path (which may be of any technology, length, or + OSI layer). The promptness of the detection of a path failure can be + controlled by trading off protocol overhead and system load with + detection times. + + BFD is *not* intended to directly provide control protocol liveness + information; those protocols have their own means and vagaries. + Rather, control protocols can use the services provided by BFD to + inform their operation. BFD can be viewed as a service provided by + the layer in which it is running. + + The service interface with BFD is straightforward. The application + supplies session parameters (neighbor address, time parameters, + protocol options), and BFD provides the session state, of which the + most interesting transitions are to and from the Up state. The + application is expected to bootstrap the BFD session, as BFD has no + discovery mechanism. + + + + + + +Katz & Ward Standards Track [Page 3] + +RFC 5882 Generic Application of BFD June 2010 + + + An implementation SHOULD establish only a single BFD session per data + protocol path, regardless of the number of applications that wish to + utilize it. There is no additional value in having multiple BFD + sessions to the same endpoints. If multiple applications request + different session parameters, it is a local issue as to how to + resolve the parameter conflicts. BFD in turn will notify all + applications bound to a session when a session state change occurs. + + BFD should be viewed as having an advisory role to the protocol or + protocols or other network functions with which it is interacting, + which will then use their own mechanisms to effect 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, partly for + architectural reasons and partly because BFD may have curious and + unpredictable latency characteristics and as such makes a poor + transport mechanism. + + It is important to remember that the interaction between BFD and its + client applications has essentially no interoperability issues, + because BFD is acting in an advisory nature (similar to hardware + signaling the loss of light on a fiber optic circuit, for example) + and existing mechanisms in the client applications are 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 is + outside the scope of this specification. However, it is useful to + describe some mechanisms that implementors may use in order to + promote full-featured implementations. One way of modeling this + interaction is to create an adaptation layer between the BFD state + machine and the client applications. The adaptation layer is + cognizant 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 cause signaling to + the clients to take failure action. However, in some cases, this may + not always be the best course of action. + + + + + + +Katz & Ward Standards Track [Page 4] + +RFC 5882 Generic Application of BFD June 2010 + + + Implementors may choose to hide rapid Up/Down/Up transitions of the + BFD session from its clients. This is useful in order to support + process restarts without necessitating complex protocol mechanisms, + for example. + + As such, a system MAY choose not to notify clients if a BFD session + transitions from Up to Down state, and returns to Up state, if 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 state 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 intended to signal that the BFD + session is being taken down for administrative purposes, and the + session state is not indicative of the liveness of the data path. + + Therefore, 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, so long as that client has + 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 a + client, and assume the semantics of Down state, if either the local + or remote session state transitions to AdminDown. Otherwise, the + client will not be able to determine whether the path is viable, and + unfortunate results may occur. + +3.3. Hitless Establishment/Reestablishment of BFD State + + It is useful to be able to configure a BFD session between a pair of + systems without impacting the state of any clients that will be + associated with that session. Similarly, it is useful for BFD state + to be reestablished without perturbing associated clients when all + BFD state is lost (such as in process restart situations). This + interacts with the clients' ability to establish their state + independent of BFD. + + The BFD state machine transitions that occur in the process of + bringing up a BFD session in such situations SHOULD NOT cause a + connectivity failure notification to the clients. + + + + + + + +Katz & Ward Standards Track [Page 5] + +RFC 5882 Generic Application of BFD June 2010 + + + A client that is capable of establishing its state prior to the + configuration or restarting of a BFD session MAY do so if + appropriate. The means to do so is outside of the scope of this + specification. + +4. Control Protocol Interactions + + Very common client applications of BFD are control protocols, such as + routing protocols. The object, when BFD interacts with a control + protocol, is to advise the control protocol of the connectivity of + the data protocol. In the case of routing protocols, for example, + this allows the connectivity failure to trigger the rerouting of + traffic around the failed path more quickly than the native detection + mechanisms. + +4.1. Adjacency Establishment + + If the session state on either the local or remote system (if known) + is AdminDown, BFD has been administratively disabled, and the + establishment of a control protocol adjacency MUST be allowed. + + BFD sessions are typically bootstrapped by the control protocol, + using the mechanism (discovery, configuration) used by the control + protocol to find neighbors. Note that it is possible in some failure + scenarios for the network to be in a state such that the control + protocol is capable of coming up, but the BFD session cannot be + established, and, more particularly, data cannot be forwarded. To + avoid this situation, it would be beneficial not to allow the control + protocol to establish a neighbor adjacency. However, this would + preclude the operation of the control protocol in an environment in + which not all systems support BFD. + + Therefore, 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 method for determining that + both systems are willing to establish a BFD session is if the control + protocol carries explicit signaling of this fact. If there is no + explicit signaling, the willingness to establish a BFD session may be + determined by means outside the scope of this specification. + + If it is believed that the neighboring system does not support BFD, + the establishment of a control protocol adjacency SHOULD NOT be + blocked. + + The setting of BFD's various timing parameters and modes are 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 + + + +Katz & Ward Standards Track [Page 6] + +RFC 5882 Generic Application of BFD June 2010 + + + is outside the scope of this specification. It is generally useful + to choose the parameters resulting in the shortest Detection Time; a + particular client application can always apply hysteresis to the + notifications from BFD if it desires longer Detection Times. + + Note that many control protocols assume full connectivity between all + systems on multiaccess media such as LANs. If BFD is running on only + a subset of systems on such a network, and adjacency establishment is + blocked by the absence of a BFD session, the assumptions of the + control protocol may be violated, with unpredictable results. + +4.2. Reaction to BFD Session State Changes + + If a BFD session transitions from Up state to AdminDown, or the + session transitions from Up to Down because the remote system is + indicating that the session is in state AdminDown, clients SHOULD NOT + take any control protocol action. + + For other transitions from Up to Down state, the mechanism by which + the control protocol reacts to a path failure signaled by BFD depends + on the capabilities of the protocol, as specified in the following + subsections. + +4.2.1. Control Protocols with a Single Data Protocol + + A control protocol that is tightly bound to a single failing data + protocol SHOULD take action to ensure that data traffic is no longer + directed to the failing path. Note that this should not be + interpreted as BFD replacing the control protocol liveness mechanism, + if any, as the control protocol may rely on mechanisms not verified + by BFD (multicast, for instance) so BFD most likely cannot detect all + failures that would impact the control protocol. However, a control + protocol MAY choose to use BFD session state information to more + rapidly detect an impending control protocol failure, particularly if + the control protocol operates in-band (over the data protocol). + + Therefore, 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 over which BFD is running. If the control + protocol has an explicit mechanism for announcing path state, a + system SHOULD use that mechanism rather than impacting the + connectivity of the control protocol, particularly if the control + protocol operates out-of-band from the failed data protocol. + However, if such a mechanism is not available, a control protocol + timeout SHOULD be emulated for the associated neighbor. + + + + + + +Katz & Ward Standards Track [Page 7] + +RFC 5882 Generic Application of BFD June 2010 + + +4.2.2. Control Protocols with Multiple Data Protocols + + Slightly different mechanisms are used if the control protocol + supports the routing of multiple data protocols, depending 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 the associated BFD session), it is necessary to consider + the path to have failed for all data protocols. Otherwise, there is + no way for the control protocol to turn away traffic for the failed + data protocol (and such traffic would be black-holed indefinitely). + + Therefore, 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 corresponding to the BFD + session. If this cannot be signaled otherwise, a control protocol + timeout SHOULD be emulated for the associated neighbor. + +4.2.2.2. Independent Topologies + + With individual routing topologies for each data protocol, only the + failed data protocol needs to be rerouted around the failed path. + + Therefore, 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 over which BFD is running. + Generally, this can be done without impacting the connectivity of + other topologies (since otherwise it is very difficult to support + separate topologies for multiple data protocols). + +4.3. Interactions with Graceful Restart Mechanisms + + A number of control protocols support Graceful Restart mechanisms, + including IS-IS [ISIS-GRACE], OSPF [OSPF-GRACE], and BGP [BGP-GRACE]. + These mechanisms are designed to allow a control protocol to restart + without perturbing network connectivity state (lest it appear that + the system and/or all of its links had failed). They are predicated + on the existence of a separate forwarding plane that does not + necessarily share fate with the control plane in which the routing + protocols operate. In particular, the assumption is that the + forwarding plane can continue to function 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. This + + + +Katz & Ward Standards Track [Page 8] + +RFC 5882 Generic Application of BFD June 2010 + + + information is used to determine the actions to be taken in + conjunction with Graceful Restart. If BFD does not share its fate + with the control plane on either system, it can be used to determine + whether Graceful Restart in a control protocol is NOT viable (the + forwarding plane is not operating). + + If the control protocol has a Graceful Restart mechanism, BFD may be + used in conjunction with this mechanism. The interaction between BFD + and the control protocol depends on the capabilities of the control + protocol and whether or not 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 allow the failure to 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 implies that data can no longer be forwarded, so any Graceful + Restart in progress at the time of the BFD session failure SHOULD be + aborted in order 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 cannot be + disentangled from other events taking place in the control plane. In + many cases, the BFD session will fail as a side effect of the restart + taking place. As such, it would be best to avoid aborting any + Graceful Restart taking place, if possible (since otherwise BFD and + Graceful Restart cannot coexist). + + There is some risk in doing so, since a simultaneous failure or + restart of the forwarding plane will not be detected, but this is + 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 prior to the + restart taking place. In this 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. + + + + + +Katz & Ward Standards Track [Page 9] + +RFC 5882 Generic Application of BFD June 2010 + + +4.3.2.2. Control Protocols without Planned Restart Signaling + + Control protocols that cannot signal a planned restart depend on the + recently restarted system to signal the Graceful Restart prior to the + control protocol adjacency timeout. In most cases, whether the + restart is planned or unplanned, it is likely that the BFD session + will time out prior to the onset of Graceful Restart, in which case a + topology change SHOULD be signaled in the control protocol as + specified in Section 3.2. + + However, if the restart is in fact planned, an implementation MAY + adjust the BFD session timing parameters prior to restarting in such + a way that the Detection Time in each direction is longer than the + restart period of the control protocol, providing the restarting + system the same opportunity to enter Graceful Restart as it would + have without BFD. The restarting system SHOULD NOT send any BFD + Control packets until there is a high likelihood that its neighbors + know a Graceful Restart is taking place, as the first BFD Control + packet will cause the BFD session to fail. + +4.4. Interactions with Multiple Control Protocols + + If multiple control protocols wish to establish BFD sessions with the + same remote system for the same data protocol, 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, because IBGP + is dependent on OSPF for its routing information, 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. + + In general, it is best for the protocol at the lowest point in the + hierarchy to interact with BFD, and then to use existing interactions + between the control protocols to effect changes as necessary. This + will provide the fastest possible failure detection and recovery in a + network. + +5. Interactions with Non-Protocol Functions + + BFD session status may be used to affect other system functions that + are not protocol based (for example, static routes). If the path to + a remote system fails, it may be desirable to avoid passing traffic + + + + + +Katz & Ward Standards Track [Page 10] + +RFC 5882 Generic Application of BFD June 2010 + + + to that remote system, so the local system may wish to take internal + measures to accomplish this (such as withdrawing a static route and + withdrawing that route from routing protocols). + + If it is known, or presumed, that the remote system is BFD capable + and the BFD session is not in Up state, appropriate action SHOULD be + taken (such as withdrawing a static route). + + If it is known, or presumed, that the remote system does not support + BFD, action such as withdrawing a static route SHOULD NOT be taken. + + Bootstrapping of the BFD session in the non-protocol case is likely + to be derived from configuration information. + + There is no need to exchange endpoints or discriminator values via + any mechanism other than configuration (via Operational Support + Systems or any other means) as the endpoints must be known and + configured by the same means. + +6. Data Protocols and Demultiplexing + + BFD is intended to protect a single "data protocol" and is + encapsulated within that protocol. A pair of systems may have + multiple BFD sessions over the same topology if they support (and are + encapsulated by) different protocols. For example, if two systems + have IPv4 and IPv6 running across the same link between them, these + are considered two separate paths and require two separate BFD + sessions. + + This same technique is used for more fine-grained paths. For + example, if multiple differentiated services [DIFFSERV] are being + operated over IPv4, an independent BFD session may be run for each + service level. The BFD Control packets must be marked in the same + way as the data packets, partly to ensure as much fate sharing as + possible between BFD and data traffic, and also to demultiplex the + initial packet if the discriminator values have not been exchanged. + +7. Multiple Link Subnetworks + + A number of technologies exist for aggregating multiple parallel + links at layer N-1 and treating them as a single link at layer N. + BFD may be used in a number of ways to protect the path at layer N. + The exact mechanism used is outside the scope of this specification. + However, this section provides examples of some possible deployment + scenarios. Other scenarios are possible and are not precluded. + + + + + + +Katz & Ward Standards Track [Page 11] + +RFC 5882 Generic Application of BFD June 2010 + + +7.1. Complete Decoupling + + The simplest approach is to simply run BFD over the layer N path, + with no interaction with the layer N-1 mechanisms. Doing so assumes + that the layer N-1 mechanism will deal with connectivity issues in + individual layer N-1 links. BFD will declare a failure in the layer + N path only when the session times out. + + This approach will work 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 inform the layer N BFD when the + aggregated link is no longer viable. In this case, the BFD session + will detect the failure more rapidly, as it need not wait for the + session to time out. This is analogous to triggering a session + failure based on the hardware-detected failure of a single link. + + This approach will also work whether or not the layer N-1 neighbor is + the same as the layer N neighbor. + +7.3. Aggregating BFD Sessions + + Another approach would be to use BFD on each layer N-1 link and to + aggregate the state of the multiple sessions into a single indication + to the layer N clients. This approach has the advantage that it is + independent of the layer N-1 technology. However, this approach only + works if the layer N neighbor is the same as the layer N-1 neighbor + (a single hop at layer N-1). + +7.4. Combinations of Scenarios + + Combinations of more than one of the scenarios listed above (or + others) may be useful in some cases. For example, if the layer N + neighbor is not 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 the layer N-1 BFD sessions could be used to + trigger a layer N BFD session failure. + + + + + + + + + + +Katz & Ward Standards Track [Page 12] + +RFC 5882 Generic Application of BFD June 2010 + + +8. Other Application Issues + + BFD can provide liveness detection for functions related to + Operations, Administration, and Maintenance (OAM) in tunneling and + pseudowire protocols. Running BFD inside the tunnel is recommended, + as it exercises more aspects of the path. One way to accommodate + this is to address BFD packets based on the tunnel endpoints, + assuming that they are numbered. + + If a planned outage is to take place on a path over which BFD is run, + it is preferable to take down the BFD session by going into AdminDown + state prior to the outage. The system asserting AdminDown SHOULD do + so for at least one Detection Time in order to ensure that the remote + system is aware of it. + + Similarly, if BFD is to be deconfigured from a system, it is + desirable not to trigger any client application action. Simply + ceasing the transmission of BFD Control packets will cause the remote + system to detect a session failure. In order to avoid this, the + system on which BFD is being deconfigured SHOULD put the session into + AdminDown state and maintain this state for a Detection Time to + ensure that the remote system is aware of it. + +9. Interoperability Issues + + The BFD protocol itself is designed so that it will always + interoperate at a basic level; asynchronous mode is mandatory and is + always available, and other modes and functions are negotiated at run + time. Since the service provided by BFD is identical regardless of + the variants 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 existing + mechanisms in those protocols and functions, so interoperability + problems are very unlikely unless BFD is applied in contradictory + ways (such as a BFD session failure causing one implementation to go + down and another implementation to come up). In fact, BFD may be + advising one system for a particular control function but not the + other; the only impact of this would be potentially asymmetric + control protocol failure detection. + +10. Specific Protocol Interactions (Non-Normative) + + As noted above, there are no interoperability concerns regarding + interactions between BFD and control protocols. However, there is + enough concern and confusion in this area so that it is worthwhile to + provide examples of interactions with specific protocols. + + + +Katz & Ward Standards Track [Page 13] + +RFC 5882 Generic Application of BFD June 2010 + + + Since the interactions do not affect interoperability, they are non- + normative. + +10.1. BFD Interactions with OSPFv2, OSPFv3, and IS-IS + + The two versions of OSPF ([OSPFv2] and [OSPFv3]), as well as IS-IS + [ISIS], all suffer from an architectural limitation, namely that + their Hello protocols are limited in the granularity of their failure + detection times. In particular, OSPF has a minimum detection time of + two seconds, and IS-IS has a minimum detection time of one second. + + BFD may be used to 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 would be to use the discovery mechanism inherent in + the Hello protocols in OSPF and IS-IS to bootstrap the establishment + of the BFD session. Any BFD sessions established 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. At this time, + OSPFv2 and OSPFv3 carry routing information for a single data + protocol (IPv4 and IPv6, respectively) so when it is desired to + signal a topology change after a BFD session failure, this should be + done by tearing down the corresponding OSPF neighbor. + + IS-IS may be used to support only one data protocol, or multiple data + protocols. [ISIS] specifies a common topology for multiple data + protocols, but work is under way 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 associated with a failing BFD session should no longer + be advertised in IS-IS Label Switched Paths (LSPs) in order 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, whereas IS-IS does + not. The appropriate mechanisms outlined in Section 3.3 should be + used. + + + + + + +Katz & Ward Standards Track [Page 14] + +RFC 5882 Generic Application of BFD June 2010 + + +10.1.3. OSPF Virtual Links + + If it is desired to use BFD for failure detection of OSPF Virtual + Links, the mechanism described in [BFD-MULTI] MUST be used, since + OSPF Virtual Links may traverse an arbitrary number of hops. BFD + authentication SHOULD be used and is strongly encouraged. + +10.2. Interactions with BGP + + BFD may be useful with External Border Gateway Protocol (EBGP) + sessions [BGP] in order to more rapidly trigger topology changes in + the face of path failure. As noted in Section 4.4, it is 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 is + strongly encouraged. + + [BGP-GRACE] describes a Graceful Restart mechanism for BGP. If + Graceful Restart is not 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 does + not signal planned restarts, so Section 4.3.2.2 applies. 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 somewhat unique in + that, at least as specified, neighbor adjacency state is not stored + per se. Rather, installed routes contain a next hop address, which + in most cases is the address of the advertising neighbor (but may not + be). + + In the case of RIP, when the BFD session associated with a neighbor + fails, an expiration of the "timeout" timer for each route installed + from the neighbor (for which the neighbor is the next hop) should be + simulated. + + Note that if a BFD session fails, and a route is received from that + neighbor with a next hop address that is not the address of the + neighbor itself, the route will linger until it naturally times out + + + +Katz & Ward Standards Track [Page 15] + +RFC 5882 Generic Application of BFD June 2010 + + + (after 180 seconds). However, if an implementation keeps track of + all of the routes received from each neighbor, all of the routes from + the neighbor corresponding to the failed BFD session should be timed + out, regardless of the next hop specified therein, and thereby + avoiding the lingering route problem. + +11. Security Considerations + + This specification does not raise any additional security issues + beyond those of the specifications referred to in the list of + normative references. + +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. + + + +Katz & Ward Standards Track [Page 16] + +RFC 5882 Generic Application of BFD June 2010 + + + [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 + + + + + + + + + + + + + + +Katz & Ward Standards Track [Page 17] + -- cgit v1.2.3