doc: Add RFC documents

1 files changed, 1347 insertions, 0 deletions

diff --git a/doc/rfc/rfc7880.txt b/doc/rfc/rfc7880.txt
new file mode 100644
index 0000000..370c1bd
--- /dev/null
+++ b/doc/rfc/rfc7880.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      C. Pignataro
+Request for Comments: 7880                                       D. Ward
+Updates: 5880                                                      Cisco
+Category: Standards Track                                       N. Akiya
+ISSN: 2070-1721                                      Big Switch Networks
+                                                               M. Bhatia
+                                                          Ionos Networks
+                                                           S. Pallagatti
+                                                               July 2016
+
+
+          Seamless Bidirectional Forwarding Detection (S-BFD)
+
+Abstract
+
+   This document defines Seamless Bidirectional Forwarding Detection
+   (S-BFD), a simplified mechanism for using BFD with a large proportion
+   of negotiation aspects eliminated, thus providing benefits such as
+   quick provisioning, as well as improved control and flexibility for
+   network nodes initiating path monitoring.
+
+   This document updates RFC 5880.
+
+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 7841.
+
+   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/rfc7880.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pignataro, et al.            Standards Track                    [Page 1]
+
+RFC 7880                    Seamless BFD Base                  July 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pignataro, et al.            Standards Track                    [Page 2]
+
+RFC 7880                    Seamless BFD Base                  July 2016
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+   2. Terminology .....................................................4
+   3. Seamless BFD Overview ...........................................6
+   4. S-BFD Discriminators ............................................7
+      4.1. S-BFD Discriminator Uniqueness .............................7
+      4.2. Discriminator Pools ........................................7
+   5. Reflector BFD Session ...........................................8
+   6. State Variables .................................................9
+      6.1. New State Variables ........................................9
+      6.2. State Variable Initialization and Maintenance ..............9
+   7. S-BFD Procedures ...............................................10
+      7.1. Demultiplexing of S-BFD Control Packet ....................10
+      7.2. Responder Procedures ......................................11
+           7.2.1. Responder Demultiplexing ...........................11
+           7.2.2. Transmission of S-BFD Control Packet by
+                  SBFDReflector ......................................11
+           7.2.3. Additional SBFDReflector Behaviors .................12
+      7.3. Initiator Procedures ......................................13
+           7.3.1. SBFDInitiator State Machine ........................14
+           7.3.2. Transmission of S-BFD Control Packet by
+                  SBFDInitiator ......................................15
+           7.3.3. Additional SBFDInitiator Behaviors .................15
+      7.4. Diagnostic Values .........................................16
+      7.5. The Poll Sequence .........................................16
+   8. Operational Considerations .....................................16
+      8.1. Scaling Aspect ............................................17
+      8.2. Congestion Considerations .................................17
+   9. Co-existence with Classical BFD Sessions .......................17
+   10. S-BFD Echo Function ...........................................18
+   11. Security Considerations .......................................19
+   12. References ....................................................20
+      12.1. Normative References .....................................20
+      12.2. Informative References ...................................20
+   Appendix A. Loop Problem and Solution .............................22
+   Acknowledgements ..................................................23
+   Contributors ......................................................23
+   Authors' Addresses ................................................24
+
+
+
+
+
+
+
+
+
+
+
+
+Pignataro, et al.            Standards Track                    [Page 3]
+
+RFC 7880                    Seamless BFD Base                  July 2016
+
+
+1.  Introduction
+
+   Bidirectional Forwarding Detection (BFD), as described in [RFC5880]
+   and related documents, has efficiently generalized the failure
+   detection mechanism for multiple protocols and applications.  There
+   are some improvements that can be made to better fit existing
+   technologies.  There is a possibility of evolving BFD to better fit
+   new technologies.  This document focuses on several aspects of BFD in
+   order to further improve efficiency, expand failure detection
+   coverage, and allow BFD usage for wider scenarios.  Additional use
+   cases are listed in [RFC7882].
+
+   Specifically, this document defines Seamless Bidirectional Forwarding
+   Detection (S-BFD), a simplified mechanism for using BFD with a large
+   proportion of negotiation aspects eliminated, thus providing benefits
+   such as quick provisioning, as well as improved control and
+   flexibility for network nodes initiating path monitoring.  S-BFD
+   enables cases benefiting from the use of core BFD technologies in a
+   fashion that leverages existing implementations and protocol
+   machinery while providing a rather simplified and largely stateless
+   infrastructure for continuity testing.
+
+   One key aspect of the mechanism described in this document eliminates
+   the time between a network node wanting to perform a continuity test
+   and completing the continuity test.  In traditional BFD terms, the
+   initial state changes from DOWN to UP are virtually nonexistent.
+   Removal of this "seam" (i.e., time delay) in BFD provides a smooth
+   and continuous operational experience for applications.  Therefore,
+   "Seamless BFD" (S-BFD) has been chosen as the name for this
+   mechanism.
+
+2.  Terminology
+
+   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].
+
+   The reader is expected to be familiar with the BFD [RFC5880], IP
+   [RFC791] [RFC2460], and MPLS [RFC3031] terms and protocol constructs.
+   The remainder of this section describes several new terms introduced
+   by S-BFD.
+
+   o  Classical BFD - BFD session types based on [RFC5880].
+
+   o  S-BFD - Seamless BFD.
+
+   o  S-BFD Control packet - a BFD Control packet for the S-BFD
+      mechanism.
+
+
+
+Pignataro, et al.            Standards Track                    [Page 4]
+
+RFC 7880                    Seamless BFD Base                  July 2016
+
+
+   o  S-BFD Echo packet - a BFD Echo packet for the S-BFD mechanism.
+
+   o  S-BFD packet - a BFD Control packet or a BFD Echo packet.
+
+   o  Entity - a function on a network node to which the S-BFD mechanism
+      allows remote network nodes to perform continuity tests.  An
+      entity can be abstract (e.g., reachability) or specific (e.g., IP
+      addresses, Router-IDs, functions).
+
+   o  SBFDInitiator - an S-BFD session on a network node that performs a
+      continuity test to a remote entity by sending S-BFD packets.
+
+   o  SBFDReflector - an S-BFD session on a network node that listens
+      for incoming S-BFD Control packets to local entities and generates
+      response S-BFD Control packets.
+
+   o  Reflector BFD session - synonymous with SBFDReflector.
+
+   o  S-BFD Discriminator - a BFD Discriminator allocated for a local
+      entity.  An SBFDReflector listens for S-BFD Discriminators.
+
+   o  BFD Discriminator - a BFD Discriminator allocated for an
+      SBFDInitiator.
+
+   o  Initiator - a network node hosting an SBFDInitiator.
+
+   o  Responder - a network node hosting an SBFDReflector.
+
+   Figure 1 describes the relationship between S-BFD terms.
+
+    +---------------------+                +------------------------+
+    |      Initiator      |                |         Responder      |
+    | +-----------------+ |                |    +-----------------+ |
+    | |  SBFDInitiator  |---S-BFD Ctrl pkt----->|  SBFDReflector  | |
+    | | +-------------+ |<--S-BFD Ctrl pkt------| +-------------+ | |
+    | | | BFD Discrim | | |                |    | |S-BFD Discrim| | |
+    | | |             | |---S-BFD Echo pkt---+  | |             | | |
+    | | +-------------+ | |                | |  | +----------^--+ | |
+    | +-----------------+<-------------------+  +------------|----+ |
+    |                     |                |                 |      |
+    |                     |                |             +---v----+ |
+    |                     |                |             | Entity | |
+    |                     |                |             +--------+ |
+    +---------------------+                +------------------------+
+
+                 Figure 1: S-BFD Terminology Relationship
+
+
+
+
+
+Pignataro, et al.            Standards Track                    [Page 5]
+
+RFC 7880                    Seamless BFD Base                  July 2016
+
+
+3.  Seamless BFD Overview
+
+   An S-BFD module on each network node allocates one or more S-BFD
+   Discriminators for local entities and creates a Reflector BFD
+   session.  Allocated S-BFD Discriminators may be advertised by
+   applications (e.g., OSPF/IS-IS).  The required result is that
+   applications on other network nodes will know about the S-BFD
+   Discriminators allocated by a remote node to remote entities.  The
+   Reflector BFD session, upon receiving an S-BFD Control packet
+   targeted to one of the local S-BFD Discriminator values, is to
+   transmit a response S-BFD Control packet back to the initiator.
+
+   Once the above setup is complete, any network node that knows about
+   the S-BFD Discriminator allocated by a remote node to a remote entity
+   or entities can quickly perform a continuity test to the remote
+   entity by simply sending S-BFD Control packets with a corresponding
+   S-BFD Discriminator value in the Your Discriminator field.
+
+   This is exemplified in Figure 2.
+
+                     <------- IS-IS Network ------->
+
+                               +---------+
+                               |         |
+                     A---------B---------C---------D
+                     ^                             ^
+                     |                             |
+                 System-ID                      System-ID
+                    xxx                            yyy
+                BFD Discrim                    BFD Discrim
+                    123                            456
+
+                     Figure 2: S-BFD for IS-IS Network
+
+   An S-BFD module in a system with IS-IS System-ID xxx (Node A)
+   allocates an S-BFD Discriminator 123, and IS-IS advertises the S-BFD
+   Discriminator 123 in an IS-IS TLV.  An S-BFD module in a system with
+   IS-IS System-ID yyy (Node D) allocates an S-BFD Discriminator 456,
+   and IS-IS advertises the S-BFD Discriminator 456 in an IS-IS TLV.  A
+   Reflector BFD session is created on both network nodes (Node A and
+   Node D).  When Node A wants to check the reachability of Node D,
+   Node A can send an S-BFD Control packet destined to Node D with the
+   Your Discriminator field set to 456.  When the Reflector BFD session
+   on Node D receives this S-BFD Control packet, then a response S-BFD
+   Control packet is sent back to Node A, which allows Node A to
+   complete the continuity test.
+
+
+
+
+
+Pignataro, et al.            Standards Track                    [Page 6]
+
+RFC 7880                    Seamless BFD Base                  July 2016
+
+
+   When a node allocates multiple S-BFD Discriminators, how remote nodes
+   determine which of the discriminators is associated with a specific
+   entity is currently unspecified.  The use of multiple S-BFD
+   Discriminators by a single network node is therefore discouraged
+   until a means of learning the mapping is defined.
+
+4.  S-BFD Discriminators
+
+4.1.  S-BFD Discriminator Uniqueness
+
+   One important characteristic of an S-BFD Discriminator is that it
+   MUST be unique within an administrative domain.  If multiple network
+   nodes allocate the same S-BFD Discriminator value, then S-BFD Control
+   packets falsely terminating on a wrong network node can result in a
+   Reflector BFD session generating a response back because of a
+   matching Your Discriminator value.  This is clearly not desirable.
+
+4.2.  Discriminator Pools
+
+   This subsection describes a discriminator pool implementation
+   technique to minimize S-BFD Discriminator collisions.  This technique
+   will allow an implementation to better satisfy the S-BFD
+   Discriminator uniqueness requirement defined in Section 4.1.
+
+   o  An SBFDInitiator is to allocate a discriminator from the BFD
+      Discriminator pool.  If the system also supports classical BFD
+      (i.e., implements [RFC5880]), then the BFD Discriminator pool
+      SHOULD be shared by SBFDInitiator sessions and classical BFD
+      sessions.
+
+   o  An SBFDReflector is to allocate a discriminator from the S-BFD
+      Discriminator pool.  The S-BFD Discriminator pool SHOULD be a
+      separate pool from the BFD Discriminator pool.
+
+   The remainder of this subsection describes the reasons for the
+   suggestions above.
+
+   Locally allocated S-BFD Discriminator values for entities that
+   SBFDReflector sessions are listening for may be arbitrarily allocated
+   or derived from values provided by applications.  These values may be
+   protocol IDs (e.g., System-ID, Router-ID) or network targets (e.g.,
+   IP address).  To avoid derived S-BFD Discriminator values already
+   being assigned to other BFD sessions (i.e., SBFDInitiator sessions
+   and classical BFD sessions), it is RECOMMENDED that the discriminator
+   pool for SBFDReflector sessions be separate from other BFD sessions.
+
+
+
+
+
+
+Pignataro, et al.            Standards Track                    [Page 7]
+
+RFC 7880                    Seamless BFD Base                  July 2016
+
+
+   Even when following the "separate discriminator pool" approach, a
+   collision is still possible between different S-BFD applications that
+   may be using different values and algorithms to derive S-BFD
+   Discriminator values.  If two applications are using S-BFD for the
+   same purpose (e.g., network reachability), then the colliding S-BFD
+   Discriminator value can be shared.  If the two applications are using
+   S-BFD for a different purpose, then the collision must be addressed.
+   The use of multiple S-BFD Discriminators by a single network node,
+   however, is discouraged (see Section 3).
+
+5.  Reflector BFD Session
+
+   Each network node creates one or more Reflector BFD sessions.  This
+   Reflector BFD session is a session that transmits S-BFD Control
+   packets in response to received S-BFD Control packets with the
+   Your Discriminator field having S-BFD Discriminators allocated for
+   local entities.  Specifically, this Reflector BFD session has the
+   following characteristics:
+
+   o  MUST NOT transmit any S-BFD packets based on local timer expiry.
+
+   o  MUST transmit an S-BFD Control packet in response to a received
+      S-BFD Control packet having a valid S-BFD Discriminator in the
+      Your Discriminator field, unless prohibited by local policies
+      (e.g., administrative, security, rate-limiter).
+
+   o  MUST be capable of sending only two states: UP and AdminDown.
+
+   One Reflector BFD session may be responsible for handling received
+   S-BFD Control packets targeted to all locally allocated S-BFD
+   Discriminators, or a few Reflector BFD sessions may each be
+   responsible for a subset of locally allocated S-BFD Discriminators.
+   This policy is a local matter and is outside the scope of this
+   document.
+
+   Note that incoming S-BFD Control packets may be based on IPv4, IPv6,
+   or MPLS [RFC7881].  Note also that other options are possible and may
+   be defined in future documents.  How such S-BFD Control packets reach
+   an appropriate Reflector BFD session is also a local matter and is
+   outside the scope of this document.
+
+
+
+
+
+
+
+
+
+
+
+Pignataro, et al.            Standards Track                    [Page 8]
+
+RFC 7880                    Seamless BFD Base                  July 2016
+
+
+6.  State Variables
+
+   S-BFD introduces new state variables and modifies the usage of
+   existing ones.
+
+6.1.  New State Variables
+
+   A new state variable is added to the base specification in support
+   of S-BFD.
+
+   o  bfd.SessionType: This is a new state variable that describes
+      the type of a particular session.  Allowable values for S-BFD
+      sessions are:
+
+      *  SBFDInitiator - an S-BFD session on a network node that
+         performs a continuity test to a target entity by sending S-BFD
+         packets.
+
+      *  SBFDReflector - an S-BFD session on a network node that listens
+         for incoming S-BFD Control packets to local entities and
+         generates response S-BFD Control packets.
+
+   The bfd.SessionType variable MUST be initialized to the appropriate
+   type when an S-BFD session is created.
+
+6.2.  State Variable Initialization and Maintenance
+
+   State variables (defined in Section 6.8.1 of [RFC5880]) need to
+   be initialized or manipulated differently, depending on the
+   session type.
+
+   o  bfd.DemandMode: This variable MUST be initialized to 1 for session
+      type SBFDInitiator and MUST be initialized to 0 for session type
+      SBFDReflector.  This is done to prevent loops (see Appendix A).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pignataro, et al.            Standards Track                    [Page 9]
+
+RFC 7880                    Seamless BFD Base                  July 2016
+
+
+7.  S-BFD Procedures
+
+7.1.  Demultiplexing of S-BFD Control Packet
+
+   An S-BFD packet MUST be demultiplexed with lower-layer information
+   (e.g., dedicated destination UDP port [RFC7881], associated Channel
+   Type [RFC7885]).  The following procedure SHOULD be executed on both
+   initiator and reflector:
+
+      If the packet is an S-BFD packet
+
+         If the S-BFD packet is for an SBFDReflector
+
+            The packet MUST be looked up to locate a corresponding
+            SBFDReflector session based on the value from the
+            Your Discriminator field in the table describing S-BFD
+            Discriminators.
+
+         Else
+
+            The packet MUST be looked up to locate a corresponding
+            SBFDInitiator session or classical BFD session based on the
+            value from the Your Discriminator field in the table
+            describing BFD Discriminators.  If no match, then the
+            received packet MUST be discarded.
+
+            If the session is an SBFDInitiator session
+
+               The destination of the packet (i.e., the destination IP
+               address) SHOULD be verified as being for itself.
+
+            Else
+
+               The packet MUST be discarded.
+
+      Else
+
+         The procedure described in Section 6.8.6 of [RFC5880] MUST be
+         applied.
+
+   More details on S-BFD Control packet demultiplexing are provided in
+   relevant S-BFD data-plane documents.
+
+
+
+
+
+
+
+
+
+Pignataro, et al.            Standards Track                   [Page 10]
+
+RFC 7880                    Seamless BFD Base                  July 2016
+
+
+7.2.  Responder Procedures
+
+   A network node that receives S-BFD Control packets transmitted by an
+   initiator is referred to as the responder.  The responder, upon
+   reception of S-BFD Control packets, is to verify the validity of the
+   packets, as described in [RFC5880].
+
+7.2.1.  Responder Demultiplexing
+
+   An S-BFD packet MUST be demultiplexed with lower-layer information.
+   The following procedure SHOULD be executed by the responder:
+
+      If the Your Discriminator field is not one of the entries
+      allocated for local entities
+
+         The packet MUST be discarded.
+
+      Else
+
+         The packet is determined to be handled by a Reflector BFD
+         session responsible for that S-BFD Discriminator.
+
+         If allowable per local policy (e.g., administrative, security,
+         rate-limiter)
+
+            The chosen Reflector BFD session SHOULD transmit a response
+            BFD Control packet using the procedures described in
+            Section 7.2.2.
+
+7.2.2.  Transmission of S-BFD Control Packet by SBFDReflector
+
+   The contents of S-BFD Control packets sent by an SBFDReflector MUST
+   be set as per Section 6.8.7 of [RFC5880].  There are a few fields
+   that need to be set differently from [RFC5880], as follows:
+
+      State (Sta)
+
+         Set to bfd.SessionState (either UP or AdminDown only).
+         Clarification of Reflector BFD session state is described in
+         Section 7.2.3.
+
+      Demand (D)
+
+         Set to 0, to indicate that the S-BFD packet is sent by the
+         SBFDReflector.
+
+
+
+
+
+
+Pignataro, et al.            Standards Track                   [Page 11]
+
+RFC 7880                    Seamless BFD Base                  July 2016
+
+
+      Detect Mult
+
+         Value to be copied from the Detection Multiplier field of the
+         received BFD packet.
+
+      My Discriminator
+
+         Value to be copied from the Your Discriminator field of the
+         received BFD packet.
+
+      Your Discriminator
+
+         Value to be copied from the My Discriminator field of the
+         received BFD packet.
+
+      Desired Min TX Interval
+
+         Value to be copied from the Desired Min TX Interval field of
+         the received BFD packet.
+
+      Required Min RX Interval
+
+         Set to bfd.RequiredMinRxInterval.  Value indicating the minimum
+         interval, in microseconds, between received S-BFD Control
+         packets.  Further details are provided in Section 7.2.3.
+
+      Required Min Echo RX Interval
+
+         If the device supports looping back S-BFD Echo packets
+
+            Set to the minimum required S-BFD Echo packet receive
+            interval for this session.
+
+         Else
+
+            Set to 0.
+
+7.2.3.  Additional SBFDReflector Behaviors
+
+   o  S-BFD Control packets transmitted by the SBFDReflector MUST have
+      Required Min RX Interval set to a value that expresses, in
+      microseconds, the minimum interval between incoming S-BFD Control
+      packets that this SBFDReflector can handle.  The SBFDReflector can
+      control how fast SBFDInitiators will be sending S-BFD Control
+      packets to themselves by ensuring that Required Min RX Interval
+      indicates a value based on the current load.
+
+
+
+
+
+Pignataro, et al.            Standards Track                   [Page 12]
+
+RFC 7880                    Seamless BFD Base                  July 2016
+
+
+   o  When the SBFDReflector receives an S-BFD Control packet from an
+      SBFDInitiator, then the SBFDReflector needs to determine what
+      "state" to send in the response S-BFD Control packet.  If the
+      monitored local entity is in service, then the state MUST be set
+      to UP.  If the monitored local entity is "temporarily out of
+      service", then the state SHOULD be set to AdminDown.
+
+   o  If an SBFDReflector receives an S-BFD Control packet with the
+      Demand (D) bit cleared, the packet MUST be discarded (see
+      Appendix A).
+
+7.3.  Initiator Procedures
+
+   S-BFD Control packets transmitted by an SBFDInitiator MUST set the
+   Your Discriminator field to an S-BFD Discriminator corresponding to
+   the remote entity.
+
+   Every SBFDInitiator MUST have a locally unique My Discriminator value
+   allocated from the BFD Discriminator pool.
+
+   Figure 3 describes the high-level concept of continuity testing using
+   S-BFD.  R2 allocates XX as the S-BFD Discriminator for network
+   reachability purposes and advertises XX to neighbors.  Figure 3 shows
+   R1 and R4 performing a continuity test to R2.
+
+          +--- md=50/yd=XX (ping) ----+
+          |                           |
+          |+-- md=XX/yd=50 (pong) --+ |
+          ||                        | |
+          |v                        | v
+          R1 ==================== R2[*] ========= R3 ========= R4
+                                    | ^                        |^
+                                    | |                        ||
+                                    | +-- md=60/yd=XX (ping) --+|
+                                    |                           |
+                                    +---- md=XX/yd=60 (pong) ---+
+
+         [*] Reflector BFD session on R2.
+         === Links connecting network nodes.
+         --- S-BFD Control packet traversal.
+
+                      Figure 3: S-BFD Continuity Test
+
+
+
+
+
+
+
+
+
+Pignataro, et al.            Standards Track                   [Page 13]
+
+RFC 7880                    Seamless BFD Base                  July 2016
+
+
+7.3.1.  SBFDInitiator State Machine
+
+   An SBFDInitiator may be a "persistent" session on the initiator with
+   a timer for S-BFD Control packet transmissions (stateful
+   SBFDInitiator).  An SBFDInitiator may also be a module, a script, or
+   a tool on the initiator that transmits one or more S-BFD Control
+   packets "when needed" (stateless SBFDInitiator).  For stateless
+   SBFDInitiators, a complete BFD state machine may not be applicable.
+   For stateful SBFDInitiators, the states and the state machine
+   described in [RFC5880] will not function due to the SBFDReflector
+   session only sending the UP and AdminDown states (i.e., the
+   SBFDReflector session does not send the INIT state).  The following
+   diagram provides the RECOMMENDED state machine for stateful
+   SBFDInitiators.  The notation on each arc represents the state of the
+   SBFDInitiator (as received in the State field in the S-BFD Control
+   packet) or indicates the expiration of the Detection Timer.  See
+   Figure 4.
+
+                       +--+
+          ADMIN DOWN,  |  |
+          TIMER        |  V
+                     +------+   UP                +------+
+                     |      |-------------------->|      |----+
+                     | DOWN |                     |  UP  |    | UP
+                     |      |<--------------------|      |<---+
+                     +------+   ADMIN DOWN,       +------+
+                                TIMER
+
+               Figure 4: SBFDInitiator Finite State Machine
+
+   Note that the above state machine is different from the base BFD
+   specification [RFC5880].  This is because the INIT state is no longer
+   applicable for the SBFDInitiator.  Another important difference is
+   the transition of the state machine from the DOWN state to the UP
+   state when a packet with an UP state setting is received by the
+   SBFDInitiator.  The definitions of the states and events have the
+   same meanings as those defined in the base BFD specification
+   [RFC5880].
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pignataro, et al.            Standards Track                   [Page 14]
+
+RFC 7880                    Seamless BFD Base                  July 2016
+
+
+7.3.2.  Transmission of S-BFD Control Packet by SBFDInitiator
+
+   The contents of S-BFD Control packets sent by an SBFDInitiator MUST
+   be set as per Section 6.8.7 of [RFC5880].  There are a few fields
+   that need to be set differently from [RFC5880], as follows:
+
+      Demand (D)
+
+         Used to indicate that the S-BFD packet originated from the
+         SBFDInitiator.  Always set to 1.
+
+      Your Discriminator
+
+         Set to bfd.RemoteDiscr.  bfd.RemoteDiscr is set to the
+         Discriminator value of the remote entity.  It MAY be learnt
+         from routing protocols or configured locally.
+
+      Required Min RX Interval
+
+         Set to 0.
+
+      Required Min Echo RX Interval
+
+         Set to 0.
+
+7.3.3.  Additional SBFDInitiator Behaviors
+
+   o  If the SBFDInitiator receives a valid S-BFD Control packet in
+      response to a transmitted S-BFD Control packet to a remote entity,
+      then the SBFDInitiator SHOULD conclude that the S-BFD Control
+      packet reached the intended remote entity.
+
+   o  When an SBFDInitiator receives a response S-BFD Control packet, if
+      the state specified is AdminDown, the SBFDInitiator MUST NOT
+      conclude that the reachability of the corresponding remote entity
+      is lost and MUST back off the packet transmission interval for the
+      remote entity to an interval no faster than 1 second.
+
+   o  When a sufficient number of S-BFD packets have not arrived as they
+      should, the SBFDInitiator SHOULD declare loss of reachability to
+      the remote entity.  The criteria for declaring loss of
+      reachability and the action that would be triggered as a result
+      are outside the scope of this document; the action MAY include
+      logging an error.
+
+
+
+
+
+
+
+Pignataro, et al.            Standards Track                   [Page 15]
+
+RFC 7880                    Seamless BFD Base                  July 2016
+
+
+   o  Regarding the third bullet item, it is critical for an
+      implementation to understand the latency to/from the Reflector BFD
+      session on the responder.  In other words, for the very first
+      S-BFD packet transmitted by the SBFDInitiator, an implementation
+      MUST NOT expect a response S-BFD packet to be received for a time
+      equivalent to the sum of the latencies: initiator to responder and
+      responder back to initiator.
+
+   o  If the SBFDInitiator receives an S-BFD Control packet with the
+      Demand (D) bit set, the packet MUST be discarded (see Appendix A).
+
+7.4.  Diagnostic Values
+
+   The diagnostic value in both directions MAY be set to a certain
+   value, to attempt to communicate further information to both ends.
+   Implementations MAY use the already-existing diagnostic values
+   defined in Section 4.1 of [RFC5880].  However, details regarding this
+   topic are outside the scope of this specification.
+
+7.5.  The Poll Sequence
+
+   The Poll Sequence MAY be used in both directions.  The Poll Sequence
+   MUST operate in accordance with [RFC5880].  An SBFDReflector MAY use
+   the Poll Sequence to slow down the rate at which S-BFD Control
+   packets are generated from an SBFDInitiator.  This is done by the
+   SBFDReflector, using the procedures described in Section 7.2.3 and
+   setting the Poll (P) bit in the reflected S-BFD Control packet.  The
+   SBFDInitiator is to then send the next S-BFD Control packet with the
+   Final (F) bit set.  If an SBFDReflector receives an S-BFD Control
+   packet with the P bit set, then the SBFDReflector MUST respond with
+   an S-BFD Control packet with the P bit cleared and the F bit set.
+
+8.  Operational Considerations
+
+   S-BFD provides a smooth and continuous (i.e., seamless) operational
+   experience as an Operations, Administration, and Maintenance (OAM)
+   mechanism for connectivity checking and connection verification.
+   This is achieved by providing a simplified mechanism with a large
+   proportion of negotiation aspects eliminated, resulting in faster and
+   simpler provisioning.
+
+   Because of this simplified mechanism, due to a misconfiguration an
+   SBFDInitiator could send S-BFD Control packets to a target that does
+   not exist or that is outside the S-BFD administrative domain.  As
+   explained in Section 7.3.1, an SBFDInitiator can be a persistent
+   initiator or a "when needed" one.  When an S-BFD persistent
+   SBFDInitiator is used, a deployment SHOULD ensure that S-BFD Control
+   packets do not propagate for an extended period of time outside of
+
+
+
+Pignataro, et al.            Standards Track                   [Page 16]
+
+RFC 7880                    Seamless BFD Base                  July 2016
+
+
+   the administrative domain that uses it.  Further, operational
+   measures SHOULD be taken to determine if responses to S-BFD packets
+   are not sent for an extended period of time and then remediate the
+   situation.  These potential concerns are largely mitigated by dynamic
+   advertisement mechanisms for S-BFD and with automation checks before
+   applying configurations.
+
+8.1.  Scaling Aspect
+
+   This mechanism brings forth one noticeable difference in terms of the
+   scaling aspect: the number of SBFDReflectors.  This specification
+   eliminates the need for egress nodes to have fully active BFD
+   sessions when only one side desires to perform continuity tests.
+   With the introduction of the Reflector BFD concept, egress is no
+   longer required to create any active BFD sessions on a per-path/LSP/
+   function basis.  Because of this, the total number of BFD sessions in
+   a network is reduced.
+
+8.2.  Congestion Considerations
+
+   When S-BFD performs failure detection, it consumes resources,
+   including bandwidth and CPU processing.  To avoid congestion, it is
+   therefore imperative that operators correctly provision the rates at
+   which S-BFD packets are transmitted.  When BFD is used across
+   multiple hops, a congestion control mechanism MUST be implemented,
+   and when congestion is detected, the BFD implementation MUST reduce
+   the amount of traffic it generates.  The exact mechanism used to
+   detect congestion is outside the scope of this specification but may
+   include the detection of lost BFD Control packets or other means.
+   The SBFDReflector can limit the rate at which SBFDInitiators will be
+   sending S-BFD Control packets by utilizing Required Min RX Interval,
+   but at the expense of detection time (i.e., detection time will
+   increase).
+
+9.  Co-existence with Classical BFD Sessions
+
+   Demultiplexing requirements for the initial packet are described in
+   Section 7.1.  Because of this, the S-BFD mechanism can co-exist with
+   classical BFD sessions.
+
+
+
+
+
+
+
+
+
+
+
+
+Pignataro, et al.            Standards Track                   [Page 17]
+
+RFC 7880                    Seamless BFD Base                  July 2016
+
+
+10.  S-BFD Echo Function
+
+   The concept of the S-BFD Echo function is similar to the BFD Echo
+   function described in [RFC5880].  S-BFD Echo packets have the
+   destination of "self"; thus, S-BFD Echo packets are self-generated
+   and self-terminated after traversing a link/path.  S-BFD Echo packets
+   are expected to U-turn on the target node in the data plane and
+   MUST NOT be processed by any Reflector BFD sessions on the
+   target node.
+
+   When using the S-BFD Echo function, it is RECOMMENDED that:
+
+   o  Both S-BFD Control packets and S-BFD Echo packets be sent.
+
+   o  Both S-BFD Control packets and S-BFD Echo packets have the same
+      semantics in the forward direction to reach the target node.
+
+   In other words, it is not preferable to send just S-BFD Echo packets
+   without also sending S-BFD Control packets.  There are two reasons
+   behind this suggestion:
+
+   o  S-BFD Control packets can verify the reachability of the intended
+      target node; this allows one to have confidence that S-BFD Echo
+      packets are U-turning on the expected target node.
+
+   o  S-BFD Control packets can detect when the target node is going out
+      of service (i.e., by receiving AdminDown state).
+
+   S-BFD Echo packets can be spoofed and can U-turn in a transit node
+   before reaching the expected target node.  When the S-BFD Echo
+   function is used, it is RECOMMENDED in this specification that both
+   S-BFD Control packets and S-BFD Echo packets be sent.  While the
+   additional use of S-BFD Control packets alleviates these two
+   concerns, some form of authentication MAY still be included.
+
+   The usage of the Required Min Echo RX Interval field is described in
+   Sections 7.2.2 and 7.3.2.  Because of the stateless nature of
+   SBFDReflector sessions, a value specified in the Required Min Echo RX
+   Interval field is not very meaningful to the SBFDReflector.  Thus, it
+   is RECOMMENDED that the Required Min Echo RX Interval field simply be
+   set to zero by the SBFDInitiator.  The SBFDReflector MAY set the
+   Required Min Echo RX Interval field to an appropriate value to
+   control the rate at which it wants to receive S-BFD Echo packets.
+
+
+
+
+
+
+
+
+Pignataro, et al.            Standards Track                   [Page 18]
+
+RFC 7880                    Seamless BFD Base                  July 2016
+
+
+   The following aspects of S-BFD Echo functions are left as
+   implementation details and are outside the scope of this document:
+
+   o  Format of the S-BFD Echo packet (e.g., data beyond UDP header).
+
+   o  Procedures on when and how to use the S-BFD Echo function.
+
+11.  Security Considerations
+
+   The same security considerations as those described in [RFC5880]
+   apply to this document.  Additionally, implementing the following
+   measures will strengthen security aspects of the mechanism described
+   by this document:
+
+   o  The SBFDInitiator MAY pick a sequence number to be set in
+      "sequence number" in the Authentication Section, based on the
+      configured authentication mode.
+
+   o  The SBFDReflector MUST NOT use the crypto sequence number to make
+      a decision about accepting the packet.  This is because the
+      SBFDReflector does not maintain S-BFD peer state and because the
+      SBFDReflector can receive S-BFD packets from multiple
+      SBFDInitiators.  Consequently, BFD authentication can be used, but
+      not the sequence number.
+
+   o  The SBFDReflector MAY use the Auth Key ID in the incoming packet
+      to verify the Authentication Data.
+
+   o  The SBFDReflector MUST accept the packet if authentication is
+      successful.
+
+   o  The SBFDReflector MUST compute the Authentication Data and MUST
+      use the same sequence number that it received in the S-BFD Control
+      packet to which it is responding.
+
+   o  The SBFDInitiator SHOULD accept an S-BFD Control packet with a
+      sequence number within the permissible range.  One potential
+      approach is the procedure explained in [BFD-GEN-AUTH].
+
+   Using the above method,
+
+   o  SBFDReflectors continue to remain stateless, despite using
+      security.
+
+   o  SBFDReflectors are not susceptible to replay attacks, as they
+      always respond to S-BFD Control packets irrespective of the
+      sequence number carried.
+
+
+
+
+Pignataro, et al.            Standards Track                   [Page 19]
+
+RFC 7880                    Seamless BFD Base                  July 2016
+
+
+   o  An attacker cannot impersonate the responder, since the
+      SBFDInitiator will only accept S-BFD Control packets that come
+      with the sequence number that it had originally used when sending
+      the S-BFD Control packet.
+
+   Additionally, the use of strong forms of authentication is strongly
+   encouraged for S-BFD.  The use of Simple Password authentication
+   [RFC5880] potentially puts other services at risk if S-BFD packets
+   can be intercepted and those password values are reused for other
+   services.
+
+   Considerations related to loop problems are covered in Appendix A.
+
+12.  References
+
+12.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
+              (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
+              <http://www.rfc-editor.org/info/rfc5880>.
+
+12.2.  Informative References
+
+   [BFD-GEN-AUTH]
+              Bhatia, M., Manral, V., Zhang, D., and M. Jethanandani,
+              "BFD Generic Cryptographic Authentication", Work in
+              Progress, draft-ietf-bfd-generic-crypto-auth-06,
+              April 2014.
+
+   [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
+              DOI 10.17487/RFC791, September 1981,
+              <http://www.rfc-editor.org/info/rfc791>.
+
+   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
+              December 1998, <http://www.rfc-editor.org/info/rfc2460>.
+
+   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
+              Label Switching Architecture", RFC 3031,
+              DOI 10.17487/RFC3031, January 2001,
+              <http://www.rfc-editor.org/info/rfc3031>.
+
+
+
+
+
+Pignataro, et al.            Standards Track                   [Page 20]
+
+RFC 7880                    Seamless BFD Base                  July 2016
+
+
+   [RFC7881]  Pignataro, C., Ward, D., and N. Akiya, "Seamless
+              Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6,
+              and MPLS", RFC 7881, DOI 10.17487/RFC7881, July 2016,
+              <http://www.rfc-editor.org/info/rfc7881>.
+
+   [RFC7882]  Aldrin, S., Pignataro, C., Mirsky, G., and N. Kumar,
+              "Seamless Bidirectional Forwarding Detection (S-BFD) Use
+              Cases", RFC 7882, DOI 10.17487/RFC7882, July 2016,
+              <http://www.rfc-editor.org/info/rfc7882>.
+
+   [RFC7885]  Govindan, V. and C. Pignataro, "Seamless Bidirectional
+              Forwarding Detection (S-BFD) for Virtual Circuit
+              Connectivity Verification (VCCV)", RFC 7885,
+              DOI 10.17487/RFC7885, July 2016,
+              <http://www.rfc-editor.org/info/rfc7885>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pignataro, et al.            Standards Track                   [Page 21]
+
+RFC 7880                    Seamless BFD Base                  July 2016
+
+
+Appendix A.  Loop Problem and Solution
+
+   Consider a scenario where we have two nodes and both are S-BFD
+   capable.
+
+    Node A (IP 2001:db8::1) ----------------- Node B (IP 2001:db8::2)
+                                    |
+                                    |
+                         Man in the Middle (MITM)
+
+   Assume that Node A reserved a discriminator 0x01010101 for target
+   identifier 2001:db8::1 and has a reflector session in listening mode.
+   Similarly, Node B reserved a discriminator 0x02020202 for its target
+   identifier 2001:db8::2 and also has a reflector session in
+   listening mode.
+
+   Suppose that a MITM sends a spoofed packet with My Discriminator =
+   0x01010101, Your Discriminator = 0x02020202, source IP as
+   2001:db8::1, and destination IP as 2001:db8::2.  When this packet
+   reaches Node B, the reflector session on Node B will swap the
+   discriminators and IP addresses of the received packet and reflect it
+   back, since the Your Discriminator value of the received packet
+   matches the reserved discriminator of Node B.  The reflected packet
+   that reached Node A will have My Discriminator = 0x02020202 and
+   Your Discriminator = 0x01010101.  Since the Your Discriminator value
+   of the received packet matches the reserved discriminator of Node A,
+   Node A will swap the discriminators and reflect the packet back to
+   Node B.  Since the reflectors must set the TTL of the reflected
+   packets to 255, the above scenario will result in an infinite loop
+   because of just one malicious packet injected from the MITM.
+
+   The solution is to avoid the loop problem by using the D bit (Demand
+   mode bit).  The initiator always sets the D bit, and the reflector
+   always clears it.  This way, we can determine if a received packet
+   was a reflected packet and avoid reflecting it back.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pignataro, et al.            Standards Track                   [Page 22]
+
+RFC 7880                    Seamless BFD Base                  July 2016
+
+
+Acknowledgements
+
+   The authors would like to thank Jeffrey Haas, Greg Mirsky, Marc
+   Binderberger, and Alvaro Retana for performing thorough reviews and
+   providing a number of suggestions.  The authors would also like to
+   thank Girija Raghavendra Rao, Les Ginsberg, Srihari Raghavan, Vanitha
+   Neelamegam, and Vengada Prasad Govindan from Cisco Systems for
+   providing valuable comments.  Finally, the authors would also like to
+   thank John E. Drake and Pablo Frank for providing comments and
+   suggestions.
+
+Contributors
+
+   The following are key contributors to this document:
+
+      Tarek Saad, Cisco Systems, Inc.
+      Siva Sivabalan, Cisco Systems, Inc.
+      Nagendra Kumar, Cisco Systems, Inc.
+      Mallik Mudigonda, Cisco Systems, Inc.
+      Sam Aldrin, Google
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pignataro, et al.            Standards Track                   [Page 23]
+
+RFC 7880                    Seamless BFD Base                  July 2016
+
+
+Authors' Addresses
+
+   Carlos Pignataro
+   Cisco Systems, Inc.
+
+   Email: cpignata@cisco.com
+
+
+   Dave Ward
+   Cisco Systems, Inc.
+
+   Email: wardd@cisco.com
+
+
+   Nobo Akiya
+   Big Switch Networks
+
+   Email: nobo.akiya.dev@gmail.com
+
+
+   Manav Bhatia
+   Ionos Networks
+
+   Email: manav@ionosnetworks.com
+
+
+   Santosh Pallagatti
+
+   Email: santosh.pallagatti@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pignataro, et al.            Standards Track                   [Page 24]
+