< draft-ietf-isis-bfd-tlv-02.txt   draft-ietf-isis-bfd-tlv-03.txt >
IS-IS for IP Internets C. Hopps IS-IS for IP Internets C. Hopps
Internet-Draft L. Ginsberg Internet-Draft L. Ginsberg
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: July 8, 2010 January 4, 2010 Expires: July 6, 2011 January 2, 2011
IS-IS BFD Enabled TLV IS-IS BFD Enabled TLV
draft-ietf-isis-bfd-tlv-02 draft-ietf-isis-bfd-tlv-03
Abstract Abstract
This document describes a TLV for use in the IS-IS routing protocol This document describes a type-length-value (TLV) for use in the
that allows for the proper use of the Bidirectional Forwarding IS-IS routing protocol that allows for the proper use of the
Detection protocol (BFD). There exist certain scenarios in which Bidirectional Forwarding Detection protocol (BFD). There exist
IS-IS will not react appropriately to a BFD detected forwarding plane certain scenarios in which IS-IS will not react appropriately to a
failure without use of either this TLV or some other method. BFD detected forwarding plane failure without use of either this TLV
or some other method.
Requirements Language Requirements Language
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 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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 Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
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 This Internet-Draft will expire on July 6, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 8, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Solution . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The Solution . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. State Definitions . . . . . . . . . . . . . . . . . . . . . 4 3.1. State Definitions . . . . . . . . . . . . . . . . . . . . . 4
3.2. Adjacency Establishment and Maintenance . . . . . . . . . . 4 3.2. Adjacency Establishment and Maintenance . . . . . . . . . . 4
3.3. Advertisement of Topology Specific IS Neighbors . . . . . . 5 3.3. Advertisement of Topology Specific IS Neighbors . . . . . . 5
4. Transition . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Transition . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . 6 5. Graceful Restart . . . . . . . . . . . . . . . . . . . . . . . 6
6. The BFD Enabled TLV . . . . . . . . . . . . . . . . . . . . . . 6 6. The BFD Enabled TLV . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. Normative References . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
The Bidirectional Forwarding Detection protocol [I-D.ietf-bfd-base] The Bidirectional Forwarding Detection (BFD) protocol [RFC5880] is a
is a protocol that allows for detection of a forwarding plane failure protocol that allows for detection of a forwarding plane failure
between two routers. A router can use [I-D.ietf-bfd-base] to between two routers. A router can use [RFC5880] to validate that a
validate that a peer router's forwarding ability is functioning. peer router's forwarding ability is functioning.
One specific application of BFD as described in One specific application of BFD as described in [RFC5882] is to
[I-D.ietf-bfd-generic] is to verify the forwarding ability of an verify the forwarding ability of an IS-IS [RFC1195] router's
IS-IS [RFC1195] router's adjacencies; however, the method described adjacencies; however, the method described in [RFC5882] does not
in [I-D.ietf-bfd-generic] does not allow for certain failure allow for certain failure scenarios. We will define a TLV that will
scenarios. We will define a TLV that will allow for proper response allow for proper response to the detection of all forwarding failures
to the detection of all forwarding failures where the use of BFD is where the use of BFD is employed with IS-IS.
employed with IS-IS.
2. The Problem 2. The Problem
We observe that to allow for mixed use (i.e., some routers running We observe that to allow for mixed use (i.e., some routers running
BFD and some not) [I-D.ietf-bfd-generic] does not require a BFD BFD and some not) [RFC5882] does not require a BFD session be
session be established prior to the establishment of an IS-IS established prior to the establishment of an IS-IS adjacency. Thus,
adjacency. Thus, if a router A has neighbors B and C, and B does not if a router A has neighbors B and C, and B does not support BFD, A
support BFD, A would still form adjacencies with B and C, and would would still form adjacencies with B and C, and would only establish a
only establish a BFD session with C. BFD session with C.
The problem with this solution is that it assumes that the The problem with this solution is that it assumes that the
transmission and receipt of IS-IS IIHs shares fate with forwarded transmission and receipt of IS-IS Hellos (IIHs) shares fate with
data packets. This is not a fair assumption to make given that the forwarded data packets. This is not a fair assumption to make given
primary use of BFD is to protect IPv4 (and IPv6) forwarding and IS-IS that the primary use of BFD is to protect IPv4 (and IPv6) forwarding
does not utilize IPv4 or IPv6 for sending or receiving its hellos. and IS-IS does not utilize IPv4 or IPv6 for sending or receiving its
hellos.
Thus, if we consider our previous example, and if C is currently Thus, if we consider our previous example, and if C is currently
experiencing an IPv4 forwarding failure that allows for IS-IS IIHs to experiencing an IPv4 forwarding failure that allows for IIHs to be
be sent and received, when A first starts (or restarts) A will assume sent and received, when A first starts (or restarts) A will assume
that C simply does not support BFD, will form an adjacency with C, that C simply does not support BFD, will form an adjacency with C,
and may incorrectly forward IPv4 traffic through C. and may incorrectly forward IPv4 traffic through C.
3. The Solution 3. The Solution
A simple solution to this problem is for an IS-IS router to advertise A simple solution to this problem is for an IS-IS router to advertise
that it has BFD enabled on a given interface. It can do this through that it has BFD enabled on a given interface. It can do this through
the inclusion of a TLV in its IIHs, and indeed that is our proposal. the inclusion of a TLV in its IIHs as described in this document.
When sending an IIH on a BFD enabled interface, a router which When sending an IIH on a BFD enabled interface, a router which
supports this extension MUST include the BFD enabled TLV in its IIH. supports this extension MUST include the BFD enabled TLV in its IIH.
The contents of the TLV MUST indicate what topologies/protocols The contents of the TLV MUST indicate what topologies/protocols
[RFC5120] have been enabled for BFD by including the appropriate [RFC5120] have been enabled for BFD by including the appropriate
MTID/NLPID pairs. Multi-Topology Identifier (MTID)/ Network Layer Protocol Identifier
(NLPID) pairs.
When sending an IIH on an interface on which BFD is NOT enabled a When sending an IIH on an interface on which BFD is NOT enabled a
router MUST NOT include the BFD enabled TLV. router MUST NOT include the BFD enabled TLV.
3.1. State Definitions 3.1. State Definitions
The following definitions apply to each IS-IS neighbor: The following definitions apply to each IS-IS neighbor:
For each locally supported MTID/NLPID pair, an For each locally supported MTID/NLPID pair, an
ISIS_TOPO_NLPID_BFD_REQUIRED variable is assigned. If BFD is "ISIS_TOPO_NLPID_BFD_REQUIRED" variable is assigned. If BFD is
supported by both the local system and the neighbor for the MTID/ supported by both the local system and the neighbor for the MTID/
NLPID this variable is set to TRUE. Otherwise the variable is set to NLPID this variable is set to "TRUE". Otherwise the variable is set
FALSE. to "FALSE".
For each locally supported MTID, an ISIS_TOPO_BFD_REQUIRED variable For each locally supported MTID, an "ISIS_TOPO_BFD_REQUIRED" variable
is set to the logical OR of all ISIS_TOPO_NLPID_BFD_REQUIRED is set to the logical "OR" of all "ISIS_TOPO_NLPID_BFD_REQUIRED"
variables associated with that MTID. variables associated with that MTID.
An ISIS_BFD_REQUIRED variable is set to the logical AND of all An "ISIS_BFD_REQUIRED" variable is set to the logical "AND" of all
ISIS_TOPO_BFD_REQUIRED variables. "ISIS_TOPO_BFD_REQUIRED" variables.
For each locally supported MTID/NLPID pair, an ISIS_TOPO_NLPID_STATE For each locally supported MTID/NLPID pair, an
variable is assigned. If ISIS_TOPO_NLPID_BFD_REQUIRED is TRUE, this "ISIS_TOPO_NLPID_STATE" variable is assigned. If
variable follows the BFD session state for that MTID/NLPID (UP == "ISIS_TOPO_NLPID_BFD_REQUIRED" is "TRUE", this variable follows the
TRUE). Otherwise the variable is set to TRUE. BFD session state for that MTID/NLPID ("UP == TRUE"). Otherwise the
variable is set to "TRUE".
For each locally supported topology (MTID), an ISIS_TOPO_USEABLE For each locally supported topology (MTID), an "ISIS_TOPO_USEABLE"
variable is set to the logical AND of the set of variable is set to the logical "AND" of the set of
ISIS_TOPO_NLPID_STATE variables associated with that MTID. "ISIS_TOPO_NLPID_STATE" variables associated with that MTID.
An ISIS_NEIGHBOR_USEABLE variable is set to the logical OR of all An "ISIS_NEIGHBOR_USEABLE" variable is set to the logical "OR" of all
ISIS_TOPO_USEABLE variables. "ISIS_TOPO_USEABLE" variables.
3.2. Adjacency Establishment and Maintenance 3.2. Adjacency Establishment and Maintenance
Whenever ISIS_BFD_REQUIRED is TRUE the following extensions to the Whenever "ISIS_BFD_REQUIRED" is "TRUE" the following extensions to
rules for adjacency establishment and maintenance MUST apply: the rules for adjacency establishment and maintenance MUST apply:
o ISIS_NEIGHBOR_USEABLE MUST be TRUE before the adjacency can o "ISIS_NEIGHBOR_USEABLE" MUST be "TRUE" before the adjacency can
transition from INIT to UP state transition from "INIT" to "UP" state
o When the IS-IS adjacency is UP and ISIS_NEIGHBOR_USEABLE becomes o When the IS-IS adjacency is "UP" and "ISIS_NEIGHBOR_USEABLE"
FALSE the IS-IS adjacency MUST transition to DOWN. becomes "FALSE" the IS-IS adjacency MUST transition to "DOWN".
o On a Point-to-Point circuit whenever ISIS_NEIGHBOR_USEABLE is o On a Point-to-Point circuit whenever "ISIS_NEIGHBOR_USEABLE" is
FALSE, the Three-Way adjacency state MUST be set to DOWN in the "FALSE", the Three-Way adjacency state MUST be set to "DOWN" in
Point-to-Point Three Way Adjacency TLV[RFC5303] in all transmitted the Point-to-Point Three Way Adjacency TLV[RFC5303] in all
IIHs. transmitted IIHs.
o On a LAN circuit whenever ISIS_NEIGHBOR_USEABLE is FALSE, the IS o On a LAN circuit whenever "ISIS_NEIGHBOR_USEABLE" is "FALSE", the
Neighbors TLV advertising the MAC address of the neighbor MUST be IS Neighbors TLV advertising the MAC address of the neighbor MUST
omitted in all transmitted IIHs. be omitted in all transmitted IIHs.
3.3. Advertisement of Topology Specific IS Neighbors 3.3. Advertisement of Topology Specific IS Neighbors
The advertisement of a topology specific IS-neighbor (as well as the The advertisement of a topology specific IS-neighbor (as well as the
use of the neighbor in the topology specific decision process) is use of the neighbor in the topology specific decision process) is
determined by the value of ISIS_TOPO_USEABLE for each topology. If determined by the value of "ISIS_TOPO_USEABLE" for each topology. If
ISIS_TOPO_USEABLE is TRUE then the topology specific neighbor is "ISIS_TOPO_USEABLE" is "TRUE" then the topology specific neighbor is
advertised. If ISIS_TOPO_USEABLE is FALSE then the topology specific advertised. If "ISIS_TOPO_USEABLE" is "FALSE" then the topology
neighbor is NOT advertised. specific neighbor is not advertised.
4. Transition 4. Transition
To allow for a non-disruptive transition to the use of BFD some To allow for a non-disruptive transition to the use of BFD some
amount of time should be allowed before bringing down an UP adjacency amount of time should be allowed before bringing down an "UP"
on a BFD enabled interface when the value of ISIS_BFD_REQUIRED adjacency on a BFD enabled interface when the value of
becomes TRUE as a result of the introduction of the BFD TLV or the "ISIS_BFD_REQUIRED" becomes "TRUE" as a result of the introduction of
modification (by adding a new supported MTID/NLPID) of an existing the BFD TLV or the modification (by adding a new supported MTID/
BFD TLV in a neighbor's IIH. A simple way to do this is to not NLPID) of an existing BFD TLV in a neighbor's IIH. A simple way to
update the adjacency hold-time when receiving such an IIH from a do this is to not update the adjacency hold-time when receiving such
neighbor with whom we have an UP adjacency until an IIH from a neighbor with whom we have an "UP" adjacency until
ISIS_NEIGHBOR_USEABLE becomes TRUE. "ISIS_NEIGHBOR_USEABLE" becomes "TRUE".
If the value of ISIS_BFD_REQUIRED becomes FALSE as a result of the If the value of "ISIS_BFD_REQUIRED" becomes "FALSE" as a result of
removal the BFD TLV or the modification (by removing a supported the removal the BFD TLV or the modification (by removing a supported
MTID/NLPID) of an existing BFD TLV in a neighbor's IIH then BFD MTID/NLPID) of an existing BFD TLV in a neighbor's IIH then BFD
session establishment is no longer required to maintain the adjacency session establishment is no longer required to maintain the adjacency
or transition the adjacency to the UP state. or transition the adjacency to the "UP" state.
If a BFD session is administratively shut down [I-D.ietf-bfd-base] If a BFD session is administratively shut down [RFC5880] and the BFD
and the BFD session state change impacts the value of session state change impacts the value of "ISIS_NEIGHBOR_USEABLE",
ISIS_NEIGHBOR_USEABLE, then IS-IS SHOULD allow time for the then IS-IS SHOULD allow time for the corresponding MTID/NLPID to be
corresponding MTID/NLPID to be removed from the neighbor's BFD TLV by removed from the neighbor's BFD TLV by not updating the adjacency
not updating the adjacency hold time until ISIS_BFD_REQUIRED becomes hold time until "ISIS_BFD_REQUIRED" becomes "FALSE". Note that while
FALSE. Note that while this allows a non-disruptive transition, it this allows a non-disruptive transition, it still enforces
still enforces consistency between the administrative state of the consistency between the administrative state of the BFD session and
BFD session and the MTID/NLPID(s) advertised in the BFD TLV. This is the MTID/NLPID(s) advertised in the BFD TLV. This is necessary to
necessary to provide consistent behavior regardless of whether the provide consistent behavior regardless of whether the BFD AdminDown
BFD AdminDown state is introduced before or after an IS-IS adjacency state is introduced before or after an IS-IS adjacency "UP" state has
UP state has been achieved. been achieved.
5. Graceful Restart 5. Graceful Restart
It is worth considering what if anything should be done when IS-IS is This section describes IS-IS implementation considerations when both
gracefully restarting [RFC5306]. both IS-IS graceful restart [RFC5306] and BFD are co-deployed.
In cases where BFD shares fate with the control plane, it can be In cases where BFD shares fate with the control plane, it can be
expected that BFD session failure may occur in conjunction with the expected that BFD session failure may occur in conjunction with the
control plane restart. In such cases premature abort of IS-IS control plane restart. In such cases premature abort of IS-IS
graceful restart as a result of BFD session failure is undesirable. graceful restart as a result of BFD session failure is undesirable.
Therefore, some mechanism to ignore the BFD session failure for a Therefore, some mechanism to ignore the BFD session failure for a
limited period of time would be beneficial. How this is implemented limited period of time would be beneficial. The issue of the
is beyond the scope of this document. Consult [I-D.ietf-bfd-generic] interaction between graceful restart and BFD is described at length
for further details. in RFC5882. The implementation of this interaction is outside the
scope of this document.
6. The BFD Enabled TLV 6. The BFD Enabled TLV
The BFD enabled TLV is formatted as shown below. The TLV SHALL only The BFD enabled TLV is formatted as shown below. The TLV SHALL only
be included in an IS-IS IIH PDU and only when BFD is enabled for one be included in an IIH and only when BFD is enabled for one or more
or more supported MTID/protocols on the interface over which the IIH supported MTID/protocols on the interface over which the IIH is being
is being sent. The NLPIDs encoded in the TLV are defined in sent. The NLPIDs encoded in the TLV are defined in [ISO9577]
[ISO9577]
Type 139 (suggested - to be assigned by IANA) Type 139 (suggested - to be assigned by IANA)
Length # of octets in the value field (3 to 255) Length # of octets in the value field (3 to 255)
Value three octets specifying the MTID/NLPID for each Value three octets specifying the MTID/NLPID for each
topology/data protocol for which BFD support is enabled topology/data protocol for which BFD support is enabled
No. of octets No. of octets
+-----------------------+ +-----------------------+
|R|R|R|R| MTID | 2 |R|R|R|R| MTID | 2
+-----------------------+ +-----------------------+
skipping to change at page 6, line 49 skipping to change at page 6, line 49
: : : :
+-----------------------+ +-----------------------+
|R|R|R|R| MTID | 2 |R|R|R|R| MTID | 2
+-----------------------+ +-----------------------+
| NLPID | 1 | NLPID | 1
+-----------------------+ +-----------------------+
7. Security Considerations 7. Security Considerations
The TLV defined within this document describes an addition to the The TLV defined within this document describes an addition to the
IS-IS Hello protocol and does not impact the security mechanism of IS-IS Hello protocol. Inappropriate use of this TLV could prevent an
the IS-IS protocol. IS-IS adjacency from forming or lead to failure to detect
bidirectional forwarding failures - each of which is a form of denial
of service. However, a party who can manipulate the contents of this
TLV is already in a position to create such a denial of service by
disrupting IS-IS routing in other ways.
Note that the introduction of this TLV has no impact on the use/
non-use of authentication either by IS-IS or by BFD.
8. IANA Considerations 8. IANA Considerations
The following IS-IS TLV type is defined by this draft. The following IS-IS TLV type is defined by this draft.
Name Value IIH LSP SNP Name Value IIH LSP SNP
---------------------- ----- --- --- --- ---------------------- ----- --- --- ---
BFD Enabled TLV 139 y n n BFD Enabled TLV 139 y n n
Please update the IS-IS TLV Codepoint Registry accordingly. Please update the IS-IS TLV Codepoint Registry accordingly.
Note to RFC Editor: this section may be removed on publication as an
RFC.
9. Acknowledgements 9. Acknowledgements
The authors wish to thank Jeffrey Haas, Matthew Jones, Dave Katz, The authors wish to thank Jeffrey Haas, Matthew Jones, Dave Katz,
Jonathan Moon, Stefano Previdi, Mike Shand, Michael Shiplett and Jonathan Moon, Stefano Previdi, Mike Shand, Michael Shiplett and
David Ward, for various input on this document. David Ward, for various input on this document.
10. References 10. Normative References
10.1. Normative References
[ISO9577] International Organization for Standardization, "Protocol [ISO9577] International Organization for Standardization, "Protocol
identification in the network layer(ISO/IEC 9577)", ISO/ identification in the network layer(ISO/IEC 9577)", ISO/
IEC 9577:1999, Fourth Edition, Dec 1999. IEC 9577:1999, Fourth Edition, Dec 1999.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990. dual environments", RFC 1195, December 1990.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 8, line 5 skipping to change at page 8, line 6
Topology (MT) Routing in Intermediate System to Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120, February 2008. Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
[RFC5303] Katz, D., Saluja, R., and D. Eastlake, "Three-Way [RFC5303] Katz, D., Saluja, R., and D. Eastlake, "Three-Way
Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303, Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303,
October 2008. October 2008.
[RFC5306] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", [RFC5306] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS",
RFC 5306, October 2008. RFC 5306, October 2008.
10.2. Informative References [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010.
[I-D.ietf-bfd-base]
Katz, D. and D. Ward, "Bidirectional Forwarding
Detection", draft-ietf-bfd-base-09 (work in progress),
February 2009.
[I-D.ietf-bfd-generic] [RFC5882] Katz, D. and D. Ward, "Generic Application of
Katz, D. and D. Ward, "Generic Application of BFD", Bidirectional Forwarding Detection (BFD)", RFC 5882,
draft-ietf-bfd-generic-05 (work in progress), June 2010.
February 2009.
Authors' Addresses Authors' Addresses
Christian E. Hopps Christian E. Hopps
Cisco Systems Cisco Systems
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, California 95134 San Jose, California 95134
USA USA
Email: chopps@cisco.com Email: chopps@cisco.com
 End of changes. 41 change blocks. 
129 lines changed or deleted 122 lines changed or added

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