Network Working Group
Internet Engineering Task Force (IETF)                         S. Aldrin
Internet-Draft
Request for Comments: 7882                                  Google, Inc
Intended status: Inc.
Category: Informational                                     C. Pignataro
Expires: November 7, 2016
ISSN: 2070-1721                                                    Cisco
                                                               G. Mirsky
                                                                Ericsson
                                                                N. Kumar
                                                                   Cisco
                                                             May 6,
                                                               July 2016

     Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases
                  draft-ietf-bfd-seamless-use-case-08

Abstract

   This document describes various use cases for a Seamless Bidirectional
   Forwarding Detection (S-BFD), (S-BFD) and provides requirements such that
   protocol mechanisms allow for a simplified detection of forwarding
   failures.

   These use cases support S-BFD, as which is a simplified mechanism to use
   Bidirectional Forwarding Detection (BFD) for
   using BFD with a large portions proportion of negotiation aspects eliminated,
   accelerating the establishment of a BFD session.  S-BFD  The benefits of S-
   BFD include quick provisioning provisioning, as well as improved control and
   flexibility to for network nodes initiating the path monitoring.

Status of This Memo

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

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid 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 maximum candidate for any level of Internet
   Standard; see Section 2 of six months RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 7, 2016.
   http://www.rfc-editor.org/info/rfc7882.

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  . . . . . . . . . . . . . . . . . . . . . . . .   2 ....................................................3
      1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   3 ................................................3
   2. Introduction to Seamless BFD  . . . . . . . . . . . . . . . .   4 ....................................4
   3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   5 .......................................................5
      3.1. Unidirectional Forwarding Path Validation . . . . . . . .   5 ..................5
      3.2. Validation of the Forwarding Path Prior prior to
           Switching Traffic . . . . . . . . . . . . . . . . . . . . . . . . .   6 ..........................................6
      3.3. Centralized Traffic Engineering . . . . . . . . . . . . .   7 ............................7
      3.4. BFD in Centralized Segment Routing  . . . . . . . . . . .   8 .........................8
      3.5. Efficient BFD Operation under Resource Constraints  . . .   8 .........8
      3.6. BFD for Anycast Addresses . . . . . . . . . . . . . . . .   8 ..................................8
      3.7. BFD Fault Isolation . . . . . . . . . . . . . . . . . . .   9 ........................................9
      3.8. Multiple BFD Sessions to the Same Target Node . . . . . .   9 ..............9
      3.9. An MPLS BFD Session Per per ECMP Path . . . . . . . . . . . .  10 .........................10
   4. Detailed Requirements for a Seamless BFD  . . . . . . . . . .  10 .........................11
   5. Security Considerations . . . . . . . . . . . . . . . . . . .  12 ........................................12
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  12
   9. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     9.1. .....................................................12
      6.1. Normative References  . . . . . . . . . . . . . . . . . .  12
     9.2. ......................................12
      6.2. Informative References  . . . . . . . . . . . . . . . . .  13 ....................................13
   Acknowledgements ..................................................15
   Contributors ......................................................15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14 ................................................15

1.  Introduction

   Bidirectional Forwarding Detection (BFD) is a lightweight protocol, (BFD), as defined in [RFC5880], is
   a lightweight protocol used to detect forwarding failures.  Various
   protocols
   protocols, applications, and applications clients rely on BFD as its clients for failure
   detection.  Even though the protocol is lightweight and simple, there
   are certain use cases where faster setting up setup of sessions and faster
   continuity check checks of the data forwarding data-forwarding paths is 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 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, 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 uses use
   cases and protocol specific protocol-specific enhancements or proposals are outside the
   scope of this document as well.  Protocol definitions to support
   these use cases can be found at [I-D.ietf-bfd-seamless-base] in [RFC7880] and
   [I-D.ietf-bfd-seamless-ip]. [RFC7881].

1.1.  Terminology

   The reader is expected to be familiar with the BFD [RFC5880], IP
   [RFC0791]
   [RFC791] [RFC2460], MPLS [RFC3031], and Segment Routing (SR)
   [I-D.ietf-spring-segment-routing] terminologies [SR-ARCH]
   terms and protocol constructs.

1.2.  Requirements Language

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

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

   o  [RFC5883] defines BFD over multihop paths multi-hop paths.

   o  [RFC5884] defines BFD for MPLS Label Switched Paths (LSPs) (LSPs).

   o  [RFC5885] defines BFD for MPLS Pseudowires (PWs) (PWs).

   Currently, BFD is best suited to verify 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 verifiable. valid.  Currently, the exchange of
   discriminators and the demultiplexing of the initial BFD packets is are
   application dependent.

   If this information is already known to the end-points endpoints of a potential
   BFD session, the initial handshake including an exchange of
   discriminators is unnecessary 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, 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 Discriminator for each BFD
   session that the entity will participate in (see Section 6.3 of
   [RFC5880]).  However, a key goal of a Seamless BFD 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, Discriminators, and allowing those
   network entities are allowed to use one discriminator Discriminator value for
   multiple sessions.  Therefore, there may be only one or a few
   discriminators assigned to a node.  These network entities will
   create an S-BFD listener session instance that listens for incoming
   BFD control Control packets.  When the mappings between specific network
   entities and their corresponding BFD discriminators Discriminators are known to
   other network nodes belonging to the same administrative domain,
   then, without having received any BFD packet packets from a particular
   target, a network entity in this network is able to send a BFD
   control
   Control packet to the target's assigned discriminator in the
   Your Discriminator field.  The target network node, upon reception of
   such a BFD control Control packet, will transmit a response BFD control 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 mechanics. mechanisms.  Both of these high-level
   goals result in the S-BFD use cases. cases outlined in this document.

3.1.  Unidirectional Forwarding Path Validation

   Even though bidirectional verification of forwarding path paths is useful,
   there are scenarios where verification is only required in one
   direction between a pair of nodes.  One such case is, 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, 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 LDP-based MPLS networks.  A final example is when
   a unidirectional tunnel uses BFD to validate the reachability of an
   egress node.

   Additionally, there are operational implications to validation of the unidirectional path validation. has operational
   implications.  If the traditional BFD is to be used, the target network entity has to be provisioned
   entity, as well as an initiator, has to be provisioned, even though the reverse path
   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, entity -- only on the source one.
   entity.

   In this use case, a BFD session could be established in a single
   direction.  When the targeted target network entity receives the packet, it
   identities
   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 bi-directional session, hence bidirectional session; hence, the two way 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 for this use case 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 prior to Switching Traffic

   This

   In this use case is when case, BFD is used to verify reachability before sending
   traffic via a path/LSP.  This comes with at a cost, which is
   that cost: traffic is prevented to use
   from using the path/LSP until BFD is able to validate the reachability, which reachability;
   this could take seconds due to BFD session bring-up sequences
   [RFC5880], LSP ping 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, target and for the
   target to properly demultiplexing these, demultiplex these packets is for the source
   network entities to know what the discriminator Discriminator values to will be used for
   the session.  The same  This is also the case for S-BFD: the three-way
   handshake mechanism is eliminated during the bootstrap bootstrapping of BFD
   sessions.  However, this information is required at each entity to
   verify that BFD messages are being received from the expected end-points, hence
   endpoints; hence, the handshake mechanism serves no purpose.
   Elimination of the unnecessary handshake mechanism allows for faster
   reachability validation of BFD provisioned paths/LSPs.

   In addition, it is expected that some MPLS technologies will require
   traffic engineered
   traffic-engineered LSPs to be created dynamically, perhaps driven by
   external applications, as e.g. as, for example, in Software Defined Networks 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 in establishment of establishing forwarding paths for the data
   flow.  Traffic engineering (TE) 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 network, and its
   multiple data paths and node reachability 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 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 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 traffic-engineering use
   case that the traditional BFD session establishment and validation of
   the forwarding path does 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 traffic-engineered tunnel, it could steer the
   traffic onto the traffic engineered traffic-engineered tunnel very quickly quickly, thus
   minimizing adverse effect effects on a service.  This is even more useful
   and necessary when the scale of the network and the number of traffic
   engineered
   traffic-engineered tunnels grows. 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.

3.4.  BFD in Centralized Segment Routing

   A monitoring technique of for a Segment Routing network based on a
   centralized controller is described in [I-D.ietf-spring-oam-usecase]. [SR-MPLS].  Specific OAM
   Operations, Administration, and Maintenance (OAM) requirements for
   Segment Routing are captured in
   [I-D.ietf-spring-sr-oam-requirement]. [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, segment and
   that the packet is U-turned at the expected node.  This criteria criterion
   ensures the continuity check to the adjacent segment-id. 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 under in its domain.

3.5.  Efficient BFD Operation under Resource Constraints

   When BFD sessions are being setup, set up, torn down down, or modified (i.e.,
   when parameters such as interval intervals and multiplier multipliers are being
   modified), BFD requires additional packets packets, other than scheduled
   packet transmissions transmissions, to complete the negotiation procedures (i.e., P/F bits).
   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 low-powered and traffic sensitive traffic-sensitive networks; these
   include
   microwave, low powered nano-cells, microwave systems, low-powered nanocells, and others.  In
   these scenarios, it is desirable for BFD to slow down, speed up,
   stop, or resume at- 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 parameters, and such attributes like as
   transmission interval, interval and receiver interval, etc., 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, 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
   set of BFD agents to collectively form one endpoint of a BFD session.
   The concept of a Target Listener "target listener" in S-BFD solves 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, packet responds.  This use case does not imply the BFD session
   establishment with every node hosting the anycast address.
   Consequently, in this any cast 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 multihop 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 upon lack to receive some number of
   consecutive
   packet reception, which packets.  This failure can be caused by a fault anywhere
   along these
   path. 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).  The  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, if Equal-Cost Multipath (ECMP) is used. network.  In addition, the longer it takes from the time
   of BFD session failure to starting the time that fault isolation, isolation begins, the
   more likely that the fault will not be able to
   be isolated (e.g., a fault can get may be
   corrected via rerouting or routed around). some other means during that time).  If
   BFD had built-in fault isolation fault-isolation capability, fault isolation can get would be
   triggered at when the earliest sign of fault detection. was first detected.  This embedded fault
   isolation will would be more effective when (i.e., faults would be detected
   sooner) if those BFD fault isolation fault-isolation packets are load balanced were load-balanced in
   the same way as the BFD packets that were dropped, detecting the fault. dropped.

   This use case describes S-BFD fault isolation fault-isolation capabilities, utilizing
   a TTL field (e.g., as described in Section 5.1.1 of [I-D.ietf-bfd-seamless-ip]) [RFC7881]) or
   using status indicating fields. 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
   liveliness.  It is possible, on
   liveness.  On a system where BFD is running, it is possible for
   certain events to (intentionally or unintentionally) to cause a short brief
   interruption of BFD packet transmissions.  With distributed
   architectures of BFD implementations, this case can be protected.  In
   this case, the prevented.
   This use case of is for an S-BFD node running multiple BFD sessions to a targets,
   the same target node, with those sessions hosted on different system
   modules (e.g., in different CPU instances).  This can reduce BFD false
   failures, resulting in a more stable network.

   To support this use case, a mapping between the multiple
   discriminators on a single system, system and the specific entity within the that
   system is required.

3.9.  An MPLS BFD Session Per per ECMP Path

   BFD for MPLS LSPs, defined in [RFC5884], describes procedures to run for
   running BFD as an LSP in-band continuity check mechanism, through usage of mechanism by using
   MPLS
   echo request Echo Request messages [RFC4379] to bootstrap the BFD session on
   the target (i.e., egress) node.  Section 4 of [RFC5884] also
   describes a the possibility of running multiple BFD sessions per
   alternative paths of
   LSP. LSPs.  [RFC7726] further clarified clarifies the procedures, both for
   both ingress and egress nodes, of regarding how to bootstrap, maintain,
   and remove multiple BFD sessions for the same <MPLS LSP, FEC> tuple. tuple
   ("FEC" means Forwarding Equivalence Class).  However, this mechanism
   still requires the use of MPLS LSP Ping for bootstrapping,
   round-trips
   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
   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,
   node when ECMP paths and/or corresponding load balance load-balance hash keys
   change.  If a BFD session over any paths of the LSP can be
   instantiated, stopped stopped, and resumed without requiring additional
   procedures of for bootstrapping via an MPLS echo request Echo Request message, it
   would greatly simplify both implementations and operations, operations and
   benefits
   would benefit network devices devices, as less processing are would be required
   by them.

   To support this requirement, multiple S-BFD sessions need to be
   established over different ECMP paths from between the same pair of source to
   and target
   node. nodes.

4.  Detailed Requirements for a Seamless BFD

   REQ#1:   A

   REQ 1:   Upon receipt of an S-BFD packet, a target network entity
            (for the S-BFD session), upon
            receipt of the S-BFD packet, 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:

   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:

   REQ 3:   The S-BFD session MUST be able to be established without the
            need for the exchange of discriminators in during session
            negotiation.

   REQ#4:

   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 under in its domain.

   REQ#5:

   REQ 5:   The established S-BFD session parameters and attributes,
            such as transmission interval, interval and reception interval, etc., MUST
            be modifiable without changing the state of the session.

   REQ#6:

   REQ 6:   An S-BFD source network entity MUST be able to send S-BFD
            control Control
            packets to an anycast address which address.  These packets are received
            and processed by any node hosting that address, and must 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 BFD S-BFD session with every node hosing
            hosting the anycast address.

   REQ#7:

   REQ 7:   S-BFD SHOULD support fault isolation fault-isolation capability, which MAY
            be triggered when a fault is encountered.

   REQ#8:

   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
            diverge
            divergent paths in ECMP environments.  It also provides
            resiliency in distributed router architectures.  The mapping
            between BFD discriminators Discriminators and particular entities (e.g.,
            ECMP paths, or Line Cards) line cards) is out the scope of scope for the S-BFD
            specification.

   REQ#9:
            protocol.

   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:

   REQ 10:  S-BFD MUST incorporate robust security protections against
            impersonators, malicions 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 the use cases for S-BFD and identifies various
   associated requirements.  Some of these requirements are security
   related.  The use cases herein described herein do not expose a system to
   abuse or to 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 discarted because of the 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 a
   Seamless BFD S-BFD
   supporting these use cases and realizing these requirements will
   address the associated security considerations.  A
   Seamless BFD  S-BFD should not have
   reduced security capabilities as compared to traditional BFD.

6.  IANA Considerations

   There are no IANA considerations introduced by this document.

9.  References

9.1.

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

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

9.2.

6.2.  Informative References

   [I-D.ietf-bfd-seamless-base]
              Akiya, N., Pignataro, C., Ward, D., Bhatia, M., and J.
              Networks, "Seamless Bidirectional Forwarding Detection
              (S-BFD)", draft-ietf-bfd-seamless-base-09 (work in
              progress), April 2016.

   [I-D.ietf-bfd-seamless-ip]
              Akiya, N., Pignataro, C., and D. Ward, "Seamless
              Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6
              and MPLS", draft-ietf-bfd-seamless-ip-04 (work in
              progress), April 2016.

   [I-D.ietf-spring-oam-usecase]
              Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "A
              Scalable and Topology-Aware MPLS Dataplane Monitoring
              System", draft-ietf-spring-oam-usecase-03 (work in
              progress), April 2016.

   [I-D.ietf-spring-segment-routing]
              Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
              and R. Shakir, "Segment Routing Architecture", draft-ietf-
              spring-segment-routing-07 (work in progress), December
              2015.

   [I-D.ietf-spring-sr-oam-requirement]
              Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G.,
              and S. Litkowski, "OAM Requirements for Segment Routing
              Network", draft-ietf-spring-sr-oam-requirement-01 (work in
              progress), December 2015.

   [RFC0791]

   [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, 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>.

7.

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

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

Acknowledgements

   The authors would like to thank Tobias Gondrom and Eric Gray, Gray for
   their insightful and useful comments.  The authors appreciate the
   thorough review and comments provided by Dale R. Worley.

8.

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