doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc6213.txt b/doc/rfc/rfc6213.txt
new file mode 100644
index 0000000..bdf9fe0
--- /dev/null
+++ b/doc/rfc/rfc6213.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          C. Hopps
+Request for Comments: 6213                                   L. Ginsberg
+Category: Standards Track                                  Cisco Systems
+ISSN: 2070-1721                                               April 2011
+
+
+                         IS-IS BFD-Enabled TLV
+
+Abstract
+
+   This document describes a type-length-value (TLV) for use in the IS-
+   IS routing protocol that allows for the proper use of the
+   Bidirectional Forwarding Detection (BFD) protocol.  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.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6213.
+
+Copyright Notice
+
+   Copyright (c) 2011 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 Simplified BSD License.
+
+
+
+
+
+
+Hopps & Ginsberg             Standards Track                    [Page 1]
+
+RFC 6213                  IS-IS BFD-Enabled TLV               April 2011
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Requirements Language ......................................2
+   2. The Problem .....................................................2
+   3. The Solution ....................................................3
+      3.1. State Definitions ..........................................3
+      3.2. Adjacency Establishment and Maintenance ....................4
+      3.3. Advertisement of Topology-Specific IS Neighbors ............4
+   4. Transition ......................................................4
+   5. Graceful Restart ................................................5
+   6. The BFD-Enabled TLV .............................................5
+   7. Security Considerations .........................................6
+   8. IANA Considerations .............................................6
+   9. Acknowledgements ................................................6
+   10. Normative References ...........................................7
+
+1.  Introduction
+
+   The Bidirectional Forwarding Detection (BFD) protocol [RFC5880] is a
+   protocol that allows for detection of a forwarding plane failure
+   between two routers.  A router can use [RFC5880] to validate that a
+   peer router's forwarding ability is functioning.
+
+   One specific application of BFD as described in [RFC5882] is to
+   verify the forwarding ability of an IS-IS [RFC1195] router's
+   adjacencies; however, the method described in [RFC5882] 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.
+
+1.1.  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].
+
+2.  The Problem
+
+   We observe that, in order to allow for mixed use (i.e., some routers
+   running BFD and some not), [RFC5882] 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 it would only
+   establish a BFD session with C.
+
+
+
+
+
+
+Hopps & Ginsberg             Standards Track                    [Page 2]
+
+RFC 6213                  IS-IS BFD-Enabled TLV               April 2011
+
+
+   The problem with this solution is that it assumes that the
+   transmission and receipt of IS-IS Hellos (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 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 as described in this document.
+
+   When sending an IIH on a BFD enabled interface, a router that
+   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
+   Multi-Topology Identifier (MTID)/ Network Layer Protocol Identifier
+   (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 of 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.
+
+
+
+
+
+
+Hopps & Ginsberg             Standards Track                    [Page 3]
+
+RFC 6213                  IS-IS BFD-Enabled TLV               April 2011
+
+
+   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 IIHs.
+
+   o  On a LAN circuit whenever "ISIS_NEIGHBOR_USEABLE" is "FALSE", the
+      IS Neighbors TLV advertising the Media Access Control (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
+
+
+
+Hopps & Ginsberg             Standards Track                    [Page 4]
+
+RFC 6213                  IS-IS BFD-Enabled TLV               April 2011
+
+
+   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 [RFC5880] 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.
+
+5.  Graceful Restart
+
+   This section describes IS-IS implementation considerations when both
+   IS-IS graceful restart [RFC5306] and BFD are co-deployed.
+
+   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.  The issue of the
+   interaction between graceful restart and BFD is described at length
+   in RFC 5882.  The implementation of this interaction is outside the
+   scope of this document.
+
+6.  The BFD-Enabled TLV
+
+   The BFD-enabled TLV is formatted as shown below.  The TLV SHALL only
+   be included in an IIH 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].
+
+
+
+
+
+
+Hopps & Ginsberg             Standards Track                    [Page 5]
+
+RFC 6213                  IS-IS BFD-Enabled TLV               April 2011
+
+
+     Type   148
+     Length # of octets in the value field (3 to 255)
+     Value  3 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.  Inappropriate use of this TLV could prevent an
+   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
+
+   The following IS-IS TLV type is defined by this document.
+
+   Name                                  Value  IIH  LSP  SNP  Purge
+   ----------------------                -----  ---  ---  ---  -----
+   BFD-Enabled TLV                         148   y    n    n     n
+
+   The IS-IS TLV Codepoint registry has been updated accordingly.
+
+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.
+
+
+
+
+Hopps & Ginsberg             Standards Track                    [Page 6]
+
+RFC 6213                  IS-IS BFD-Enabled TLV               April 2011
+
+
+10.  Normative References
+
+   [ISO9577]  International Organization for Standardization, "Protocol
+              identification in the network layer(ISO/IEC 9577)", ISO/
+              IEC 9577:1999, Fourth Edition, December 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.
+
+   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
+              (BFD)", RFC 5880, June 2010.
+
+   [RFC5882]  Katz, D. and D. Ward, "Generic Application of
+              Bidirectional Forwarding Detection (BFD)", RFC 5882,
+              June 2010.
+
+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, California  95035
+   USA
+   EMail: ginsberg@cisco.com
+
+
+
+
+
+Hopps & Ginsberg             Standards Track                    [Page 7]
+