draft-ietf-bfd-generic-00.txt   draft-ietf-bfd-generic-01.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: January, 2006 July, 2005 Expires: April, 2006 October, 2005
Generic Application of BFD Generic Application of BFD
draft-ietf-bfd-generic-00.txt draft-ietf-bfd-generic-01.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 3, line 42 skipping to change at page 3, line 42
transport mechanism. transport mechanism.
3. Control Protocol Interactions 3. Control Protocol Interactions
The object when BFD interacts with a control protocol is to advise The object when BFD interacts with a control protocol is to advise
the control protocol of the connectivity of the data protocol. In the control protocol of the connectivity of the data protocol. In
the case of routing protocols, for example, this allows the the case of routing protocols, for example, this allows the
connectivity failure to trigger the rerouting of traffic around the connectivity failure to trigger the rerouting of traffic around the
failed path. failed path.
BFD sessions are typically bootstrapped by the control protocol,
using the mechanism (discovery, configuration) used by the control
protocol to find neighbors. In most cases it is not desirable to
preclude the control protocol from establishing an adjacency if the
BFD session cannot be established (usually because the neighbor does
not support BFD.)
If the control protocol carries signaling that indicates the
willingness of each system to establish a BFD session, the lack of a
BFD session may be used to block establishment of a control protocol
adjacency.
If it appears that the neighboring system does not support BFD
(because the control protocol adjacency was established but no BFD
Control packets have been received from the neighbor) it is useful to
increase the interval between transmitted BFD Control packets beyond
the minimum. This will have minimal 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.
The mechanism by which the control protocol achieves its reaction to The mechanism by which the control protocol achieves its reaction to
the path failure depends on the capabilities of the protocol. A the path failure depends on the capabilities of the protocol. A
protocol which is tightly bound to the failing data protocol may wish protocol which is tightly bound to the failing data protocol may wish
to emulate a control protocol failure across the path (such as to emulate a control protocol failure across the path (such as
tearing down an adjacency or peer in a routing protocol that supports tearing down an adjacency or peer in a routing protocol that supports
only the failed data protocol.) Note that this should not be only the failed data protocol.) 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 4, line 16 skipping to change at page 4, line 37
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.)
If the control protocol has a more explicit mechanism for announcing If the control protocol has a more explicit mechanism for announcing
path state, it is preferable to use that mechanism rather than path state, it is preferable to use that mechanism rather than
impacting the connectivity of the control protocol (since the control impacting the connectivity of the control protocol (since the control
protocol may be supporting other data protocols that are still protocol may be supporting other data protocols that are still
functioning), particularly if the control protocol operates out of functioning), particularly if the control protocol operates out of
band from the failed data protocol. band from the failed data protocol.
If the control protocol has a Graceful Restart mechanism, BFD may be
used in conjunction with this mechanism. If BFD is implemented in
the forwarding plane, a session failure implies that data can no
longer be forwarded. In this case, any Graceful Restart in progress
should be aborted. See [BFD-1HOP] for a more detailed discussion.
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. 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 not attempt to pass a remote system fails, it may be desirable to avoid passing traffic
traffic to that remote system, so the local system may wish to take to that remote system, so the local system may wish to take internal
internal measures to accomplish this. Bootstrapping of the BFD measures to accomplish this (such as withdrawing a static route and
session is likely to be derived from configuration information in withdrawing that route from routing protocols.)
this case.
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 There is no need to exchange endpoints or discriminator values via
any other mechanism than configuration (via OSS or any other means) any mechanism other than configuration (via Operational Support
as the endpoints must be known and configured by the same means. Systems or any other means) as the endpoints must be known and
configured by the same means.
5. Other Application Issues 5. 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 on 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
initial packet if the discriminator values have not been exchanged.
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 ADMIN
DOWN state prior to the outage. DOWN state prior to the outage.
6. 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.
The interaction between BFD and other protocols and control functions The interaction between BFD and other protocols and control functions
is very loosely coupled. The actions taken are based on existing is very loosely coupled. The actions taken are based on existing
mechanisms in those protocols and functions, so interoperability mechanisms in those protocols and functions, so interoperability
problems are very unlikely unless BFD is applied in contradictory problems are very unlikely unless BFD is applied in contradictory
ways (such as a BFD session failure causing one implementation to go ways (such as a BFD session failure causing one implementation to go
down and another implementation to come up.) down and another implementation to come up.)
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-03.txt, July, 2005. draft-ietf-bfd-base-04.txt, October, 2005.
[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-03.txt, July, 2005. Hop)", draft-ietf-bfd-v4v6-1hop-04.txt, October, 2005.
[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-01.txt, February, 2005. draft-ietf-bfd-mpls-02.txt, July, 2005.
[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-03.txt, July, 2005. ietf-bfd-multihop-03.txt, July, 2005.
[DIFFSERV] Nichols, K. et al, "Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC
2474, December, 1998.
[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
Security Considerations Security Considerations
This specification does not raise any additional security issues This specification does not raise any additional security issues
beyond those of the specifications referred to in the list of beyond those of the specifications referred to in the list of
normative references. normative references.
IANA Considerations IANA Considerations
skipping to change at page 6, line 31 skipping to change at page 8, line 5
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
Text concerning the interaction between BFD and a hierarchy of
control protocols was added. A discussion of bootstrapping and
session establishment was included. Graceful Restart interactions
were mentioned. A section on fine-grained path demultiplexing was
added.
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
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 7, line 33 skipping to change at page 9, line 13
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 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 January, 2006. This document expires in April, 2006.
 End of changes. 14 change blocks. 
14 lines changed or deleted 88 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/