Network Working Group D. Katz
Internet Draft Juniper Networks
D. Ward
Cisco Systems
Expires: January, 2006 July, 2005
Generic Application of BFD
draft-ietf-bfd-generic-00.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
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Katz, Ward [Page 1]
Internet Draft Generic Application of BFD July, 2005
Abstract
This document describes the generic application of the Bidirectional
Forwarding Detection (BFD) protocol in environments not specifically
documented in other specifications. 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
BFD [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 in specific
situations ([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 in a broad way.
This document describes the generic application of BFD. Applications
with specific requirements should be spelled out in specific
documents.
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.
Katz, Ward [Page 2]
Internet Draft Generic Application of BFD July, 2005
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 function 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.
3. Control Protocol Interactions
The object when BFD interacts with a control protocol is to advise
the control protocol of the connectivity of the data protocol. In
the case of routing protocols, for example, this allows the
connectivity failure to trigger the rerouting of traffic around the
failed path.
The mechanism by which the control protocol achieves its reaction to
the path failure depends on the capabilities of the protocol. A
protocol which is tightly bound to the failing data protocol may wish
to emulate a control protocol failure across the path (such as
tearing down an adjacency or peer in a routing protocol that supports
only the failed data protocol.) Note that this should not be
interpreted as BFD replacing the control protocol liveness mechanism,
if any, as the control protocol may rely on mechanisms not verified
by BFD (multicast, for instance) so BFD most likely cannot detect all
Katz, Ward [Page 3]
Internet Draft Generic Application of BFD July, 2005
failures that would impact the control protocol. However, a control
protocol may choose to use BFD session state information to more
rapidly detect an impending control protocol failure, particularly if
the control protocol operates in band (over the data protocol.)
If the control protocol has a more explicit mechanism for announcing
path state, it is preferable to use that mechanism rather than
impacting the connectivity of the control protocol (since the control
protocol may be supporting other data protocols that are still
functioning), particularly if the control protocol operates out of
band from the failed data protocol.
4. 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 not attempt to pass
traffic to that remote system, so the local system may wish to take
internal measures to accomplish this. Bootstrapping of the BFD
session is likely to be derived from configuration information in
this case.
There is no need to exchange endpoints or discriminator values via
any other mechanism than configuration (via OSS or any other means)
as the endpoints must be known and configured by the same means.
5. 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 ADMIN
DOWN state prior to the outage.
Katz, Ward [Page 4]
Internet Draft Generic Application of BFD July, 2005
6. 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.)
Normative References
[BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection",
draft-ietf-bfd-base-03.txt, July, 2005.
[BFD-1HOP] Katz, D., and Ward, D., "BFD for IPv4 and IPv6 (Single
Hop)", draft-ietf-bfd-v4v6-1hop-03.txt, July, 2005.
[BFD-MPLS] Aggarwal, R., and Kompella, K., "BFD for MPLS LSPs",
draft-ietf-bfd-mpls-01.txt, February, 2005.
[BFD-MULTI] Katz, D., and Ward, D., "BFD for Multihop Paths", draft-
ietf-bfd-multihop-03.txt, July, 2005.
[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
Katz, Ward [Page 5]
Internet Draft Generic Application of BFD July, 2005
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
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
Katz, Ward [Page 6]
Internet Draft Generic Application of BFD July, 2005
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 Internet Society (2005).
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 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 January, 2006.
Katz, Ward [Page 7]
