draft-ietf-bfd-generic-01.txt   draft-ietf-bfd-generic-02.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: April, 2006 October, 2005 Expires: December, 2006 June, 2006
Generic Application of BFD Generic Application of BFD
draft-ietf-bfd-generic-01.txt draft-ietf-bfd-generic-02.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 36 skipping to change at page 1, line 36
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 Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. 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 in environments not specifically Forwarding Detection (BFD) protocol. Comments on this draft should
documented in other specifications. Comments on this draft should be be directed to rtg-bfd@ietf.org.
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].
1. Introduction 1. Introduction
BFD [BFD] provides a liveness detection mechanism that can be The Bidirectional Forwarding Detection protocol [BFD] provides a
utilized by other network components for which their integral liveness detection mechanism that can be utilized by other network
liveness mechanisms are either too slow, inappropriate, or components for which their integral liveness mechanisms are either
nonexistent. Other drafts have detailed the use of BFD in specific too slow, inappropriate, or nonexistent. Other drafts have detailed
situations ([BFD-1HOP], [BFD-MULTI], [BFD-MPLS]). As the utility of the use of BFD with specific encapsulations ([BFD-1HOP], [BFD-MULTI],
BFD has become understood, there have been calls to specify BFD [BFD-MPLS]). As the utility of BFD has become understood, there have
interactions with a growing list of network functions. Rather than been calls to specify BFD interactions with a growing list of network
producing a long series of short documents on the application of BFD, functions. Rather than producing a long series of short documents on
it seemed worthwhile to describe the interactions between BFD and the application of BFD, it seemed worthwhile to describe the
other network functions in a broad way. interactions between BFD and other network functions in a broad way.
This document describes the generic application of BFD. Applications This document describes the generic application of BFD. Specific
with specific requirements should be spelled out in specific protocol applications are provided for illustrative purposes.
documents.
2. Overview 2. Overview
The Bidirectional Forwarding Detection (BFD) specification defines a The Bidirectional Forwarding Detection (BFD) specification defines a
protocol with simple and specific semantics. Its sole purpose is to protocol with simple and specific semantics. Its sole purpose is to
verify connectivity between a pair of systems, for a particular data verify connectivity between a pair of systems, for a particular data
protocol across a path (which may be of any technology, length, or 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 OSI layer). The promptness of the detection of a path failure can be
controlled by trading off protocol overhead and system load with controlled by trading off protocol overhead and system load with
detection times. detection times.
skipping to change at page 3, line 25 skipping to change at page 3, line 22
An implementation SHOULD establish only a single BFD session per data An implementation SHOULD establish only a single BFD session per data
protocol path, regardless of the number of applications that wish to protocol path, regardless of the number of applications that wish to
utilize it. There is no additional value in having multiple BFD utilize it. There is no additional value in having multiple BFD
sessions to the same endpoints. If multiple applications request sessions to the same endpoints. If multiple applications request
different session parameters, it is a local issue as to how to different session parameters, it is a local issue as to how to
resolve the parameter conflicts. BFD in turn will notify all resolve the parameter conflicts. BFD in turn will notify all
applications bound to a session when a session state change occurs. applications bound to a session when a session state change occurs.
BFD should be viewed as having an advisory role to the protocol or BFD should be viewed as having an advisory role to the protocol or
protocols or other network function with which it is interacting, protocols or other network functions with which it is interacting,
which will then use their own mechanisms to effect any state which will then use their own mechanisms to effect any state
transitions. The interaction is very much at arm's length, which transitions. The interaction is very much at arm's length, which
keeps things simple and decoupled. In particular, BFD explicitly keeps things simple and decoupled. In particular, BFD explicitly
does not carry application-specific information, partly for does not carry application-specific information, partly for
architectural reasons, and partly because BFD may have curious and architectural reasons, and partly because BFD may have curious and
unpredictable latency characteristics and as such makes a poor unpredictable latency characteristics and as such makes a poor
transport mechanism. 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 3. Control Protocol Interactions
The object when BFD interacts with a control protocol is to advise Very common client applications of BFD are control protocols, such as
the control protocol of the connectivity of the data protocol. In routing protocols. The object when BFD interacts with a control
the case of routing protocols, for example, this allows the protocol is to advise the control protocol of the connectivity of the
connectivity failure to trigger the rerouting of traffic around the data protocol. In the case of routing protocols, for example, this
failed path. allows the connectivity failure to trigger the rerouting of traffic
around the failed path more quickly than the native detection
mechanisms.
3.1. Session Establishment
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. In most cases it is not desirable to
preclude the control protocol from establishing an adjacency if the preclude the control protocol from establishing an adjacency if the
BFD session cannot be established (usually because the neighbor does BFD session cannot be established (usually because the neighbor does
not support BFD.) not support BFD.)
If the control protocol carries signaling that indicates the If the control protocol carries signaling that indicates the
willingness of each system to establish a BFD session, the lack of a 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 BFD session MAY be used to block establishment of a control protocol
adjacency. adjacency.
If it appears that the neighboring system does not support BFD If it appears that the neighboring system does not support BFD
(because the control protocol adjacency was established but no BFD (because the control protocol adjacency was established but no BFD
Control packets have been received from the neighbor) it is useful to Control packets have been received from the neighbor) a system MAY
increase the interval between transmitted BFD Control packets beyond increase the interval between transmitted BFD Control packets beyond
the minimum. This will have minimal impact on BFD session the minimum specified in [BFD]. This will have negligible impact on
establishment if the neighbor decides to run BFD after all, since BFD BFD session establishment if the neighbor decides to run BFD after
Control packets will be sent on an event-driven basis once the first all, since BFD Control packets will be sent on an event-driven basis
packet is seen from the neighbor. once the first packet is seen from the neighbor.
The mechanism by which the control protocol achieves its reaction to The setting of BFD's various timing parameters and modes are not
the path failure depends on the capabilities of the protocol. A subject to standardization. Note that all protocols sharing a
protocol which is tightly bound to the failing data protocol may wish session will operate using the same parameters. The mechanism for
to emulate a control protocol failure across the path (such as choosing the parameters among those desired by the various protocols
tearing down an adjacency or peer in a routing protocol that supports are outside the scope of this specification. It is generally useful
only the failed data protocol.) Note that this should not be 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.
3.2. Reaction to BFD Session State Changes
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
A control protocol that is tightly bound to a single failing data
protocol SHOULD take action to ensure that data traffic is no longer
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.)
If the control protocol has a more explicit mechanism for announcing Therefore, when a BFD session transitions from Up to Down, action
path state, it is preferable to use that mechanism rather than SHOULD be taken in the control protocol to signal the lack of
impacting the connectivity of the control protocol (since the control connectivity for the data protocol over which BFD is running. If the
protocol may be supporting other data protocols that are still control protocol has an explicit mechanism for announcing path state,
functioning), particularly if the control protocol operates out of a system SHOULD use that mechanism rather than impacting the
band from the failed data protocol. connectivity of the control protocol, particularly if the control
protocol operates out of band from the failed data protocol.
However, if such a mechanism is not available, a control protocol
timeout SHOULD be emulated for the associated neighbor.
3.2.2. Control Protocols with Multiple Data Protocols
Slightly different mechanisms are used if the control protocol
supports the routing of multiple data protocols, depending on whether
the control protocol supports separate topologies for each data
protocol.
3.2.2.1. Shared Topologies
With a shared topology, if one of the data protocols fails (as
signaled by the associated BFD session), it is necessary to consider
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
data protocol (and such traffic would be black holed indefinitely.)
Therefore, when a BFD session transitions from Up to Down, action
SHOULD be taken in the control protocol to signal the lack of
connectivity for all data protocols sharing the topology. If this
cannot be signaled otherwise, a control protocol timeout SHOULD be
emulated for the associated neighbor.
3.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 Up to Down, action
SHOULD be taken in the control protocol to signal the lack of
connectivity for the data protocol over which BFD is running.
Generally this can be done without impacting the connectivity of
other data protocols (since otherwise it is very difficult to support
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
A number of control protocols support Graceful Restart mechanisms.
These mechanisms are designed to allow a 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 that does not
necessarily share fate with 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 the Control Plane Independent (C)
bit whether or not BFD shares fate with the control plane. This
information is used to determine the actions to 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 is NOT viable (the
forwarding plane is not operating.)
If the control protocol has a Graceful Restart mechanism, BFD may be If the control protocol has a Graceful Restart mechanism, BFD may be
used in conjunction with this mechanism. If BFD is implemented in used in conjunction with this mechanism. The interaction between BFD
the forwarding plane, a session failure implies that data can no and the control protocol depends on the capabilities of the control
longer be forwarded. In this case, any Graceful Restart in progress protocol, and whether or not BFD shares fate with the control plane.
should be aborted. See [BFD-1HOP] for a more detailed discussion. In particular, it may be desirable for a BFD session failure to abort
the Graceful Restart process and allow the failure to be visible to
the network.
3.3.1. BFD Fate Independent of the Control Plane
If BFD is 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.
3.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.
3.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.
3.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. 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 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 (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 to interact with BFD. In this example, because IBGP is dependent on
OSPF for its routing information, the faster failure detection OSPF for its routing information, the faster failure detection
relayed to IBGP may actually be detrimental. The cost of a peer relayed to IBGP may actually be detrimental. The cost of a peer
state transition is high in BGP, and OSPF will naturally heal the state transition is high in BGP, and OSPF will naturally heal the
path through the network if it were to receive the failure detection. 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 In general, it is best for the protocol at the lowest point in the
skipping to change at page 6, line 31 skipping to change at page 10, line 31
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.) 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. 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. 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. 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. 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 data protocols are advertised in the ISIS Hello, and
independent topologies are in use, the failing data protocol should
no longer be advertised in ISIS Hello packets in order to signal a
lack of connectivity for that protocol. 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. 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. 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. 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 Normative References
[BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection",
draft-ietf-bfd-base-04.txt, October, 2005. draft-ietf-bfd-base-05.txt, June, 2006.
[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-04.txt, October, 2005. Hop)", draft-ietf-bfd-v4v6-1hop-05.txt, June, 2006.
[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-02.txt, July, 2005. draft-ietf-bfd-mpls-03.txt, June, 2006.
[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-04.txt, June, 2006.
[BGP] Rekhter, Y., Li, T. et al, "A Border Gateway Protocol 4
(BGP-4)", RFC 4271, January, 2006.
[BGP-GRACE] Sangli, S., Rekhter, Y., et al, "Graceful Restart
Mechanism for BGP", draft-ietf-idr-restart-12.txt, June, 2006.
[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
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 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. 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 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
This document has no actions for IANA. This document has no actions for IANA.
skipping to change at page 8, line 7 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
Text concerning the interaction between BFD and a hierarchy of Control protocol-specific interactions were moved from [BFD-1HOP] to
control protocols was added. A discussion of bootstrapping and this document, and brief mentions of BGP and RIP were added.
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
skipping to change at page 8, line 39 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 (2005). Copyright (C) The Internet Society (2006).
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 AND THE INTERNET
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 April, 2006. This document expires in December, 2006.
 End of changes. 26 change blocks. 
59 lines changed or deleted 345 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/