doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc7882.txt b/doc/rfc/rfc7882.txt
new file mode 100644
index 0000000..08480a0
--- /dev/null
+++ b/doc/rfc/rfc7882.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         S. Aldrin
+Request for Comments: 7882                                  Google, Inc.
+Category: Informational                                     C. Pignataro
+ISSN: 2070-1721                                                    Cisco
+                                                               G. Mirsky
+                                                                Ericsson
+                                                                N. Kumar
+                                                                   Cisco
+                                                               July 2016
+
+
+     Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases
+
+Abstract
+
+   This document describes various use cases for Seamless Bidirectional
+   Forwarding Detection (S-BFD) and provides requirements such that
+   protocol mechanisms allow for simplified detection of forwarding
+   failures.
+
+   These use cases support S-BFD, which is a simplified mechanism for
+   using BFD with a large proportion of negotiation aspects eliminated,
+   accelerating the establishment of a BFD session.  The benefits of
+   S-BFD include quick provisioning, as well as improved control and
+   flexibility for network nodes initiating path monitoring.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   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).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see 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/rfc7882.
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al.                Informational                     [Page 1]
+
+RFC 7882                     S-BFD Use Cases                   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.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Terminology ................................................3
+   2. Introduction to Seamless BFD ....................................4
+   3. Use Cases .......................................................5
+      3.1. Unidirectional Forwarding Path Validation ..................5
+      3.2. Validation of the Forwarding Path prior to
+           Switching Traffic ..........................................6
+      3.3. Centralized Traffic Engineering ............................7
+      3.4. BFD in Centralized Segment Routing .........................8
+      3.5. Efficient BFD Operation under Resource Constraints .........8
+      3.6. BFD for Anycast Addresses ..................................8
+      3.7. BFD Fault Isolation ........................................9
+      3.8. Multiple BFD Sessions to the Same Target Node ..............9
+      3.9. An MPLS BFD Session per ECMP Path .........................10
+   4. Detailed Requirements for Seamless BFD .........................11
+   5. Security Considerations ........................................12
+   6. References .....................................................12
+      6.1. Normative References ......................................12
+      6.2. Informative References ....................................13
+   Acknowledgements ..................................................15
+   Contributors ......................................................15
+   Authors' Addresses ................................................15
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al.                Informational                     [Page 2]
+
+RFC 7882                     S-BFD Use Cases                   July 2016
+
+
+1.  Introduction
+
+   Bidirectional Forwarding Detection (BFD), as defined in [RFC5880], is
+   a lightweight protocol used to detect forwarding failures.  Various
+   protocols, applications, and clients rely on BFD for failure
+   detection.  Even though the protocol is lightweight and simple, there
+   are certain use cases where faster setup of sessions and faster
+   continuity checks of the data-forwarding paths are necessary.  This
+   document identifies these use cases and consequent requirements, such
+   that enhancements and extensions result in a Seamless BFD (S-BFD)
+   protocol.
+
+   BFD is a simple and lightweight "Hello" protocol to detect data-plane
+   failures.  With dynamic provisioning of forwarding paths on a large
+   scale, establishing BFD sessions for each of those paths not only
+   creates operational complexity but also causes undesirable delay in
+   establishing or deleting sessions.  The existing session
+   establishment mechanism of the BFD protocol has to be enhanced in
+   order to minimize the time for the session to come up to validate the
+   forwarding path.
+
+   This document specifically identifies various use cases and
+   corresponding requirements in order to enhance BFD and other
+   supporting protocols.  Specifically, one key goal is removing the
+   time delay (i.e., the "seam") between when a network node wants to
+   perform a continuity test and when the node completes that continuity
+   test.  Consequently, "Seamless BFD" (S-BFD) has been chosen as the
+   name for this mechanism.
+
+   While the identified requirements could meet various use cases, it is
+   outside the scope of this document to identify all of the possible
+   and necessary requirements.  Solutions related to the identified use
+   cases and protocol-specific enhancements or proposals are outside the
+   scope of this document as well.  Protocol definitions to support
+   these use cases can be found in [RFC7880] and [RFC7881].
+
+1.1.  Terminology
+
+   The reader is expected to be familiar with the BFD [RFC5880], IP
+   [RFC791] [RFC2460], MPLS [RFC3031], and Segment Routing [SR-ARCH]
+   terms and protocol constructs.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   [RFC2119].
+
+
+
+
+
+Aldrin, et al.                Informational                     [Page 3]
+
+RFC 7882                     S-BFD Use Cases                   July 2016
+
+
+2.  Introduction to Seamless BFD
+
+   BFD, as defined in [RFC5880], requires two network nodes to exchange
+   locally allocated discriminators.  These discriminators enable the
+   identification of the sender and the receiver of BFD packets over the
+   particular session.  Subsequently, BFD performs proactive continuity
+   monitoring of the forwarding path between the two.  Several
+   specifications describe BFD's multiple deployment uses:
+
+   o  [RFC5881] defines BFD over IPv4 and IPv6 for single IP hops.
+
+   o  [RFC5883] defines BFD over multi-hop paths.
+
+   o  [RFC5884] defines BFD for MPLS Label Switched Paths (LSPs).
+
+   o  [RFC5885] defines BFD for MPLS Pseudowires (PWs).
+
+   Currently, BFD is best suited for verifying that two endpoints are
+   mutually reachable or that an existing connection continues to be up
+   and alive.  In order for BFD to be able to initially verify that a
+   connection is valid and that it connects the expected set of
+   endpoints, it is necessary to provide each endpoint with the
+   discriminators associated with the connection at each endpoint prior
+   to initiating BFD sessions.  The discriminators are used to verify
+   that the connection is up and valid.  Currently, the exchange of
+   discriminators and the demultiplexing of the initial BFD packets are
+   application dependent.
+
+   If this information is already known to the endpoints of a potential
+   BFD session, the initial handshake including an exchange of
+   discriminators is unnecessary, and it is possible for the endpoints
+   to begin BFD messaging seamlessly.  A key objective of the S-BFD use
+   cases described in this document is to avoid needing to exchange the
+   initial packets before the BFD session can be established, with the
+   goal of getting to the established state more quickly; in other
+   words, the initial exchange of discriminator information is an
+   unnecessary extra step that may be avoided for these cases.
+
+   In a given scenario, an entity (such as an operator or a centralized
+   controller) determines a set of network entities to which BFD
+   sessions might need to be established.  In traditional BFD, each of
+   those network entities chooses a BFD Discriminator for each BFD
+   session that the entity will participate in (see Section 6.3 of
+   [RFC5880]).  However, a key goal of S-BFD is to provide operational
+   simplification.  In this context, for S-BFD, each of those network
+   entities is assigned one or more BFD Discriminators, and those
+   network entities are allowed to use one Discriminator value for
+   multiple sessions.  Therefore, there may be only one or a few
+
+
+
+Aldrin, et al.                Informational                     [Page 4]
+
+RFC 7882                     S-BFD Use Cases                   July 2016
+
+
+   discriminators assigned to a node.  These network entities will
+   create an S-BFD listener session instance that listens for incoming
+   BFD Control packets.  When the mappings between specific network
+   entities and their corresponding BFD Discriminators are known to
+   other network nodes belonging to the same administrative domain,
+   then, without having received any BFD packets from a particular
+   target, a network entity in this network is able to send a BFD
+   Control packet to the target's assigned discriminator in the
+   Your Discriminator field.  The target network node, upon reception of
+   such a BFD Control packet, will transmit a response BFD Control
+   packet back to the sender.
+
+3.  Use Cases
+
+   As per the BFD protocol [RFC5880], BFD sessions are established using
+   a handshake mechanism prior to validating the forwarding path.  This
+   section outlines some use cases where the existing mechanism may not
+   be able to satisfy the requirements identified.  In addition, some of
+   the use cases also stress the need for expedited BFD session
+   establishment while preserving the benefits of forwarding failure
+   detection using existing BFD mechanisms.  Both of these high-level
+   goals result in the S-BFD use cases outlined in this document.
+
+3.1.  Unidirectional Forwarding Path Validation
+
+   Even though bidirectional verification of forwarding paths is useful,
+   there are scenarios where verification is only required in one
+   direction between a pair of nodes.  One such case is when a static
+   route uses BFD to validate reachability to the next-hop IP router.
+   In this case, the static route is established from one network entity
+   to another.  The requirement in this case is only to validate the
+   forwarding path for that statically established unidirectional path.
+   Validation of the forwarding path in the direction of the target
+   entity to the originating entity is not required in this scenario.
+   Many LSPs have the same unidirectional characteristics and
+   unidirectional validation requirements.  Such LSPs are common in
+   Segment Routing and LDP-based MPLS networks.  A final example is when
+   a unidirectional tunnel uses BFD to validate the reachability of an
+   egress node.
+
+   Additionally, validation of the unidirectional path has operational
+   implications.  If traditional BFD is to be used, the target network
+   entity, as well as an initiator, has to be provisioned, even though
+   reverse-path validation with the BFD session is not required.
+   However, in the case of unidirectional BFD, there is no need for
+   provisioning on the target network entity -- only on the source
+   entity.
+
+
+
+
+Aldrin, et al.                Informational                     [Page 5]
+
+RFC 7882                     S-BFD Use Cases                   July 2016
+
+
+   In this use case, a BFD session could be established in a single
+   direction.  When the target network entity receives the packet, it
+   identifies the packet as BFD in an application-specific manner (for
+   example, a destination UDP port number).  Subsequently, the BFD
+   module processes the packet, using the Your Discriminator value as
+   context.  Then, the network entity sends a response to the
+   originator.  This does not necessitate the requirement for
+   establishment of a bidirectional session; hence, the two-way
+   handshake to exchange discriminators is not needed.  The target node
+   does not need to know the My Discriminator value of the source node.
+
+   Thus, in this use case a requirement for BFD is to enable session
+   establishment from the source network entity to the target network
+   entity without the need to have a session (and state) for the reverse
+   direction.  Further, another requirement is that the BFD response
+   from the target back to the sender can take any (in-band or
+   out-of-band) path.  The BFD module in the target network entity (for
+   the BFD session), upon receipt of a BFD packet, starts processing the
+   BFD packet based on the discriminator received.  The source network
+   entity can therefore establish a unidirectional BFD session without
+   the bidirectional handshake and exchange of discriminators for
+   session establishment.
+
+3.2.  Validation of the Forwarding Path prior to Switching Traffic
+
+   In this use case, BFD is used to verify reachability before sending
+   traffic via a path/LSP.  This comes at a cost: traffic is prevented
+   from using the path/LSP until BFD is able to validate reachability;
+   this could take seconds due to BFD session bring-up sequences
+   [RFC5880], LSP Ping bootstrapping [RFC5884], etc.  This use case
+   would be better supported by eliminating the need for the initial BFD
+   session negotiation.
+
+   All it takes to be able to send BFD packets to a target and for the
+   target to properly demultiplex these packets is for the source
+   network entities to know what Discriminator values will be used for
+   the session.  This is also the case for S-BFD: the three-way
+   handshake mechanism is eliminated during the bootstrapping of BFD
+   sessions.  However, this information is required at each entity to
+   verify that BFD messages are being received from the expected
+   endpoints; hence, the handshake mechanism serves no purpose.
+   Elimination of the unnecessary handshake mechanism allows for faster
+   reachability validation of BFD provisioned paths/LSPs.
+
+
+
+
+
+
+
+
+Aldrin, et al.                Informational                     [Page 6]
+
+RFC 7882                     S-BFD Use Cases                   July 2016
+
+
+   In addition, it is expected that some MPLS technologies will require
+   traffic-engineered LSPs to be created dynamically, perhaps driven by
+   external applications, as, for example, in Software-Defined
+   Networking (SDN).  It will be desirable to perform BFD validation as
+   soon as the LSPs are created, so as to use them.
+
+   In order to support this use case, an S-BFD session is established
+   without the need for session negotiation and exchange of
+   discriminators.
+
+3.3.  Centralized Traffic Engineering
+
+   Various technologies in the SDN domain that involve controller-based
+   networks have evolved such that the intelligence, traditionally
+   placed in a distributed and dynamic control plane, is separated from
+   the networking entities themselves; instead, it resides in a
+   (logically) centralized place.  There are various controllers that
+   perform the function of establishing forwarding paths for the data
+   flow.  Traffic engineering is one important function, where the path
+   of the traffic flow is engineered, depending upon various attributes
+   and constraints of the traffic paths as well as the network state.
+
+   When the intelligence of the network resides in a centralized entity,
+   the ability to manage and maintain the dynamic network, and its
+   multiple data paths and node reachability, becomes a challenge.  One
+   way to ensure that the forwarding paths are valid and working is done
+   by validation using BFD.  When traffic-engineered tunnels are
+   created, it is operationally critical to ensure that the forwarding
+   paths are working, prior to switching the traffic onto the engineered
+   tunnels.  In the absence of distributed control-plane protocols, it
+   may be desirable to verify any arbitrary forwarding path in the
+   network.  With tunnels being engineered by a centralized entity, when
+   the network state changes, traffic has to be switched with minimum
+   latency and without black-holing of the data.
+
+   It is highly desirable in this centralized traffic-engineering use
+   case that the traditional BFD session establishment and validation of
+   the forwarding path do not become a bottleneck.  If the controller or
+   other centralized entity is able to very rapidly verify the
+   forwarding path of a traffic-engineered tunnel, it could steer the
+   traffic onto the traffic-engineered tunnel very quickly, thus
+   minimizing adverse effects on a service.  This is even more useful
+   and necessary when the scale of the network and the number of
+   traffic-engineered tunnels grow.
+
+   The cost associated with the time required for BFD session
+   negotiation and establishment of BFD sessions to identify valid paths
+   is very high when providing network redundancy is a critical issue.
+
+
+
+Aldrin, et al.                Informational                     [Page 7]
+
+RFC 7882                     S-BFD Use Cases                   July 2016
+
+
+3.4.  BFD in Centralized Segment Routing
+
+   A monitoring technique for a Segment Routing network based on a
+   centralized controller is described in [SR-MPLS].  Specific
+   Operations, Administration, and Maintenance (OAM) requirements for
+   Segment Routing are captured in [SR-OAM-REQS].  In validating this
+   use case, one of the requirements is to ensure that the BFD packet's
+   behavior is according to the monitoring specified for the segment and
+   that the packet is U-turned at the expected node.  This criterion
+   ensures the continuity check to the adjacent Segment Identifier.
+
+   To support this use case, the operational requirement is for BFD,
+   initiated from a centralized controller, to perform liveness
+   detection for any given segment in its domain.
+
+3.5.  Efficient BFD Operation under Resource Constraints
+
+   When BFD sessions are being set up, torn down, or modified (i.e.,
+   when parameters such as intervals and multipliers are being
+   modified), BFD requires additional packets, other than scheduled
+   packet transmissions, to complete the negotiation procedures (i.e.,
+   Poll (P) bits and Final (F) bits; see Section 4.1 of [RFC5880]).
+   There are scenarios where network resources are constrained: a node
+   may require BFD to monitor a very large number of paths, or BFD may
+   need to operate in low-powered and traffic-sensitive networks; these
+   include microwave systems, low-powered nanocells, and others.  In
+   these scenarios, it is desirable for BFD to slow down, speed up,
+   stop, or resume at will and with a minimal number of additional BFD
+   packets exchanged to modify the session or establish a new one.
+
+   The established BFD session parameters, and such attributes as
+   transmission interval and receiver interval, need to be modifiable
+   without changing the state of the session.
+
+3.6.  BFD for Anycast Addresses
+
+   The BFD protocol requires two endpoints to host BFD sessions, both
+   sending packets to each other.  This BFD model does not fit well with
+   anycast address monitoring, as BFD packets transmitted from a network
+   node to an anycast address will reach only one of potentially many
+   network nodes hosting the anycast address.
+
+   This use case verifies that a source node can send a packet to an
+   anycast address and that the target node to which the packet is
+   delivered can send a response packet to the source node.  Traditional
+   BFD cannot fulfill this requirement, since it does not provide for a
+
+
+
+
+
+Aldrin, et al.                Informational                     [Page 8]
+
+RFC 7882                     S-BFD Use Cases                   July 2016
+
+
+   set of BFD agents to collectively form one endpoint of a BFD session.
+   The concept of a "target listener" in S-BFD fulfills this
+   requirement.
+
+   To support this use case, the BFD sender transmits BFD packets, which
+   are received by any of the nodes hosting the anycast address to which
+   the BFD packets are being sent.  The anycast target that receives the
+   BFD packet responds.  This use case does not imply BFD session
+   establishment with every node hosting the anycast address.
+   Consequently, in this anycast use case, target nodes that do not
+   happen to receive any of the BFD packets do not need to maintain any
+   state, and the source node does not need to maintain separate state
+   for each target node.
+
+3.7.  BFD Fault Isolation
+
+   BFD for multi-hop paths [RFC5883] and BFD for MPLS LSPs [RFC5884]
+   perform end-to-end validation, traversing multiple network nodes.
+   BFD has been designed to declare a failure to receive some number of
+   consecutive packets.  This failure can be caused by a fault anywhere
+   along these paths.  Fast failure detection allows for rapid fault
+   detection and consequent rapid path recovery procedures.  However,
+   operators often have to follow up, manually or automatically, to
+   attempt to identify and localize the fault that caused BFD sessions
+   to fail (i.e., fault isolation).  If Equal-Cost Multipath (ECMP) is
+   used, the usage of other tools to isolate the fault (e.g.,
+   traceroute) may cause the packets to traverse a different path
+   through the network.  In addition, the longer it takes from the time
+   of BFD session failure to the time that fault isolation begins, the
+   more likely the fault will not be isolated (e.g., a fault may be
+   corrected via rerouting or some other means during that time).  If
+   BFD had built-in fault-isolation capability, fault isolation would be
+   triggered when the fault was first detected.  This embedded fault
+   isolation would be more effective (i.e., faults would be detected
+   sooner) if those BFD fault-isolation packets were load-balanced in
+   the same way as the BFD packets that were dropped.
+
+   This use case describes S-BFD fault-isolation capabilities, utilizing
+   a TTL field (e.g., as described in Section 5.1.1 of [RFC7881]) or
+   using fields that indicate status.
+
+3.8.  Multiple BFD Sessions to the Same Target Node
+
+   BFD is capable of providing very fast failure detection, as relevant
+   network nodes continuously transmit BFD packets at the negotiated
+   rate.  If BFD packet transmission is interrupted, even for a very
+   short period of time, BFD can declare a failure irrespective of path
+   liveness.  On a system where BFD is running, it is possible for
+
+
+
+Aldrin, et al.                Informational                     [Page 9]
+
+RFC 7882                     S-BFD Use Cases                   July 2016
+
+
+   certain events to (intentionally or unintentionally) cause a brief
+   interruption of BFD packet transmissions.  With distributed
+   architectures of BFD implementations, this case can be prevented.
+   This use case is for an S-BFD node running multiple BFD sessions to
+   the same target node, with those sessions hosted on different system
+   modules (e.g., in different CPU instances).  This can reduce false
+   failures, resulting in a more stable network.
+
+   To support this use case, a mapping between the multiple
+   discriminators on a single system and the specific entity within that
+   system is required.
+
+3.9.  An MPLS BFD Session per ECMP Path
+
+   BFD for MPLS LSPs, defined in [RFC5884], describes procedures for
+   running BFD as an LSP in-band continuity check mechanism by using
+   MPLS Echo Request messages [RFC4379] to bootstrap the BFD session on
+   the target (i.e., egress) node.  Section 4 of [RFC5884] also
+   describes the possibility of running multiple BFD sessions per
+   alternative of LSPs.  [RFC7726] further clarifies the procedures, for
+   both ingress and egress nodes, regarding how to bootstrap, maintain,
+   and remove multiple BFD sessions for the same <MPLS LSP, FEC> tuple
+   ("FEC" means Forwarding Equivalence Class).  However, this mechanism
+   still requires the use of MPLS LSP Ping for bootstrapping,
+   round trips for initialization, and keeping state at the receiver.
+
+   In the presence of ECMP within an MPLS LSP, it may be desirable to
+   run in-band monitoring that exercises every path of this ECMP.
+   Otherwise, there will be scenarios where an in-band BFD session
+   remains up through one path but traffic is black-holing over another
+   path.  A BFD session per ECMP path of an LSP requires the definition
+   of procedures that update [RFC5884] in terms of how to bootstrap and
+   maintain the correct set of BFD sessions on the egress node.
+   However, for traditional BFD, that requires the constant use of MPLS
+   Echo Request messages to create and delete BFD sessions on the egress
+   node when ECMP paths and/or corresponding load-balance hash keys
+   change.  If a BFD session over any paths of the LSP can be
+   instantiated, stopped, and resumed without requiring additional
+   procedures for bootstrapping via an MPLS Echo Request message, it
+   would greatly simplify both implementations and operations and
+   would benefit network devices, as less processing would be required
+   by them.
+
+   To support this requirement, multiple S-BFD sessions need to be
+   established over different ECMP paths between the same pair of source
+   and target nodes.
+
+
+
+
+
+Aldrin, et al.                Informational                    [Page 10]
+
+RFC 7882                     S-BFD Use Cases                   July 2016
+
+
+4.  Detailed Requirements for Seamless BFD
+
+   REQ 1:   Upon receipt of an S-BFD packet, a target network entity
+            (for the S-BFD session) MUST process the packet based on the
+            discriminator received in the BFD packet.  If the S-BFD
+            context is found, the target network entity MUST be able to
+            send a response.
+
+   REQ 2:   The source network entity MUST be able to establish a
+            unidirectional S-BFD session without the bidirectional
+            handshake of discriminators for session establishment.
+
+   REQ 3:   The S-BFD session MUST be able to be established without the
+            need for the exchange of discriminators during session
+            negotiation.
+
+   REQ 4:   In a Segment Routed network, S-BFD MUST be able to perform
+            liveness detection initiated from a centralized controller
+            for any given segment in its domain.
+
+   REQ 5:   The established S-BFD session parameters and attributes,
+            such as transmission interval and reception interval, MUST
+            be modifiable without changing the state of the session.
+
+   REQ 6:   An S-BFD source network entity MUST be able to send Control
+            packets to an anycast address.  These packets are received
+            and processed by any node hosting the anycast address.  The
+            S-BFD entity MUST be able to receive responses to S-BFD
+            Control packets from any of these anycast nodes, without
+            establishing a separate S-BFD session with every node
+            hosting the anycast address.
+
+   REQ 7:   S-BFD SHOULD support fault-isolation capability, which MAY
+            be triggered when a fault is encountered.
+
+   REQ 8:   S-BFD SHOULD be able to establish multiple sessions between
+            the same pair of source and target nodes.  This requirement
+            enables but does not guarantee the ability to monitor
+            divergent paths in ECMP environments.  It also provides
+            resiliency in distributed router architectures.  The mapping
+            between BFD Discriminators and particular entities (e.g.,
+            ECMP paths, line cards) is out of scope for the S-BFD
+            protocol.
+
+
+
+
+
+
+
+
+Aldrin, et al.                Informational                    [Page 11]
+
+RFC 7882                     S-BFD Use Cases                   July 2016
+
+
+   REQ 9:   The S-BFD protocol MUST provide mechanisms for loop
+            detection and prevention, protecting against malicious
+            attacks attempting to create packet loops.
+
+   REQ 10:  S-BFD MUST incorporate robust security protections against
+            impersonators, malicious actors, and various active and
+            passive attacks.  The simple and accelerated establishment
+            of an S-BFD session should not negatively affect security.
+
+5.  Security Considerations
+
+   This document details use cases for S-BFD and identifies various
+   associated requirements.  Some of these requirements are security
+   related.  The use cases described herein do not expose a system to
+   abuse or additional security risks.  Since some negotiation aspects
+   are eliminated, a misconfiguration can result in S-BFD packets being
+   sent to an incorrect node.  If this receiving node runs S-BFD, the
+   packet will be discarded due to discriminator mismatch.  If the node
+   does not run S-BFD, the packet will be naturally discarded.
+
+   The proposed new protocols, extensions, and enhancements for S-BFD
+   supporting these use cases and realizing these requirements will
+   address associated security considerations.  S-BFD should not have
+   reduced security capabilities as compared to traditional BFD.
+
+6.  References
+
+6.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>.
+
+   [RFC5881]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
+              (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
+              DOI 10.17487/RFC5881, June 2010,
+              <http://www.rfc-editor.org/info/rfc5881>.
+
+   [RFC5883]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
+              (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883,
+              June 2010, <http://www.rfc-editor.org/info/rfc5883>.
+
+
+
+
+
+Aldrin, et al.                Informational                    [Page 12]
+
+RFC 7882                     S-BFD Use Cases                   July 2016
+
+
+   [RFC5884]  Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
+              "Bidirectional Forwarding Detection (BFD) for MPLS Label
+              Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884,
+              June 2010, <http://www.rfc-editor.org/info/rfc5884>.
+
+   [RFC5885]  Nadeau, T., Ed., and C. Pignataro, Ed., "Bidirectional
+              Forwarding Detection (BFD) for the Pseudowire Virtual
+              Circuit Connectivity Verification (VCCV)", RFC 5885,
+              DOI 10.17487/RFC5885, June 2010,
+              <http://www.rfc-editor.org/info/rfc5885>.
+
+6.2.  Informative References
+
+   [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>.
+
+   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
+              Label Switched (MPLS) Data Plane Failures", RFC 4379,
+              DOI 10.17487/RFC4379, February 2006,
+              <http://www.rfc-editor.org/info/rfc4379>.
+
+   [RFC7726]  Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S.
+              Aldrin, "Clarifying Procedures for Establishing BFD
+              Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726,
+              DOI 10.17487/RFC7726, January 2016,
+              <http://www.rfc-editor.org/info/rfc7726>.
+
+   [RFC7880]  Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S.
+              Pallagatti, "Seamless Bidirectional Forwarding Detection
+              (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016,
+              <http://www.rfc-editor.org/info/rfc7880>.
+
+   [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>.
+
+
+
+
+
+Aldrin, et al.                Informational                    [Page 13]
+
+RFC 7882                     S-BFD Use Cases                   July 2016
+
+
+   [SR-ARCH]  Filsfils, C., Ed., Previdi, S., Ed., Decraene, B.,
+              Litkowski, S., and R. Shakir, "Segment Routing
+              Architecture", Work in Progress,
+              draft-ietf-spring-segment-routing-09, July 2016.
+
+   [SR-MPLS]  Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N.
+              Kumar, "A Scalable and Topology-Aware MPLS Dataplane
+              Monitoring System", Work in Progress,
+              draft-ietf-spring-oam-usecase-03, April 2016.
+
+   [SR-OAM-REQS]
+              Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G.,
+              and S. Litkowski, "OAM Requirements for Segment Routing
+              Network", Work in Progress,
+              draft-ietf-spring-sr-oam-requirement-02, July 2016.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al.                Informational                    [Page 14]
+
+RFC 7882                     S-BFD Use Cases                   July 2016
+
+
+Acknowledgements
+
+   The authors would like to thank Tobias Gondrom and Eric Gray for
+   their insightful and useful comments.  The authors appreciate the
+   thorough review and comments provided by Dale R. Worley.
+
+Contributors
+
+   The following are key contributors to this document:
+
+      Manav Bhatia, Ionos Networks
+      Satoru Matsushima, Softbank
+      Glenn Hayden, ATT
+      Santosh P K
+      Mach Chen, Huawei
+      Nobo Akiya, Big Switch Networks
+
+Authors' Addresses
+
+   Sam Aldrin
+   Google, Inc.
+
+   Email: aldrin.ietf@gmail.com
+
+
+   Carlos Pignataro
+   Cisco Systems, Inc.
+
+   Email: cpignata@cisco.com
+
+
+   Greg Mirsky
+   Ericsson
+
+   Email: gregory.mirsky@ericsson.com
+
+
+   Nagendra Kumar
+   Cisco Systems, Inc.
+
+   Email: naikumar@cisco.com
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al.                Informational                    [Page 15]
+