summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5882.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5882.txt')
-rw-r--r--doc/rfc/rfc5882.txt955
1 files changed, 955 insertions, 0 deletions
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]
+