[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-chopps-isis-bfd-tlv) 00 01 02 03 RFC 6213

IS-IS for IP Internets                                          C. Hopps
Internet-Draft                                               L. Ginsberg
Intended status: Standards Track                           Cisco Systems
Expires: July 8, 2010                                    January 4, 2010


                         IS-IS BFD Enabled TLV
                       draft-ietf-isis-bfd-tlv-02

Abstract

   This document describes a TLV for use in the IS-IS routing protocol
   that allows for the proper use of the Bidirectional Forwarding
   Detection protocol (BFD).  There exist certain scenarios in which
   IS-IS will not react appropriately to a BFD detected forwarding plane
   failure without use of either this TLV or some other method.

Requirements Language

   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 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

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




Hopps & Ginsberg          Expires July 8, 2010                  [Page 1]

Internet-Draft            IS-IS BFD Enabled TLV             January 2010


   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  The Problem . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  The Solution  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     3.1.  State Definitions . . . . . . . . . . . . . . . . . . . . . 4
     3.2.  Adjacency Establishment and Maintenance . . . . . . . . . . 4
     3.3.  Advertisement of Topology Specific IS Neighbors . . . . . . 5
   4.  Transition  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Graceful Restart  . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  The BFD Enabled TLV . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     10.1. Normative References  . . . . . . . . . . . . . . . . . . . 7
     10.2. Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8



















Hopps & Ginsberg          Expires July 8, 2010                  [Page 2]

Internet-Draft            IS-IS BFD Enabled TLV             January 2010


1.  Introduction

   The Bidirectional Forwarding Detection protocol [I-D.ietf-bfd-base]
   is a protocol that allows for detection of a forwarding plane failure
   between two routers.  A router can use [I-D.ietf-bfd-base] to
   validate that a peer router's forwarding ability is functioning.

   One specific application of BFD as described in
   [I-D.ietf-bfd-generic] is to verify the forwarding ability of an
   IS-IS [RFC1195] router's adjacencies; however, the method described
   in [I-D.ietf-bfd-generic] does not allow for certain failure
   scenarios.  We will define a TLV that will allow for proper response
   to the 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) [I-D.ietf-bfd-generic] does not require a BFD
   session be established prior to the establishment of an IS-IS
   adjacency.  Thus, if a router A has neighbors 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 IS-IS IIHs shares fate with forwarded
   data 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.

   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, will form an adjacency with C,
   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, a router which
   supports this extension MUST include the BFD enabled TLV in its IIH.
   The contents of the TLV MUST indicate what topologies/protocols
   [RFC5120] have been enabled for BFD by including the appropriate



Hopps & Ginsberg          Expires July 8, 2010                  [Page 3]

Internet-Draft            IS-IS BFD Enabled TLV             January 2010


   MTID/NLPID pairs.

   When sending an IIH on an interface on which BFD is NOT enabled a
   router MUST NOT include the BFD enabled TLV.

3.1.  State Definitions

   The following definitions apply to each IS-IS neighbor:

   For each locally supported MTID/NLPID pair, an
   ISIS_TOPO_NLPID_BFD_REQUIRED variable is assigned.  If BFD is
   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
   FALSE.

   For each locally supported MTID, an ISIS_TOPO_BFD_REQUIRED variable
   is set to the logical OR of all ISIS_TOPO_NLPID_BFD_REQUIRED
   variables associated with that MTID.

   An ISIS_BFD_REQUIRED variable is set to the logical AND of all
   ISIS_TOPO_BFD_REQUIRED variables.

   For each locally supported MTID/NLPID pair, an ISIS_TOPO_NLPID_STATE
   variable is assigned.  If ISIS_TOPO_NLPID_BFD_REQUIRED is TRUE, this
   variable follows the 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
   variable is set to the logical AND of the set of
   ISIS_TOPO_NLPID_STATE variables associated with that MTID.

   An ISIS_NEIGHBOR_USEABLE variable is set to the logical OR of all
   ISIS_TOPO_USEABLE variables.

3.2.  Adjacency Establishment and Maintenance

   Whenever ISIS_BFD_REQUIRED is TRUE the following extensions to the
   rules for adjacency establishment and maintenance MUST apply:

   o  ISIS_NEIGHBOR_USEABLE MUST be TRUE before the adjacency can
      transition from INIT to UP state

   o  When the IS-IS adjacency is UP and ISIS_NEIGHBOR_USEABLE becomes
      FALSE the IS-IS adjacency MUST transition to DOWN.

   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
      Point-to-Point Three Way Adjacency TLV[RFC5303] in all transmitted



Hopps & Ginsberg          Expires July 8, 2010                  [Page 4]

Internet-Draft            IS-IS BFD Enabled TLV             January 2010


      IIHs.

   o  On a LAN circuit whenever ISIS_NEIGHBOR_USEABLE is FALSE, the IS
      Neighbors TLV advertising the MAC address of the neighbor MUST be
      omitted in all transmitted IIHs.

3.3.  Advertisement of Topology Specific IS Neighbors

   The advertisement of a topology specific IS-neighbor (as well as the
   use of the neighbor in the topology specific decision process) is
   determined by the value of ISIS_TOPO_USEABLE for each topology.  If
   ISIS_TOPO_USEABLE is TRUE then the topology specific neighbor is
   advertised.  If ISIS_TOPO_USEABLE is FALSE then the topology specific
   neighbor is NOT advertised.


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 value of ISIS_BFD_REQUIRED
   becomes TRUE as a result of the introduction of the BFD TLV or the
   modification (by adding a new supported MTID/NLPID) of an existing
   BFD TLV in a neighbor's IIH.  A simple way to do this is to not
   update the adjacency hold-time when receiving such an IIH from a
   neighbor with whom we have an UP adjacency until
   ISIS_NEIGHBOR_USEABLE becomes TRUE.

   If the value of ISIS_BFD_REQUIRED becomes FALSE as a result of 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
   session establishment is no longer required to maintain the adjacency
   or transition the adjacency to the UP state.

   If a BFD session is administratively shut down [I-D.ietf-bfd-base]
   and the BFD session state change impacts the value of
   ISIS_NEIGHBOR_USEABLE, then IS-IS SHOULD allow time for the
   corresponding MTID/NLPID to be removed from the neighbor's BFD TLV by
   not updating the adjacency hold time until ISIS_BFD_REQUIRED becomes
   FALSE.  Note that while this allows a non-disruptive transition, it
   still enforces consistency between the administrative state of the
   BFD session and the MTID/NLPID(s) advertised in the BFD TLV.  This is
   necessary to provide consistent behavior regardless of whether the
   BFD AdminDown state is introduced before or after an IS-IS adjacency
   UP state has been achieved.






Hopps & Ginsberg          Expires July 8, 2010                  [Page 5]

Internet-Draft            IS-IS BFD Enabled TLV             January 2010


5.  Graceful Restart

   It is worth considering what if anything should be done when IS-IS is
   gracefully restarting [RFC5306].

   In cases where BFD shares fate with the control plane, it can be
   expected that BFD session failure may occur in conjunction with the
   control plane restart.  In such cases premature abort of IS-IS
   graceful restart as a result of BFD session failure is undesirable.
   Therefore, some mechanism to ignore the BFD session failure for a
   limited period of time would be beneficial.  How this is implemented
   is beyond the scope of this document.  Consult [I-D.ietf-bfd-generic]
   for further details.


6.  The BFD Enabled TLV

   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
   or more supported MTID/protocols on the interface over which the IIH
   is being sent.  The NLPIDs encoded in the TLV are defined in
   [ISO9577]

     Type   139 (suggested - to be assigned by IANA)
     Length # of octets in the value field (3 to 255)
     Value  three octets specifying the MTID/NLPID for each
            topology/data protocol for which BFD support is enabled

                                          No. of octets
                +-----------------------+
                |R|R|R|R|   MTID        |     2
                +-----------------------+
                |      NLPID            |     1
                +-----------------------+
                :                       :
                :                       :
                +-----------------------+
                |R|R|R|R|   MTID        |     2
                +-----------------------+
                | NLPID                 |     1
                +-----------------------+


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.



Hopps & Ginsberg          Expires July 8, 2010                  [Page 6]

Internet-Draft            IS-IS BFD Enabled TLV             January 2010


8.  IANA Considerations

   The following IS-IS TLV type is defined by this draft.

   Name                                  Value  IIH   LSP  SNP
   ----------------------                -----  ---   ---  ---
   BFD Enabled TLV                         139   y     n    n

   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

   The authors wish to thank Jeffrey Haas, Matthew Jones, Dave Katz,
   Jonathan Moon, Stefano Previdi, Mike Shand, Michael Shiplett and
   David Ward, for various input on this document.


10.  References

10.1.  Normative References

   [ISO9577]  International Organization for Standardization, "Protocol
              identification in the network layer(ISO/IEC 9577)", ISO/
              IEC 9577:1999, Fourth Edition, Dec 1999.

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5120]  Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
              Topology (MT) Routing in Intermediate System to
              Intermediate Systems (IS-ISs)", RFC 5120, February 2008.

   [RFC5303]  Katz, D., Saluja, R., and D. Eastlake, "Three-Way
              Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303,
              October 2008.

   [RFC5306]  Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS",
              RFC 5306, October 2008.






Hopps & Ginsberg          Expires July 8, 2010                  [Page 7]

Internet-Draft            IS-IS BFD Enabled TLV             January 2010


10.2.  Informative References

   [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]
              Katz, D. and D. Ward, "Generic Application of BFD",
              draft-ietf-bfd-generic-05 (work in progress),
              February 2009.


Authors' Addresses

   Christian E. Hopps
   Cisco Systems
   170 W. Tasman Dr.
   San Jose, California  95134
   USA

   Email: chopps@cisco.com


   Les Ginsberg
   Cisco Systems
   510 McCarthy Blvd.
   Milpitas, Ca.  95035
   USA

   Email: ginsberg@cisco.com




















Hopps & Ginsberg          Expires July 8, 2010                  [Page 8]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/