draft-ietf-bfd-generic-02.txt   draft-ietf-bfd-generic-03.txt 
Network Working Group D. Katz Network Working Group D. Katz
Internet Draft Juniper Networks Internet Draft Juniper Networks
D. Ward D. Ward
Cisco Systems Cisco Systems
Expires: December, 2006 June, 2006 Expires: September, 2007 March, 2007
Generic Application of BFD Generic Application of BFD
draft-ietf-bfd-generic-02.txt draft-ietf-bfd-generic-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Abstract Abstract
This document describes the generic application of the Bidirectional This document describes the generic application of the Bidirectional
Forwarding Detection (BFD) protocol. Comments on this draft should Forwarding Detection (BFD) protocol. Comments on this draft should
be directed to rtg-bfd@ietf.org. be directed to rtg-bfd@ietf.org.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 4, line 17 skipping to change at page 3, line 44
Very common client applications of BFD are control protocols, such as Very common client applications of BFD are control protocols, such as
routing protocols. The object when BFD interacts with a control routing protocols. The object when BFD interacts with a control
protocol is to advise the control protocol of the connectivity of the protocol is to advise the control protocol of the connectivity of the
data protocol. In the case of routing protocols, for example, this data protocol. In the case of routing protocols, for example, this
allows the connectivity failure to trigger the rerouting of traffic allows the connectivity failure to trigger the rerouting of traffic
around the failed path more quickly than the native detection around the failed path more quickly than the native detection
mechanisms. mechanisms.
3.1. Session Establishment 3.1. Session Establishment
If the session state on either the local or remote system (if known)
is AdminDown, BFD has been administratively disabled, and the
establishment of a control protocol adjacency MUST be allowed.
BFD sessions are typically bootstrapped by the control protocol, BFD sessions are typically bootstrapped by the control protocol,
using the mechanism (discovery, configuration) used by the control using the mechanism (discovery, configuration) used by the control
protocol to find neighbors. In most cases it is not desirable to protocol to find neighbors. Note that it is possible in some failure
preclude the control protocol from establishing an adjacency if the scenarios for the network to be in a state such that the control
BFD session cannot be established (usually because the neighbor does protocol is capable of coming up, but the BFD session cannot be
not support BFD.) established, and, more particularly, data cannot be forwarded. To
avoid this situation, it would be beneficial to not allow the control
protocol to establish a neighbor adjacency. However, this would
preclude the operation of the control protocol in an environment in
which not all systems support BFD.
If the control protocol carries signaling that indicates the Therefore, if the control protocol carries signaling that indicates
willingness of each system to establish a BFD session, the lack of a the that both systems are willing to establish a BFD session, or it
BFD session MAY be used to block establishment of a control protocol is known that the remote system is BFD-capable (either by out-of-band
adjacency. means or by the knowledge that the remote system previously sent BFD
Control packets), and the BFD session on the local system is in state
Down or Init, and the BFD session on the remote system is not
AdminDown, the fact that the BFD session is not in Up state SHOULD be
used to block establishment of a control protocol adjacency.
If it appears that the neighboring system does not support BFD If it appears that the neighboring system does not support BFD (no
(because the control protocol adjacency was established but no BFD BFD Control packets have been received from the neighbor), the
Control packets have been received from the neighbor) a system MAY establishment of a control protocol adjacency SHOULD NOT be blocked.
increase the interval between transmitted BFD Control packets beyond Furthermore, a system MAY increase the interval between transmitted
the minimum specified in [BFD]. This will have negligible impact on BFD Control packets beyond the minimum specified in [BFD]. This will
BFD session establishment if the neighbor decides to run BFD after have negligible impact on BFD session establishment if the neighbor
all, since BFD Control packets will be sent on an event-driven basis decides to run BFD after all, since BFD Control packets will be sent
once the first packet is seen from the neighbor. on an event-driven basis once the first packet is seen from the
neighbor.
The setting of BFD's various timing parameters and modes are not The setting of BFD's various timing parameters and modes are not
subject to standardization. Note that all protocols sharing a subject to standardization. Note that all protocols sharing a
session will operate using the same parameters. The mechanism for session will operate using the same parameters. The mechanism for
choosing the parameters among those desired by the various protocols choosing the parameters among those desired by the various protocols
are outside the scope of this specification. It is generally useful are outside the scope of this specification. It is generally useful
to choose the parameters resulting in the shortest detection time; a to choose the parameters resulting in the shortest detection time; a
particular client application can always apply hysteresis to the particular client application can always apply hysteresis to the
notifications from BFD if it desires longer detection times. notifications from BFD if it desires longer detection times.
3.2. Reaction to BFD Session State Changes 3.2. Reaction to BFD Session State Changes
The mechanism by which the control protocol reacts to a path failure If a BFD session transitions from state Up to AdminDown, or the
signaled by BFD depends on the capabilities of the protocol. session transitions from Up to Down because the remote system is
indicating that the session is in state AdminDown, clients SHOULD NOT
take any control protocol action.
Otherwise, the mechanism by which the control protocol reacts to a
path failure signaled by BFD depends on the capabilities of the
protocol.
3.2.1. Control Protocols with a Single Data Protocol 3.2.1. Control Protocols with a Single Data Protocol
A control protocol that is tightly bound to a single failing data A control protocol that is tightly bound to a single failing data
protocol SHOULD take action to ensure that data traffic is no longer protocol SHOULD take action to ensure that data traffic is no longer
directed to the failing path. Note that this should not be directed to the failing path. Note that this should not be
interpreted as BFD replacing the control protocol liveness mechanism, interpreted as BFD replacing the control protocol liveness mechanism,
if any, as the control protocol may rely on mechanisms not verified if any, as the control protocol may rely on mechanisms not verified
by BFD (multicast, for instance) so BFD most likely cannot detect all by BFD (multicast, for instance) so BFD most likely cannot detect all
failures that would impact the control protocol. However, a control failures that would impact the control protocol. However, a control
protocol MAY choose to use BFD session state information to more protocol MAY choose to use BFD session state information to more
rapidly detect an impending control protocol failure, particularly if rapidly detect an impending control protocol failure, particularly if
the control protocol operates in band (over the data protocol.) the control protocol operates in-band (over the data protocol.)
Therefore, when a BFD session transitions from Up to Down, action Therefore, when a BFD session transitions from Up to Down, action
SHOULD be taken in the control protocol to signal the lack of SHOULD be taken in the control protocol to signal the lack of
connectivity for the data protocol over which BFD is running. If the connectivity for the data protocol over which BFD is running. If the
control protocol has an explicit mechanism for announcing path state, control protocol has an explicit mechanism for announcing path state,
a system SHOULD use that mechanism rather than impacting the a system SHOULD use that mechanism rather than impacting the
connectivity of the control protocol, particularly if the control connectivity of the control protocol, particularly if the control
protocol operates out of band from the failed data protocol. protocol operates out-of-band from the failed data protocol.
However, if such a mechanism is not available, a control protocol However, if such a mechanism is not available, a control protocol
timeout SHOULD be emulated for the associated neighbor. timeout SHOULD be emulated for the associated neighbor.
3.2.2. Control Protocols with Multiple Data Protocols 3.2.2. Control Protocols with Multiple Data Protocols
Slightly different mechanisms are used if the control protocol Slightly different mechanisms are used if the control protocol
supports the routing of multiple data protocols, depending on whether supports the routing of multiple data protocols, depending on whether
the control protocol supports separate topologies for each data the control protocol supports separate topologies for each data
protocol. protocol.
3.2.2.1. Shared Topologies 3.2.2.1. Shared Topologies
With a shared topology, if one of the data protocols fails (as With a shared topology, if one of the data protocols fails (as
signaled by the associated BFD session), it is necessary to consider signaled by the associated BFD session), it is necessary to consider
the path to have failed for all data protocols. Otherwise, there is the path to have failed for all data protocols. Otherwise, there is
no way for the control protocol to turn away traffic for the failed no way for the control protocol to turn away traffic for the failed
data protocol (and such traffic would be black holed indefinitely.) data protocol (and such traffic would be black-holed indefinitely.)
Therefore, when a BFD session transitions from Up to Down, action Therefore, when a BFD session transitions from Up to Down, action
SHOULD be taken in the control protocol to signal the lack of SHOULD be taken in the control protocol to signal the lack of
connectivity for all data protocols sharing the topology. If this connectivity for all data protocols sharing the topology. If this
cannot be signaled otherwise, a control protocol timeout SHOULD be cannot be signaled otherwise, a control protocol timeout SHOULD be
emulated for the associated neighbor. emulated for the associated neighbor.
3.2.2.2. Independent Topologies 3.2.2.2. Independent Topologies
With individual routing topologies for each data protocol, only the With individual routing topologies for each data protocol, only the
failed data protocol needs to be rerouted around the failed path. failed data protocol needs to be rerouted around the failed path.
Therefore, when a BFD session transitions from Up to Down, action Therefore, when a BFD session transitions from Up to Down, action
SHOULD be taken in the control protocol to signal the lack of SHOULD be taken in the control protocol to signal the lack of
connectivity for the data protocol over which BFD is running. connectivity for the data protocol over which BFD is running.
Generally this can be done without impacting the connectivity of Generally this can be done without impacting the connectivity of
other data protocols (since otherwise it is very difficult to support other data protocols (since otherwise it is very difficult to support
separate topologies for multiple data protocols.) separate topologies for multiple data protocols.)
3.2.3. Partial BFD Deployments
Note that it is possible in some failure scenarios for the network to
be in a state such that the control protocol comes up, but the BFD
session cannot be established, and, more particularly, data cannot be
forwarded. To avoid this situation, it would be beneficial to not
allow the control protocol to establish a neighbor adjacency.
However, this would preclude the operation of the control protocol in
an environment in which not all systems support BFD.
Therefore, if a BFD session is not in Up state (possibly because the
remote system does not support BFD), it is OPTIONAL to preclude the
establishment of a control protocol neighbor adjacency. The choice
of whether to do so SHOULD be controlled by means outside the scope
of this specification, such as configuration or other mechanisms. If
a neighbor adjacency is established for the control protocol but the
corresponding BFD session is not in Up state (implying that the
neighbor does not support BFD) implementations MAY raise the BFD
transmit and receive intervals beyond the minimum of one second
specified in [BFD] in order to minimize extraneous traffic.
3.3. Interactions with Graceful Restart Mechanisms 3.3. Interactions with Graceful Restart Mechanisms
A number of control protocols support Graceful Restart mechanisms. A number of control protocols support Graceful Restart mechanisms.
These mechanisms are designed to allow a control protocol to restart These mechanisms are designed to allow a control protocol to restart
without perturbing network connectivity state (lest it appear that without perturbing network connectivity state (lest it appear that
the system and/or all of its links had failed.) They are predicated the system and/or all of its links had failed.) They are predicated
on the existence of a separate forwarding plane that does not on the existence of a separate forwarding plane that does not
necessarily share fate with the control plane in which the routing necessarily share fate with the control plane in which the routing
protocols operate. In particular, the assumption is that the protocols operate. In particular, the assumption is that the
forwarding plane can continue to function while the protocols restart forwarding plane can continue to function while the protocols restart
skipping to change at page 9, line 15 skipping to change at page 8, line 35
4. Interactions With Non-Protocol Functions 4. Interactions With Non-Protocol Functions
BFD session status may be used to affect other system functions that BFD session status may be used to affect other system functions that
are not protocol-based (for example, static routes.) If the path to are not protocol-based (for example, static routes.) If the path to
a remote system fails, it may be desirable to avoid passing traffic 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 to that remote system, so the local system may wish to take internal
measures to accomplish this (such as withdrawing a static route and measures to accomplish this (such as withdrawing a static route and
withdrawing that route from routing protocols.) withdrawing that route from routing protocols.)
If either the local session state or the remote session state (if
known) of a BFD session is AdminDown, the local system MUST NOT take
any action in the non-protocol function (such as withdrawing a static
route), since the session is being administratively disabled and the
liveness of the forwarding path is unknown.
If it is known that the remote system is BFD-capable (either by out-
of-band means or by the knowledge that the remote system previously
sent BFD Control packets), and the BFD session on the local system is
in state Down or Init, and the BFD session on the remote system is
not AdminDown, the fact that the BFD session is not 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
BFD Control packets have been received from the neighbor), action
such as withdrawing a static route SHOULD NOT be taken. Furthermore,
a system MAY increase the interval between transmitted BFD Control
packets beyond the minimum specified in [BFD]. This will have
negligible impact on BFD session establishment if the neighbor
decides to run BFD after all, since BFD Control packets will be sent
on an event-driven basis once the first packet is seen from the
neighbor.
Bootstrapping of the BFD session in the non-protocol case is likely Bootstrapping of the BFD session in the non-protocol case is likely
to be derived from configuration information. to be derived from configuration information.
There is no need to exchange endpoints or discriminator values via There is no need to exchange endpoints or discriminator values via
any mechanism other than configuration (via Operational Support any mechanism other than configuration (via Operational Support
Systems or any other means) as the endpoints must be known and Systems or any other means) as the endpoints must be known and
configured by the same means. configured by the same means.
5. Data Protocols and Demultiplexing 5. Data Protocols and Demultiplexing
skipping to change at page 10, line 14 skipping to change at page 10, line 14
6. Other Application Issues 6. Other Application Issues
BFD can provide liveness detection for OAM-like functions in BFD can provide liveness detection for OAM-like functions in
tunneling and pseudowire protocols. Running BFD inside the tunnel is tunneling and pseudowire protocols. Running BFD inside the tunnel is
recommended, as it exercises more aspects of the path. One way to recommended, as it exercises more aspects of the path. One way to
accommodate this is to address BFD packets based on the tunnel accommodate this is to address BFD packets based on the tunnel
endpoints, assuming that they are numbered. endpoints, assuming that they are numbered.
If a planned outage is to take place on a path over which BFD is run, 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 ADMIN it is preferable to take down the BFD session by going into AdminDown
DOWN state prior to the outage. state prior to the outage.
7. Interoperability Issues 7. Interoperability Issues
The BFD protocol itself is designed so that it will always The BFD protocol itself is designed so that it will always
interoperate at a basic level; asynchronous mode is mandatory and is interoperate at a basic level; asynchronous mode is mandatory and is
always available, and other modes and functions are negotiated at run always available, and other modes and functions are negotiated at run
time. Since the service provided by BFD is identical regardless of time. Since the service provided by BFD is identical regardless of
the variants used, the particular choice of BFD options has no the variants used, the particular choice of BFD options has no
bearing on interoperability. bearing on interoperability.
skipping to change at page 12, line 50 skipping to change at page 12, line 50
the address of the advertising neighbor (but may not be.) the address of the advertising neighbor (but may not be.)
In the case of RIP, when the BFD session associated with a neighbor In the case of RIP, when the BFD session associated with a neighbor
fails, an expiration of the "timeout" timer for each route installed fails, an expiration of the "timeout" timer for each route installed
from the neighbor (for which the neighbor is the next hop) should be from the neighbor (for which the neighbor is the next hop) should be
simulated. simulated.
Note that if a BFD session fails, and a route is received from that 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 with a next hop address that is not the address of the
neighbor itself, the route will linger until it naturally times out neighbor itself, the route will linger until it naturally times out
(after 180 seconds. However, if an implementation keeps track of all (after 180 seconds.) However, if an implementation keeps track of
of the routes received from each neighbor, all of the routes from the all of the routes received from each neighbor, all of the routes from
neighbor corresponding to the failed BFD session should be timed out, the neighbor corresponding to the failed BFD session should be timed
regardless of the next hop specified therein, and thereby avoiding out, regardless of the next hop specified therein, and thereby
the lingering route problem. avoiding the lingering route problem.
Normative References Normative References
[BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection",
draft-ietf-bfd-base-05.txt, June, 2006. draft-ietf-bfd-base-06.txt, March, 2007.
[BFD-1HOP] Katz, D., and Ward, D., "BFD for IPv4 and IPv6 (Single [BFD-1HOP] Katz, D., and Ward, D., "BFD for IPv4 and IPv6 (Single
Hop)", draft-ietf-bfd-v4v6-1hop-05.txt, June, 2006. Hop)", draft-ietf-bfd-v4v6-1hop-06.txt, March, 2007.
[BFD-MPLS] Aggarwal, R., and Kompella, K., "BFD for MPLS LSPs", [BFD-MPLS] Aggarwal, R., and Kompella, K., "BFD for MPLS LSPs",
draft-ietf-bfd-mpls-03.txt, June, 2006. draft-ietf-bfd-mpls-04.txt, March, 2007.
[BFD-MULTI] Katz, D., and Ward, D., "BFD for Multihop Paths", draft- [BFD-MULTI] Katz, D., and Ward, D., "BFD for Multihop Paths", draft-
ietf-bfd-multihop-04.txt, June, 2006. ietf-bfd-multihop-05.txt, March, 2007.
[BGP] Rekhter, Y., Li, T. et al, "A Border Gateway Protocol 4 [BGP] Rekhter, Y., Li, T. et al, "A Border Gateway Protocol 4
(BGP-4)", RFC 4271, January, 2006. (BGP-4)", RFC 4271, January, 2006.
[BGP-GRACE] Sangli, S., Rekhter, Y., et al, "Graceful Restart [BGP-GRACE] Sangli, S., Chen, E., et al, "Graceful Restart Mechanism
Mechanism for BGP", draft-ietf-idr-restart-12.txt, June, 2006. for BGP", RFC 4724, January, 2007.
[DIFFSERV] Nichols, K. et al, "Definition of the Differentiated [DIFFSERV] Nichols, K. et al, "Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC
2474, December, 1998. 2474, December, 1998.
[ISIS] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual [ISIS] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual
environments", RFC 1195, December 1990. environments", RFC 1195, December 1990.
[ISIS-GRACE] Shand, M., and Ginsberg, L., "Restart signaling for IS- [ISIS-GRACE] Shand, M., and Ginsberg, L., "Restart signaling for IS-
IS", RFC 3847, July 2004. IS", RFC 3847, July 2004.
skipping to change at page 14, line 33 skipping to change at page 14, line 33
Dave Ward Dave Ward
Cisco Systems Cisco Systems
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134 USA San Jose, CA 95134 USA
Phone: +1-408-526-4000 Phone: +1-408-526-4000
Email: dward@cisco.com Email: dward@cisco.com
Changes from the previous draft Changes from the previous draft
Control protocol-specific interactions were moved from [BFD-1HOP] to The only significant change to this draft was to add specific text
this document, and brief mentions of BGP and RIP were added. regarding the difference between Down and AdminDown states. Some
redundant text was removed or merged.
All other changes were purely editorial in nature.
IPR Disclaimer IPR Disclaimer
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 15, line 31 skipping to change at page 15, line 31
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Full Copyright Notice Full Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
This document expires in December, 2006. This document expires in September, 2007.
 End of changes. 24 change blocks. 
68 lines changed or deleted 88 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/