Internet Engineering Task Force Christian E. Hopps
INTERNET-DRAFT Cisco Systems
Expires September 2005 20 March 2005
IS-IS BFD Enabled TLV
<draft-chopps-isis-bfd-tlv-00.txt>
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Expires September 2005 [Page 1]
Draft IS-IS BFD Enabled TLV March 2005
Abstract
This document describes a TLV for use in the IS-IS routing protocol
that allows for the proper functioning of the Bidirectional
Forwarding Detection protocol (BFD). There exists certain scenarios
in which BFD will fail to detect a forwarding plane failure without
use of either this TLV or some other method.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [KEYWORDS].
1. Introduction
The Bidirectional Forwarding Detection protocol [BFD] is a protocol
that allows for detection of a forwarding plane failure between two
routers. A router can use [BFD] to validate that a peer router's
forwarding ability is functioning.
One specific application of BFD as described in [IP-BFD] is to verify
the forwarding ability of an IS-IS [ISIS] router's adjacencies;
however, the method described in [IP-BFD] does not allow for certain
failure scenarios. We will define a TLV that will allow for proper
detection of all forwarding failures where the use of BFD is employed
with IS-IS.
2. The Problem
We observe that to allow for mixed use (i.e., some routers running
BFD and some not) [IP-BFD] does not require a BFD session be
established prior to the establishment of an IS-IS adjacency. Thus,
if a router A has a neighbor B and C, and B does not support BFD, A
would still form adjacencies with B and C, and would only establish a
BFD session with C.
The problem with this solution is that it assumes that the
transmission and receipt of an IS-IS IIH shares fate with forwarded
packets. This is not a fair assumption to make given that the primary
use of BFD is to protect IPv4 (and IPv6) forwarding and IS-IS does
not utilize IPv4 or IPv6 for sending or receiving its hellos.
Expires September 2005 [Page 2]
Draft IS-IS BFD Enabled TLV March 2005
Thus, if we consider our previous example, and if C is currently
experiencing an IPv4 forwarding failure that allows for IS-IS IIHs to
be sent and received, when A first starts (or restarts) A will assume
that C simply does not support BFD and may incorrectly forward IPv4
traffic through C.
3. The Solution
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
the inclusion of a TLV in its IIHs, and indeed that is our proposal.
When sending an IIH on a BFD enabled interface, the router SHALL
include the BFD enabled TLV in its IIH, otherwise BFD is disabled on
the interface and the router SHALL NOT include the BFD enable TLV.
When receiving an IIH from a neighbor on an interface with BFD
enabled, if the IIH does not have a BFD enabled TLV then no BFD
session will be attempted with the given neighbor.
When receiving an IIH from a neighbor on an interface with BFD
enabled, and if the IIH contains the BFD enabled TLV, then the
establishment of a BFD session with that neighbor will be required
before allowing the adjacency to the neighbor to reach the UP state.
An adjacency can be held in the INIT state by not including the
neighbor in the IIHs sent out an interface. This method requires use
of the 3-way handshake [ISIS-3WAY] on point-to-point interfaces.
If BFD is not enabled on an interface then the BFD enabled TLV is
ignored on receipt.
4. Transition
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
on a BFD enabled interface when the BFD TLV is first added to a
neighbor's IIH. A simple way to do this is to not update the
adjacency hold-time when receiving an IIH from an UP adjacency with
the BFD enable TLV until a session is established with the neighbor.
If a neighbor removes the BFD enabled TLV from its IIH then BFD
session establishment is no longer required. It is implementation
defined whether any current session is torn down, and because of
Expires September 2005 [Page 3]
Draft IS-IS BFD Enabled TLV March 2005
this, a router wishing to transition away from the use of BFD should
first gracefully disable BFD [BFD] before removing the TLV from its
IIH.
If a BFD session is gracefully shut down [BFD] IS-IS will simply
revert to the behavior already defined above. Specifically receiving
an IIH with the BFD enabled TLV would be treated as if the neighbor
were transitioning to the use of BFD, otherwise no BFD enabled TLV is
present and no action is required.
5. Graceful Restart
It is worth considering what if anything should be done when IS-IS is
gracefully restarting [ISIS-GR]. We assume that the BFD session is
being maintained, although how this is done is outside the scope of
this document.
When there is no change in the local and remote BFD enabled state,
nothing interesting will occur. If we had a BFD session with a
neighbor previously we will continue to have one, and both routers
will continue to advertise the BFD enabled state within their IIHs.
If we did not have a session we will we continue to not have a
session.
If the neighbor changes its BFD enabled state from enabled to
disabled the TLV will no longer be present. This is the same as the
non-restarting case described above, namely BFD session establishment
is no longer required, and it is implementation defined whether any
current session is torn down.
If the neighbor changes its BFD state from disabled to enabled the
TLV will be newly present in the IIH. This is the same as the non-
restarting case of transitioning to BFD use as defined above, namely
we recover the adjacency but allow time for the BFD session to be re-
established, and as stated above this can be accomplished by not
further updating the hold-time for an adjacency until the BFD session
is established.
6. The BFD Enabled TLV
The BFD enabled TLV has the type (TBD) and length of 0. The TLV SHALL
only be included in an IS-IS IIH PDU. The TLV is boolean, and thus if
present then the sending router is indicating the BFD is enabled on
Expires September 2005 [Page 4]
Draft IS-IS BFD Enabled TLV March 2005
the sending interface, otherwise BFD is not enabled on the sending
interface.
7. Security Considerations
The TLV defined within this document describes an addition to the IS-
IS Hello protocol and does not impact the security mechanism of the
IS-IS protocol.
8. IANA Considerations
The following IS-IS TLV type is defined by this draft.
Name Value IIH LSP SNP
---------------------- ----- --- --- ---
BFD Enabled TLV TBD y n n
Please update the IS-IS TLV Codepoint Registry accordingly.
9. Acknowledgments
The author wishes to thank Les Ginsberg, Matthew Jones, Dave Katz,
Jonathan Moon, Stefano Previdi, Michael Shiplett and David Ward, for
various input on this document.
10. Normative References
[ISIS]
Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual
environments", RFC 1195, December 1990.
11. Informative References
[KEYWORD]
Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
Expires September 2005 [Page 5]
Draft IS-IS BFD Enabled TLV March 2005
[BFD]
Katz, D., and Ward, D., "Bidirectional Forwarding Detection",
draft-ietf-bfd-base-01.txt, February, 2005.
[IP-BFD]
Katz, D., and Ward, D., "BFD for IPv4 and IPv6 (Single Hop)",
draft-ietf-bfd-v4v6-1hop-01.txt, February, 2005.
[ISIS-3WAY]
Katz, D., and Saluja, R., "Three-Way Handshake for Intermediate
System to Intermediate System (IS-IS) Point-to-Point Adjacencies",
RFC 3373, September 2002.
[ISIS-GR]
Shand, M., and Ginsberg, L., "Restart Signaling for Intermediate
System to Intermediate System (IS-IS)", RFC 3847, July 2004
12. Author's Address
Christian E. Hopps
Cisco Systems
3750 Cisco Way
San Jose, CA 95134
U.S.A.
Phone: +1 408 525 1684
Email: chopps@cisco.com
13. Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Expires September 2005 [Page 6]