Network Working Group D. Katz Internet Draft Juniper Networks D. Ward Cisco Systems Expires:
September, 2007 March, 2007July, 2008 January, 2008 Generic Application of BFD draft-ietf-bfd-generic-03.txtdraft-ietf-bfd-generic-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol. Comments on this draft should be directed to firstname.lastname@example.org. 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]. 1. Introduction The Bidirectional Forwarding Detection protocol [BFD] 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 drafts 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. 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. 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. Control Protocol Interactions Very common client applications ofBasic Interaction Between BFD are control protocols, such as routing protocols.Sessions and Clients The object when BFD interacts withinteraction between a control protocol is to advise the control protocol of the connectivity ofBFD session and its associated client applications is, for the data protocol. Inmost part, an implementation issue that is outside the casescope of routing protocols, for example,this allows the connectivity failurespecification. However, it is useful to trigger the reroutingdescribe some mechanisms that implementors may use in order to promote full-featured implementations. One way of traffic around the failed path more quickly than the native detection mechanisms. 3.1. Session Establishment Ifmodeling this interaction is to create an adaptation layer between the sessionBFD state on eithermachine and the local or remote system (if known)client applications. The adaptation layer is AdminDown,cognizant of both the internals of the BFD has been administratively disabled,implementation and the establishmentrequirements of a control protocol adjacency MUST be allowed. BFD sessions are typically bootstrapped bythe control protocol, usingclients. 3.1. Session State Hysteresis A BFD session can be tightly coupled to its client applications; for example, any transition out of the mechanism (discovery, configuration) used byUp state could cause signaling to the control protocolclients to find neighbors. Note that it is possibletake failure action. But in some failure scenarios for the network tocases this may not always be in a state such thatthe control protocol is capablebest course of action. Implementors may choose to hide rapid Up/Down/Up transitions of coming up, butthe BFD session cannot be established, and, more particularly, data cannot be forwarded. To avoid this situation, it would be beneficialfrom its clients. This is useful in order to not allow the controlsupport process restarts without necessitating complex protocol to establish a neighbor adjacency. However, this would preclude the operation of the control protocol in an environment in whichmechanisms, for example. As such, a system MAY choose not all systems support BFD. Therefore, if the control protocol carries signaling that indicates the that both systems are willingto establishnotify clients if a BFD session, orsession 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 known thatoutside the remote system is BFD-capable (either by out-of-band means or byscope of this specification.) If the knowledgeBFD session does not return to Up state within that timeframe, the remote system previously sentclients SHOULD be notified that a session failure has occurred. 3.2. AdminDown State The AdminDown mechanism in BFD Control packets), andis intended to signal that the BFD session on the local systemis in state Down or Init,being taken down for administrative purposes, and the BFDsession on the remote systemstate is not AdminDown,indicative of the fact thatliveness of the BFDdata path. Therefore, a system SHOULD NOT indicate a connectivity failure to a client if either the local session is not in Upstate SHOULD be usedor the remote session state (if known) transitions to block establishmentAdminDown, so long as that client has independent means of aliveness detection (typically, control protocol adjacency.protocols.) If it appears that the neighboring systema client does not support BFD (no BFD Control packetshave been received from the neighbor), the establishmentany independent means of liveness detection, a control protocol adjacencysystem SHOULD NOT be blocked. Furthermore,indicate a system MAY increase the interval between transmitted BFD Control packets beyondconnectivity failure to a client, and assume the minimum specified in [BFD]. This will have negligible impact on BFD session establishmentsemantics of Down state, if either the neighbor decideslocal or remote session state transitions to run BFD after all, since BFD Control packetsAdminDown. Otherwise, the client will not be sent on an event-driven basis onceable to determine whether the first packetpath is seen from the neighbor. The setting of BFD's various timing parametersviable, and modes are not subjectunfortunate results may occur. 3.3. Hitless Establishment/Reestablishment of BFD State It is useful to standardization. Note that all protocols sharingbe able to configure a BFD session will operate using the same parameters. The mechanism for choosing the parameters among those desired by the various protocols are outsidebetween a pair of systems without impacting the scopestate of this specification. Itany clients that will be associated with that session. Similarly, it is generallyuseful for BFD state to choose the parameters resultingbe reestablished without perturbing associated clients when all BFD state is lost (such as in process restart situations.) This interacts with the shortest detection time; a particular client application can always apply hysteresis to the notifications from BFD if it desires longer detection times. 3.2. Reactionclients' ability to establish their state independent of BFD. The BFD Session State Changes If a BFD session transitions fromstate Up to AdminDown, or the sessionmachine transitions from Up to Down because the remote system is indicatingthat occur in the process of bringing up a BFD session isin state AdminDown, clientssuch situations SHOULD NOT take any control protocol action. Otherwise,cause a connectivity failure notification to the mechanism byclients. A client which the control protocol reactsis capable of establishing its state prior to the configuration or restarting of a path failure signaled byBFD depends on the capabilitiessession MAY do so if appropriate. The means to do so is outside of the protocol. 3.2.1.scope of this specification. 4. Control Protocols with a Single DataProtocol AInteractions Very common client applications of BFD are control protocol that is tightly bound toprotocols, such as routing protocols. The object when BFD interacts with a single failing datacontrol protocol SHOULD take action to ensure that data trafficis no longer directedto advise the failing path. Note thatcontrol protocol of the connectivity of the data protocol. In the case of routing protocols, for example, this should not be interpreted asallows 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 replacinghas been administratively disabled, and the establishment of a control protocol liveness mechanism, if any, asadjacency MUST be allowed. BFD sessions are typically bootstrapped by the control protocol may rely on mechanisms not verifiedprotocol, using the mechanism (discovery, configuration) used by BFD (multicast, for instance) so BFD most likely cannot detect all failures that would impactthe control protocol. However, a controlprotocol MAY chooseto use BFD session state informationfind neighbors. Note that it is possible in some failure scenarios for the network to more rapidly detect an impending control protocol failure, particularly ifbe in a state such that the control protocol operates in-band (overis capable of coming up, but the data protocol.) Therefore, when aBFD session transitions from Up to Down, action SHOULDcannot be taken inestablished, and, more particularly, data cannot be forwarded. To avoid this situation, it would be beneficial to not allow the control protocol to signalestablish a neighbor adjacency. However, this would preclude the lackoperation of connectivity for the data protocol over which BFD is running. Ifthe control protocol hasin an explicit mechanism for announcing path state, a system SHOULD use that mechanism rather than impactingenvironment in which not all systems support BFD. Therefore, the connectivityestablishment of the control protocol, particularly if thecontrol protocol operates out-of-band from the failed data protocol. However,adjacencies SHOULD be blocked if suchboth systems are willing to establish a mechanism is not available,BFD session but a control protocol timeout SHOULDBFD session cannot be emulated for the associated neighbor. 3.2.2. Control Protocols with Multiple Data Protocols Slightly different mechanisms are usedestablished. A system is known to be willing to establish a BFD session if the control protocol supportscarries signaling that indicates that both systems are willing to establish a BFD session, or it is known that the routingremote system is BFD-capable and BFD-enabled (the means of multiple data protocols, depending on whetherdetermining this are outside the control protocol supports separate topologies for each data protocol. 220.127.116.11. Shared Topologies With a shared topology, if onescope of the data protocols fails (as signaled by the associated BFD session),this specification.) If it is necessary to considerbelieved that the path to have failed for all data protocols. Otherwise, there is no way forneighboring system does not support BFD, the establishment of a 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, actionadjacency SHOULD NOT be taken in the control protocol to signal the lackblocked. The setting of connectivity forBFD's various timing parameters and modes are not subject to standardization. Note that all dataprotocols sharing the topology. If this cannot be signaled otherwise,a control protocol timeout SHOULD be emulated forsession will operate using the associated neighbor. 18.104.22.168. Independent Topologies With individual routing topologiessame parameters. The mechanism for each data protocol,choosing the parameters among those desired by the various protocols are 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 failed dataabsence of a BFD session, the assumptions of the control protocol needs tomay be rerouted around the failed path. Therefore, whenviolated, with unpredictable results. 4.2. Reaction to BFD Session State Changes If a BFD session transitions from state Up to Down, action SHOULD be taken inAdminDown, or the control protocolsession transitions from Up to signalDown because the lack of connectivity forremote system is indicating that the datasession is in state AdminDown, clients SHOULD NOT take any control protocol overaction. Otherwise, the mechanism by which the control protocol reacts to a path failure signaled by BFD is running. Generally this can be done without impactingdepends on the connectivitycapabilities of other data protocols (since otherwise it is very difficult to support separate topologies for multiple data protocols.) 3.3. Interactionsthe protocol. 4.2.1. Control Protocols with Graceful Restart Mechanismsa Single Data Protocol A number ofcontrol protocols support Graceful Restart mechanisms. These mechanisms are designedprotocol that is tightly bound to allowa controlsingle failing data protocol SHOULD take action to restart without perturbing network connectivity state (lest it appearensure that data traffic is no longer directed to the system and/or all of its links had failed.) They are predicated on the existence of a separate forwarding planefailing path. Note that doesthis should not necessarily share fate withbe interpreted as BFD replacing 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 viaprotocol liveness mechanism, if any, as the Control Plane Independent (C) bit whether orcontrol protocol may rely on mechanisms not verified by BFD shares fate with(multicast, for instance) so BFD most likely cannot detect all failures that would impact the control plane. Thisprotocol. However, a control protocol MAY choose to use BFD session state information is usedto determinemore rapidly detect an impending control protocol failure, particularly if the actionscontrol protocol operates in-band (over the data protocol.) Therefore, when a BFD session transitions from Up to Down, action SHOULD be taken in conjunction with Graceful Restart. If BFD does not share its fate withthe control plane on either system, it can be used to determine whether Graceful Restart in a controlprotocol to signal the lack of connectivity for the path over which BFD is NOT viable (the forwarding plane is not operating.)running. If the control protocol has an explicit mechanism for announcing path state, a Graceful Restart mechanism, BFD may be used in conjunction with this mechanism. The interaction between BFD and the control protocol depends onsystem SHOULD use that mechanism rather than impacting the capabilitiesconnectivity of the control protocol, and whether or not BFD shares fate withparticularly if the control plane. In particular, it may be desirable for a BFD session failure to abort the Graceful Restart process and allowprotocol operates out-of-band from the failure tofailed data protocol. However, if such a mechanism is not available, a control protocol timeout SHOULD be visible to the network. 3.3.1. BFD Fate Independent ofemulated for the associated neighbor. 4.2.2. Control Plane If BFD is implemented in the forwarding plane and does not share fateProtocols with Multiple Data Protocols Slightly different mechanisms are used if the control planeprotocol supports the routing of multiple data protocols, depending on either system (the "C" bit is set inwhether the BFD Control packets in both directions),control protocol restarts should not affect the BFD Session. In this case,supports separate topologies for each data protocol. 22.214.171.124. Shared Topologies With a shared topology, if one of the data protocols fails (as signaled by the associated BFD session failure implies thatsession), it is necessary to consider the path to have failed for all data canprotocols. Otherwise, there is no longer be forwarded, so any Graceful Restart in progress atway for the time ofcontrol protocol to turn away traffic for the failed data protocol (and such traffic would be black-holed indefinitely.) Therefore, when a BFD session failure SHOULD be aborted in ordertransitions from Up to avoid black holes, and a topology changeDown, action SHOULD be signaledtaken in the control protocol. 3.3.2. BFD Shares Fate withprotocol to signal the Control Plane If BFD shares fate withlack of connectivity for the control plane on either system (the "C" bit is clearpath in either direction), athe topology corresponding to the BFD session failuresession. If this cannot be disentangledsignaled otherwise, a control protocol timeout SHOULD be emulated for the associated neighbor. 126.96.36.199. 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 other events taking placeUp to Down, action SHOULD be taken in the control plane. In many cases,protocol to signal the BFD session will fail as a side effectlack of connectivity for the restart taking place. As such, it wouldpath in the topology over which BFD is running. Generally this can be bestdone without impacting the connectivity of other topologies (since otherwise it is very difficult to avoid aborting anysupport separate topologies for multiple data protocols.) 4.3. Interactions with Graceful Restart taking place, if possible (since otherwise BFD andMechanisms A number of control protocols support Graceful Restart cannot coexist.) There is some risk in doing so, sincemechanisms. These mechanisms are designed to allow a simultaneous failure orcontrol 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 willthat does not be detected, but this is always an issue when BFD sharesnecessarily share fate with the control plane. 188.8.131.52. Control Protocols with Planned Restart Signaling Some controlplane in which the routing protocols operate. In particular, the assumption is that the forwarding plane can signal a planned restart priorcontinue to function while the protocols restart taking place. In this case, if aand sort things out. BFD session failure occurs duringimplementations announce via 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. 184.108.40.206. Control Protocols Without Planned Restart SignalingControl protocols that cannot signal a planned restart depend onPlane Independent (C) bit whether or not BFD shares fate with the recently restarted systemcontrol plane. This information is used to signaldetermine the Graceful Restart prioractions to be taken in conjunction with Graceful Restart. If BFD does not share its fate with the control protocol adjacency timeout. In most cases, whether the restart is planned or unplanned,plane on either system, it is likely that the BFD session will time out priorcan be used to the onset ofdetermine whether Graceful Restart,Restart in which casea topology change SHOULD be signaled in thecontrol protocol as specified in section 3.2. However, if the restartis in fact planned, an implementation MAY adjustNOT viable (the forwarding plane is not operating.) If the control protocol has a Graceful Restart mechanism, BFD session timing parameters prior to restartingmay be used in such a way thatconjunction with this mechanism. The interaction between BFD and the detection time in each direction is longer thancontrol protocol depends on the restart periodcapabilities of the control protocol, providing the restarting systemand whether or not BFD shares fate with the same opportunitycontrol plane. In particular, it may be desirable for a BFD session failure to enterabort the Graceful Restart as it would have without BFD. The restarting system SHOULD NOT send anyprocess and allow the failure to be visible to the network. 4.3.1. BFD Fate Independent of the Control packets until therePlane If BFD is a high likelihoodimplemented 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. 220.127.116.11. 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. 18.104.22.168. 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. 22.214.171.124. 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 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. 4.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 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 eitherit 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 local session state orinitial packet if the remote session state (if known)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 session is AdminDown, the local system MUST NOT take any actionmay be used in the non-protocol function (such as withdrawinga static route), since the session is being administratively disabled and the livenessnumber of ways to protect the forwardingpath at layer N. The exact mechanism used is unknown. If it is known that the remote system is BFD-capable (either by out- of-band means or by the knowledge thatoutside the remote system previously sent BFD Control packets),scope of this specification. However, this section provides examples of some possible deployment scenarios. Other scenarios are possible and the BFD session on the local systemare not precluded. 7.1. Complete Decoupling The simplest approach is in state Down or Init, and theto simply run BFD session onover the remote system is not AdminDown,layer N path, with no interaction with the factlayer N-1 mechanisms. Doing so assumes that the BFD session is notlayer N-1 mechanism will deal with connectivity issues in Up state SHOULD be used to take appropriate action (such as withdrawing a static route.) If it appears that the neighboring system does not support BFD (noindividual layer N-1 links. BFD Control packets have been received from the neighbor), action such as withdrawing a static route SHOULD NOT be taken. Furthermore,will declare a system MAY increasefailure in the interval between transmitted BFD Control packets beyondlayer N path only when the minimum specified in [BFD].session times out. This approach will have negligible impact on BFD session establishment ifwork whether or not the layer N-1 neighbor decidesis the same as the layer N neighbor. 7.2. Layer N-1 Hints A slightly more intelligent approach than complete decoupling is to run BFD after all, sincehave the layer N-1 mechanism inform the layer N BFD Control packets will be sent on an event-driven basis oncewhen the first packetaggregated link is seen from the neighbor. Bootstrapping ofno longer viable. In this case, the BFD session inwill detect the non-protocol case is likelyfailure more rapidly, as it need not wait for the session to be derived from configuration information. Theretime out. This is no needanalogous to exchange endpoints or discriminator values via any mechanism other than configuration (via Operational Support Systemstriggering a session failure based on the hardware-detected failure of a single link. This approach will also work whether or any other means) asnot the endpoints must be known and configured bylayer N-1 neighbor is the same means. 5. Data Protocols and Demultiplexingas the layer N neighbor. 7.3. Aggregating BFD is intendedSessions Another approach would be to protect a single "data protocol"use BFD on each layer N-1 link, and is encapsulated within that protocol. A pairto aggregate the state of systems may havethe multiple BFDsessions overinto a single indication to the same topology if they support (and are encapsulated by) different protocols. For example,layer N clients. This approach has the advantage that it is independent of the layer N-1 technology. However, this approach only works if two systems have IPv4 and IPv6 running acrossthe same link between them, these are considered two separate paths and require two separate BFD sessions. This same techniquelayer N neighbor is used forthe same as the layer N-1 neighbor (a single hop at layer N-1.) 7.4. Combinations of Scenarios Combinations of more fine-grained paths.than one of the scenarios listed above (or others) may be useful in some cases. For example, if multiple differentiated services [DIFFSERV] are being operated on over IPv4, an independentthe 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 may be run for each service level.to the layer N neighbor. The aggregate state of the layer N-1 BFD Control packets mustsessions could be marked in the same way as the data packets, partlyused to ensure as much fate sharing as possible betweentrigger a layer N BFD and data traffic, and also to demultiplex the initial packet if the discriminator values have not been exchanged. 6.session failure. 8. Other Application Issues BFD can provide liveness detection for OAM-like functions 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. 7.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 to not 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. 8.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. Since the interactions do not affect interoperability, they are non- normative. 126.96.36.199. 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. 188.8.131.52.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]. 184.108.40.206.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. ISIS 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 underway to support multiple topologies. If multiple topologies are used to support multiple data protocols are advertised in(or multiple classes of service of the ISIS Hello, and independent topologies are in use,same data protocol) the topology- specific path associated with a failing data protocolBFD session should no longer be advertised in ISIS Hello packetsLSPs in order to signal a lack of connectivity for that protocol.connectivity. Otherwise, a failing BFD session should be signaled by simulating an ISIS adjacency failure. OSPF has a planned restart signaling mechanism, whereas ISIS does not. The appropriate mechanisms outlined in section 3.3 should be used. 220.127.116.11.1.3. OSPF Virtual Links If it is desired to use BFD for failure detction 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. 18.104.22.168. Interactions with BGP BFD may be useful with EBGP sessions [BGP] in order to more rapidly trigger topology changes in the face of path failure. As noted in section 3.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-MULTIHOP] session, depending on whether the neighbor is immediately adjacent or not. The BFD session should be established to the BGP neighbor (as opposed to any other Next Hop advertised in BGP.) [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 3.3 applies. BGP Graceful Restart does not signal planned restarts, so section 22.214.171.124 applies. If Graceful Restart is aborted due to the rules described in section 3.3, the "receiving speaker" should act as if the "restart timer" expired (as described in [BGP-GRACE].) 126.96.36.199. Interactions with RIP The RIP protocol [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 (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. Normative References [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", draft-ietf-bfd-base-06.txt, March, 2007.draft-ietf-bfd-base-07.txt, January, 2008. [BFD-1HOP] Katz, D., and Ward, D., "BFD for IPv4 and IPv6 (Single Hop)", draft-ietf-bfd-v4v6-1hop-06.txt, March, 2007.draft-ietf-bfd-v4v6-1hop-07.txt, January, 2008. [BFD-MPLS] Aggarwal, R., and Kompella, K., "BFD for MPLS LSPs", draft-ietf-bfd-mpls-04.txt, March, 2007. [BFD-MULTI] Katz, D., and Ward, D., "BFD for Multihop Paths", draft- ietf-bfd-multihop-05.txt, March, 2007.ietf-bfd-multihop-06.txt, January, 2008. [BGP] Rekhter, Y., Li, T. et al, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January, 2006. [BGP-GRACE] Sangli, S., Chen, E., et al, "Graceful Restart Mechanism for BGP", RFC 4724, January, 2007. [DIFFSERV] Nichols, K. et al, "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 Ginsberg, L., "Restart signaling for IS- IS", RFC 3847, July 2004. [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [OSPFv3] Coltun, R., et al, "OSPF for IPv6", RFC 2740, December 1999. [OSPF-GRACE] Moy, J., et al, "Graceful OSPF Restart", RFC 3623, November 2003. [RIP] Malkin, G., "RIP Version 2", RFC 2453, November, 1998. Security Considerations This specification does not raise any additional security issues beyond those of the specifications referred to in the list of normative references. IANA Considerations This document has no actions for IANA. Authors' Addresses Dave Katz Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, California 94089-1206 USA Phone: +1-408-745-2000 Email: email@example.com Dave Ward Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 USA Phone: +1-408-526-4000 Email: firstname.lastname@example.org Changes from the previous draft The only significant change to this draftA section was added to add specific text regardingmore completely describe the differenceinteraction between Downa BFD session and AdminDown states. Some redundant textits clients. Rules for handling session failures in non-protocol applications were clarified. A section was removed or merged.added describing possible deployment strategies in conjunction with multilink technologies. A note was added to point out potential problems when not all systems on a multiaccess network support BFD. All other changes were purely editorial in nature. IPR Disclaimer The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- email@example.com. Full Copyright Notice Copyright (C) The IETF Trust (2007).(2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. This document expires in September, 2007.July, 2008.