[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
Internet Engineering Task Force                       Christian E. Hopps
INTERNET-DRAFT                                             Cisco Systems
Expires September 2005                                     20 March 2005

                         IS-IS BFD Enabled TLV

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

Copyright Notice

   Copyright (C) The Internet Society (2005). All Rights Reserved.

Expires September 2005                                          [Page 1]

Draft                     IS-IS BFD Enabled TLV               March 2005


   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",
   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

   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

   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

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

     Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual
     environments", RFC 1195, December 1990.

11.  Informative References

     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

     Katz, D., and Ward, D., "Bidirectional Forwarding Detection",
     draft-ietf-bfd-base-01.txt, February, 2005.

     Katz, D., and Ward, D., "BFD for IPv4 and IPv6 (Single Hop)",
     draft-ietf-bfd-v4v6-1hop-01.txt, February, 2005.

     Katz, D., and Saluja, R., "Three-Way Handshake for Intermediate
     System to Intermediate System (IS-IS) Point-to-Point Adjacencies",
     RFC 3373, September 2002.

     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
     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

Expires September 2005                                          [Page 6]