Network Working Group                                           D. Katz
Internet Draft                                         Juniper Networks
                                                                D. Ward
                                                          Cisco Systems
Expires: September, 2007                                    March, 2007 July, 2008                                       January, 2008

                       Generic Application of BFD
                     draft-ietf-bfd-generic-03.txt
                     draft-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 rtg-bfd@ietf.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 of Basic Interaction Between BFD are control protocols, such as
   routing protocols. Sessions and Clients

   The object when BFD interacts with interaction between a control
   protocol is to advise the control protocol of the connectivity of BFD session and its associated client
   applications is, for the
   data protocol.  In most part, an implementation issue that is
   outside the case scope of routing protocols, for example, this
   allows the connectivity failure specification.  However, it is useful to trigger the rerouting
   describe 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

   If modeling this
   interaction is to create an adaptation layer between the session BFD state on either
   machine 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
   establishment
   requirements of a control protocol adjacency MUST be allowed.

   BFD sessions are typically bootstrapped by the control protocol,
   using clients.

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 by Up state could cause signaling to
   the control
   protocol clients to find neighbors.  Note that it is possible take failure action.  But in some failure
   scenarios for the network to cases this may not
   always be in a state such that the control
   protocol is capable best course of action.

   Implementors may choose to hide rapid Up/Down/Up transitions 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 from its clients.  This is useful in order to not allow the control support
   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
   which mechanisms,
   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 willing to establish notify clients if a BFD session, or 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 known that
   outside the remote system is BFD-capable (either by out-of-band
   means or by scope of this specification.)  If the knowledge BFD session does
   not return to Up state within that timeframe, the remote system previously sent clients SHOULD be
   notified that a session failure has occurred.

3.2. AdminDown State

   The AdminDown mechanism in BFD
   Control packets), and is intended to signal that the BFD
   session on the local system is in state
   Down or Init, being taken down for administrative purposes, and the BFD
   session on the remote system state is not
   AdminDown, indicative of the fact that liveness of the BFD data path.

   Therefore, a system SHOULD NOT indicate a connectivity failure to a
   client if either the local session is not in Up state SHOULD be
   used or the remote session state
   (if known) transitions to block establishment AdminDown, so long as that client has
   independent means of a liveness detection (typically, control protocol adjacency.
   protocols.)

   If it appears that the neighboring system a client does not support BFD (no
   BFD Control packets have been received from the neighbor), the
   establishment any independent means of liveness
   detection, a control protocol adjacency system SHOULD NOT be blocked.
   Furthermore, indicate a system MAY increase the interval between transmitted
   BFD Control packets beyond connectivity failure to a
   client, and assume the minimum specified in [BFD].  This will
   have negligible impact on BFD session establishment semantics of Down state, if either the neighbor
   decides local
   or remote session state transitions to run BFD after all, since BFD Control packets AdminDown.  Otherwise, the
   client will not be sent
   on an event-driven basis once able to determine whether the first packet path is seen from the
   neighbor.

   The setting of BFD's various timing parameters viable, and modes are not
   subject
   unfortunate results may occur.

3.3. Hitless Establishment/Reestablishment of BFD State

   It is useful to standardization.  Note that all protocols sharing be 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 outside between a pair of
   systems without impacting the scope state of this specification.  It any clients that will be
   associated with that session.  Similarly, it is generally useful for BFD state
   to choose the parameters resulting be 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. Reaction clients' ability to establish their state
   independent of BFD.

   The BFD Session State Changes

   If a BFD session transitions from state Up to AdminDown, or the
   session machine transitions from Up to Down because the remote system is
   indicating that occur in the process of
   bringing up a BFD session is in state AdminDown, clients such situations SHOULD NOT
   take any control protocol action.

   Otherwise, cause a
   connectivity failure notification to the mechanism by clients.

   A client which the control protocol reacts is capable of establishing its state prior to the
   configuration or restarting of a
   path failure signaled by BFD depends on the capabilities session 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 Data Protocol

   A Interactions

   Very common client applications of BFD are control protocol that is tightly bound to protocols, such as
   routing protocols.  The object when BFD interacts with a single failing data control
   protocol SHOULD take action to ensure that data traffic is no longer
   directed to advise the failing path.  Note that control protocol of the connectivity of the
   data protocol.  In the case of routing protocols, for example, this should not be
   interpreted as
   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 replacing has been administratively disabled, and the
   establishment of a control protocol liveness mechanism,
   if any, as adjacency MUST be allowed.

   BFD sessions are typically bootstrapped by the control protocol may rely on mechanisms not verified protocol,
   using the mechanism (discovery, configuration) used 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 find neighbors.  Note that it is possible in some failure
   scenarios for the network to more
   rapidly detect an impending control protocol failure, particularly if be in a state such that the control
   protocol operates in-band (over is capable of coming up, but the data protocol.)

   Therefore, when a BFD session transitions from Up to Down, action
   SHOULD cannot be taken in
   established, and, more particularly, data cannot be forwarded.  To
   avoid this situation, it would be beneficial to not allow the control
   protocol to signal establish a neighbor adjacency.  However, this would
   preclude the lack operation of
   connectivity for the data protocol over which BFD is running.  If the control protocol has in an explicit mechanism for announcing path state,
   a system SHOULD use that mechanism rather than impacting environment in
   which not all systems support BFD.

   Therefore, the
   connectivity establishment of the control protocol, particularly if the control protocol operates out-of-band from the failed data protocol.
   However, adjacencies SHOULD
   be blocked if such both systems are willing to establish a mechanism is not available, BFD session but
   a control protocol
   timeout SHOULD BFD session cannot be emulated for the associated neighbor.

3.2.2. Control Protocols with Multiple Data Protocols

   Slightly different mechanisms are used established.  A system is known to be willing
   to establish a BFD session if the control protocol
   supports carries signaling
   that indicates that both systems are willing to establish a BFD
   session, or it is known that the routing remote system is BFD-capable and
   BFD-enabled (the means of multiple data protocols, depending on whether determining this are outside the control protocol supports separate topologies for each data
   protocol.

3.2.2.1. Shared Topologies

   With a shared topology, if one scope of the data protocols fails (as
   signaled by the associated BFD session),
   this specification.)

   If it is necessary to consider believed that the path to have failed for all data protocols.  Otherwise, there is
   no way for neighboring 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, action adjacency SHOULD NOT be taken in the control protocol to signal the lack
   blocked.

   The setting of
   connectivity for BFD's various timing parameters and modes are not
   subject to standardization.  Note that all data protocols sharing the topology.  If this
   cannot be signaled otherwise, a control protocol timeout SHOULD be
   emulated for
   session will operate using the associated neighbor.

3.2.2.2. Independent Topologies

   With individual routing topologies same 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 data absence of a BFD session, the assumptions of the
   control protocol needs to may be rerouted around the failed path.

   Therefore, when violated, 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 in AdminDown, or the control protocol
   session transitions from Up to signal Down because the lack of
   connectivity for remote system is
   indicating that the data session is in state AdminDown, clients SHOULD NOT
   take any control protocol over action.

   Otherwise, the mechanism by which the control protocol reacts to a
   path failure signaled by BFD is running.
   Generally this can be done without impacting depends on the connectivity capabilities of
   other data protocols (since otherwise it is very difficult to support
   separate topologies for multiple data protocols.)

3.3. Interactions the
   protocol.

4.2.1. Control Protocols with Graceful Restart Mechanisms a Single Data Protocol

   A number of control protocols support Graceful Restart mechanisms.
   These mechanisms are designed protocol that is tightly bound to allow a control single failing data
   protocol SHOULD take action to restart
   without perturbing network connectivity state (lest it appear ensure 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 plane failing path.  Note that does this should not
   necessarily share fate with be
   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 via protocol liveness mechanism,
   if any, as the Control Plane Independent (C)
   bit whether or control 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.  This protocol.  However, a control
   protocol MAY choose to use BFD session state information is used to determine more
   rapidly detect an impending control protocol failure, particularly if
   the actions control 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
   with the control plane on either system, it can be used to determine
   whether Graceful Restart in a control protocol 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 on
   system SHOULD use that mechanism rather than impacting the capabilities
   connectivity of the control protocol, and whether or not BFD shares fate with particularly if the control plane.
   In particular, it may be desirable for a BFD session failure to abort
   the Graceful Restart process and allow
   protocol operates out-of-band from the failure to failed 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 of emulated for the associated neighbor.

4.2.2. Control Plane

   If BFD is implemented in the forwarding plane and does not share fate Protocols with Multiple Data Protocols

   Slightly different mechanisms are used if the control plane protocol
   supports the routing of multiple data protocols, depending on either system (the "C" bit is set in whether
   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.

4.2.2.1. Shared Topologies

   With a shared topology, if one of the data protocols fails (as
   signaled by the associated BFD session
   failure implies that session), it is necessary to consider
   the path to have failed for all data can protocols.  Otherwise, there is
   no longer be forwarded, so any Graceful
   Restart in progress at way for the time of control 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 order transitions from Up to avoid black holes, and a topology change Down, action
   SHOULD be signaled taken in the control protocol.

3.3.2. BFD Shares Fate with protocol to signal the Control Plane

   If BFD shares fate with lack of
   connectivity for the control plane on either system (the "C"
   bit is clear path in either direction), a the topology corresponding to the BFD session failure
   session.  If this cannot be
   disentangled 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 other events taking place Up to Down, action
   SHOULD be taken in the control plane.  In
   many cases, protocol to signal the BFD session will fail as a side effect lack of
   connectivity for the restart
   taking place.  As such, it would path in the topology over which BFD is running.
   Generally this can be best done without impacting the connectivity of
   other topologies (since otherwise it is very difficult to avoid aborting any support
   separate topologies for multiple data protocols.)

4.3. Interactions with Graceful Restart taking place, if possible (since otherwise BFD and Mechanisms

   A number of control protocols support Graceful Restart cannot coexist.)

   There is some risk in doing so, since mechanisms.
   These mechanisms are designed to allow a simultaneous failure or 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 will that does not be detected, but this is
   always an issue when BFD shares
   necessarily share fate with the control plane.

3.3.2.1. Control Protocols with Planned Restart Signaling

   Some control plane in which the routing
   protocols operate.  In particular, the assumption is that the
   forwarding plane can signal a planned restart prior continue to function while the protocols restart taking place.  In this case, if a
   and sort things out.

   BFD session failure occurs
   during implementations 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.

3.3.2.2. Control Protocols Without Planned Restart Signaling Control protocols that cannot signal a planned restart depend on Plane Independent (C)
   bit whether or not BFD shares fate with the
   recently restarted system control plane.  This
   information is used to signal determine the Graceful Restart prior actions 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 prior can be used to the onset of determine
   whether Graceful Restart, 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 NOT viable (the
   forwarding plane is not operating.)

   If the control protocol has a Graceful Restart mechanism, BFD session timing parameters prior to restarting may be
   used in such
   a way that conjunction with this mechanism.  The interaction between BFD
   and the detection time in each direction is longer than control protocol depends on the
   restart period capabilities of the control
   protocol, providing the restarting
   system and whether or not BFD shares fate with the same opportunity control plane.
   In particular, it may be desirable for a BFD session failure to enter abort
   the Graceful Restart as it would
   have without BFD.  The restarting system SHOULD NOT send any process and allow the failure to be visible to
   the network.

4.3.1. BFD Fate Independent of the Control packets until there Plane

   If BFD is a high likelihood 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.

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.

3.4.

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 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 either 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 local session state or
   initial 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 action may be used in the non-protocol function (such as withdrawing a static
   route), since the session is being administratively disabled and the
   liveness number of ways to protect the forwarding path 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 that outside 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 system are not precluded.

7.1. Complete Decoupling

   The simplest approach is
   in state Down or Init, and the to simply run BFD session on over the remote system is
   not AdminDown, layer N path,
   with no interaction with the fact layer N-1 mechanisms.  Doing so assumes
   that the BFD session is not layer 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 (no
   individual 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 increase failure in the interval between transmitted BFD Control
   packets beyond layer
   N path only when the minimum specified in [BFD]. session times out.

   This approach will have
   negligible impact on BFD session establishment if work whether or not the layer N-1 neighbor
   decides is 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, since
   have the layer N-1 mechanism inform the layer N BFD Control packets will be sent
   on an event-driven basis once when the first packet
   aggregated link is seen from the
   neighbor.

   Bootstrapping of no longer viable.  In this case, the BFD session in
   will detect the non-protocol case is likely failure more rapidly, as it need not wait for the
   session to be derived from configuration information.

   There time out.  This is no need analogous to exchange endpoints or discriminator values via
   any mechanism other than configuration (via Operational Support
   Systems triggering a session
   failure based on the hardware-detected failure of a single link.

   This approach will also work whether or any other means) as not the endpoints must be known and
   configured by layer N-1 neighbor is
   the same means.

5. Data Protocols and Demultiplexing as the layer N neighbor.

7.3. Aggregating BFD is intended Sessions

   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 pair to
   aggregate the state of systems may have the multiple BFD sessions over into 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 across the same link between them, these
   are considered two separate paths and require two separate BFD
   sessions.

   This same technique layer N neighbor is used for the 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 independent 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 may be run for each
   service level. to the layer N neighbor.
   The aggregate state of the layer N-1 BFD Control packets must sessions could be marked in the same
   way as the data packets, partly used to ensure as much fate sharing as
   possible between
   trigger 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.

8.1.

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.

8.1.1.

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].

8.1.2.

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.

   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 protocol BFD session should no longer
   be advertised in ISIS Hello packets LSPs 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.

8.1.3.

10.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.

8.2.

10.2. 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 3.3.2.2 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].)

8.3.

10.3. 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: dkatz@juniper.net

    Dave Ward
    Cisco Systems
    170 W. Tasman Dr.
    San Jose, CA 95134 USA
    Phone: +1-408-526-4000
    Email: dward@cisco.com

Changes from the previous draft

   The only significant change to this draft

   A section was added to add specific text
   regarding more completely describe the difference interaction
   between Down a BFD session and AdminDown states.  Some
   redundant text its 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-
   ipr@ietf.org.

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.