draft-ietf-bfd-generic-04.txt   draft-ietf-bfd-generic-05.txt 
Network Working Group D. Katz Network Working Group D. Katz
Internet Draft Juniper Networks Internet Draft Juniper Networks
D. Ward Intended status: Proposed Standard D. Ward
Cisco Systems Cisco Systems
Expires: July, 2008 January, 2008 Expires: August, 2009 February 5, 2009
Generic Application of BFD Generic Application of BFD
draft-ietf-bfd-generic-04.txt draft-ietf-bfd-generic-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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 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
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
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.
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
document are to be interpreted as described in RFC-2119 [KEYWORDS]. document are to be interpreted as described in RFC-2119 [KEYWORDS].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Basic Interaction Between BFD Sessions and Clients . . . . . . 5
3.1 Session State Hysteresis . . . . . . . . . . . . . . . . . 5
3.2 AdminDown State . . . . . . . . . . . . . . . . . . . . . 5
3.3 Hitless Establishment/Reestablishment of BFD State . . . . 5
4. Control Protocol Interactions . . . . . . . . . . . . . . . . 6
4.1 Adjacency Establishment . . . . . . . . . . . . . . . . . 6
4.2 Reaction to BFD State Changes . . . . . . . . . . . . . . 7
4.2.1 Control Protocols with a Single Data Protocol . . . . . 7
4.2.2 Control Protocols with Multiple Data Protocols . . . . . 8
4.2.2.1 Shared Topologies . . . . . . . . . . . . . . . . . . 8
4.2.2.2 Independent Topologies . . . . . . . . . . . . . . . . 8
4.3 Interactions with Graceful Restart Mechanisms . . . . . . 9
4.3.1 BFD Fate Independent of the Control Plane . . . . . . . 9
4.3.2 BFD Shares Fate with the Control Plane . . . . . . . . . 9
4.3.2.1 Control Protocols with Planned Restart Signaling . . 10
4.3.2.2 Control Protocols Without Planned Restart Signaling 10
4.4 Interactions with Multiple Control Protocols . . . . . . 10
5. Interactions with Non-Protocol Functions . . . . . . . . . . 11
6. Data Protocols and Demultiplexing . . . . . . . . . . . . . 12
7. Multiple Link Subnetworks . . . . . . . . . . . . . . . . . 12
7.1 Complete Decoupling . . . . . . . . . . . . . . . . . . 12
7.2 Layer N-1 Hints . . . . . . . . . . . . . . . . . . . . 12
7.3 Aggregating BFD Sessions . . . . . . . . . . . . . . . . 13
7.4 Combinations of Scenarios . . . . . . . . . . . . . . . 13
8. Other Application Issues . . . . . . . . . . . . . . . . . . 13
9. Interoperability Issues . . . . . . . . . . . . . . . . . . 14
10. Specific Protocol Interactions (Non-Normative) . . . . . . 14
10.1 BFD Interactions with OSPFv2, OSPFv3, and IS-IS . . . . 14
10.1.1 Session Establishment . . . . . . . . . . . . . . 15
10.1.2 Reaction to BFD State Changes . . . . . . . . . . 15
10.1.3 OSPF Virtual Links . . . . . . . . . . . . . . . . 15
10.2 Interactions with BGP . . . . . . . . . . . . . . . . . 15
10.3 Interactions with RIP . . . . . . . . . . . . . . . . . 16
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17
12. Security Considerations . . . . . . . . . . . . . . . . . . 17
13. References . . . . . . . . . . . . . . . . . . . . . . . . 17
13.1 Normative References . . . . . . . . . . . . . . . . . 17
13.2 Informative References . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
Changes from the previous draft . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The Bidirectional Forwarding Detection protocol [BFD] provides a The Bidirectional Forwarding Detection protocol [BFD] provides a
liveness detection mechanism that can be utilized by other network liveness detection mechanism that can be utilized by other network
components for which their integral liveness mechanisms are either components for which their integral liveness mechanisms are either
too slow, inappropriate, or nonexistent. Other drafts have detailed too slow, inappropriate, or nonexistent. Other drafts have detailed
the use of BFD with specific encapsulations ([BFD-1HOP], [BFD-MULTI], the use of BFD with specific encapsulations ([BFD-1HOP], [BFD-MULTI],
[BFD-MPLS]). As the utility of BFD has become understood, there have [BFD-MPLS]). As the utility of BFD has become understood, there have
been calls to specify BFD interactions with a growing list of network been calls to specify BFD interactions with a growing list of network
functions. Rather than producing a long series of short documents on functions. Rather than producing a long series of short documents on
skipping to change at page 5, line 44 skipping to change at page 6, line 44
scenarios for the network to be in a state such that the control scenarios for the network to be in a state such that the control
protocol is capable of coming up, but the BFD session cannot be protocol is capable of coming up, but the BFD session cannot be
established, and, more particularly, data cannot be forwarded. To established, and, more particularly, data cannot be forwarded. To
avoid this situation, it would be beneficial to not allow the control avoid this situation, it would be beneficial to not allow the control
protocol to establish a neighbor adjacency. However, this would protocol to establish a neighbor adjacency. However, this would
preclude the operation of the control protocol in an environment in preclude the operation of the control protocol in an environment in
which not all systems support BFD. which not all systems support BFD.
Therefore, the establishment of control protocol adjacencies SHOULD Therefore, the establishment of control protocol adjacencies SHOULD
be blocked if both systems are willing to establish a BFD session but be blocked if both systems are willing to establish a BFD session but
a BFD session cannot be established. A system is known to be willing a BFD session cannot be established. One method for determining that
to establish a BFD session if the control protocol carries signaling both systems are willing to establish a BFD session is if the control
that indicates that both systems are willing to establish a BFD protocol carries explicit signaling of this fact. If there is no
session, or it is known that the remote system is BFD-capable and explicit signaling, the willingness to establish a BFD session may be
BFD-enabled (the means of determining this are outside the scope of determined by means outside the scope of this specification.
this specification.)
If it is believed that the neighboring system does not support BFD, If it is believed that the neighboring system does not support BFD,
the establishment of a control protocol adjacency SHOULD NOT be the establishment of a control protocol adjacency SHOULD NOT be
blocked. blocked.
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
skipping to change at page 6, line 32 skipping to change at page 7, line 31
blocked by the absence of a BFD session, the assumptions of the blocked by the absence of a BFD session, the assumptions of the
control protocol may be violated, with unpredictable results. control protocol may be violated, with unpredictable results.
4.2. Reaction to BFD Session State Changes 4.2. Reaction to BFD Session State Changes
If a BFD session transitions from state Up to AdminDown, or the If a BFD session transitions from state Up to AdminDown, or the
session transitions from Up to Down because the remote system is session transitions from Up to Down because the remote system is
indicating that the session is in state AdminDown, clients SHOULD NOT indicating that the session is in state AdminDown, clients SHOULD NOT
take any control protocol action. take any control protocol action.
Otherwise, the mechanism by which the control protocol reacts to a For other transitions from state Up to Down, the mechanism by which
path failure signaled by BFD depends on the capabilities of the the control protocol reacts to a path failure signaled by BFD depends
protocol. on the capabilities of the protocol, as specified in the following
subsections.
4.2.1. Control Protocols with a Single Data Protocol 4.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
skipping to change at page 14, line 38 skipping to change at page 15, line 38
be advertised in ISIS LSPs in order to signal a lack of connectivity. be advertised in ISIS LSPs in order to signal a lack of connectivity.
Otherwise, a failing BFD session should be signaled by simulating an Otherwise, a failing BFD session should be signaled by simulating an
ISIS adjacency failure. ISIS adjacency failure.
OSPF has a planned restart signaling mechanism, whereas ISIS does OSPF has a planned restart signaling mechanism, whereas ISIS does
not. The appropriate mechanisms outlined in section 3.3 should be not. The appropriate mechanisms outlined in section 3.3 should be
used. used.
10.1.3. OSPF Virtual Links 10.1.3. OSPF Virtual Links
If it is desired to use BFD for failure detction of OSPF Virtual If it is desired to use BFD for failure detection of OSPF Virtual
Links, the mechanism described in [BFD-MULTI] MUST be used, since Links, the mechanism described in [BFD-MULTI] MUST be used, since
OSPF Virtual Links may traverse an arbitrary number of hops. BFD OSPF Virtual Links may traverse an arbitrary number of hops. BFD
Authentication SHOULD be used and is strongly encouraged. Authentication SHOULD be used and is strongly encouraged.
10.2. Interactions with BGP 10.2. Interactions with BGP
BFD may be useful with EBGP sessions [BGP] in order to more rapidly 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 trigger topology changes in the face of path failure. As noted in
section 3.4, it is generally unwise for IBGP sessions to interact section 3.4, it is generally unwise for IBGP sessions to interact
with BFD if the underlying IGP is already doing so. with BFD if the underlying IGP is already doing so.
EBGP sessions being advised by BFD may establish either a one hop EBGP sessions being advised by BFD may establish either a one hop
[BFD-1HOP] or a multihop [BFD-MULTIHOP] session, depending on whether [BFD-1HOP] or a multihop [BFD-MULTIHOP] session, depending on whether
the neighbor is immediately adjacent or not. The BFD session should the neighbor is immediately adjacent or not. The BFD session should
be established to the BGP neighbor (as opposed to any other Next Hop be established to the BGP neighbor (as opposed to any other Next Hop
advertised in BGP.) advertised in BGP.) BFD Authentication SHOULD be used and is
strongly encouraged.
[BGP-GRACE] describes a Graceful Restart mechanism for BGP. If [BGP-GRACE] describes a Graceful Restart mechanism for BGP. If
Graceful Restart is not taking place on an EBGP session, and the Graceful Restart is not taking place on an EBGP session, and the
corresponding BFD session fails, the EBGP session should be torn down corresponding BFD session fails, the EBGP session should be torn down
in accordance with section 3.2. If Graceful Restart is taking place, in accordance with section 3.2. If Graceful Restart is taking place,
the basic procedures in section 3.3 applies. BGP Graceful Restart the basic procedures in section 3.3 applies. BGP Graceful Restart
does not signal planned restarts, so section 3.3.2.2 applies. If does not signal planned restarts, so section 3.3.2.2 applies. If
Graceful Restart is aborted due to the rules described in section Graceful Restart is aborted due to the rules described in section
3.3, the "receiving speaker" should act as if the "restart timer" 3.3, the "receiving speaker" should act as if the "restart timer"
expired (as described in [BGP-GRACE].) expired (as described in [BGP-GRACE].)
skipping to change at page 16, line 5 skipping to change at page 17, line 5
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 (after 180 seconds.) However, if an implementation keeps track of
all of the routes received from each neighbor, all of the routes from all of the routes received from each neighbor, all of the routes from
the neighbor corresponding to the failed BFD session should be timed the neighbor corresponding to the failed BFD session should be timed
out, regardless of the next hop specified therein, and thereby out, regardless of the next hop specified therein, and thereby
avoiding the lingering route problem. avoiding the lingering route problem.
Normative References 11. IANA Considerations
This document has no actions for IANA.
12. Security Considerations
This specification does not raise any additional security issues
beyond those of the specifications referred to in the list of
normative references.
13. References
13.1. Normative References
[BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection",
draft-ietf-bfd-base-07.txt, January, 2008. draft-ietf-bfd-base-09.txt, February, 2009.
[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-07.txt, January, 2008. Hop)", draft-ietf-bfd-v4v6-1hop-08.txt, February, 2009.
[BFD-MPLS] Aggarwal, R., and Kompella, K., "BFD for MPLS LSPs", [BFD-MPLS] Aggarwal, R.,Kompella, K., et al, "BFD for MPLS LSPs",
draft-ietf-bfd-mpls-04.txt, March, 2007. draft-ietf-bfd-mpls-07.txt, June, 2008.
[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-06.txt, January, 2008. ietf-bfd-multihop-07.txt, February, 2009.
13.2. Informative References
[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., Chen, E., et al, "Graceful Restart Mechanism [BGP-GRACE] Sangli, S., Chen, E., et al, "Graceful Restart Mechanism
for BGP", RFC 4724, January, 2007. 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.
skipping to change at page 17, line 5 skipping to change at page 18, line 17
[OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[OSPFv3] Coltun, R., et al, "OSPF for IPv6", RFC 2740, December 1999. [OSPFv3] Coltun, R., et al, "OSPF for IPv6", RFC 2740, December 1999.
[OSPF-GRACE] Moy, J., et al, "Graceful OSPF Restart", RFC 3623, [OSPF-GRACE] Moy, J., et al, "Graceful OSPF Restart", RFC 3623,
November 2003. November 2003.
[RIP] Malkin, G., "RIP Version 2", RFC 2453, November, 1998. [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 Authors' Addresses
Dave Katz Dave Katz
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, California 94089-1206 USA Sunnyvale, California 94089-1206 USA
Phone: +1-408-745-2000 Phone: +1-408-745-2000
Email: dkatz@juniper.net Email: dkatz@juniper.net
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
A section was added to more completely describe the interaction All changes are purely editorial in nature.
between a BFD session and its clients.
Rules for handling session failures in non-protocol applications were
clarified.
A section was 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 (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 July, 2008. This document expires in August, 2009.
 End of changes. 19 change blocks. 
94 lines changed or deleted 96 lines changed or added

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