One document matched: draft-ietf-bfd-seamless-use-case-08.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5881 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5881.xml">
<!ENTITY RFC5883 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5883.xml">
<!ENTITY RFC5880 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5880.xml">
<!ENTITY RFC5884 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5884.xml">
<!ENTITY RFC5885 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5885.xml">
<!ENTITY RFC4379 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4379.xml">

<!ENTITY RFC0791 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0791.xml">
<!ENTITY RFC2460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC3031 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3031.xml">
<!ENTITY RFC7726 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7726.xml">

<!ENTITY I-D.ietf-bfd-seamless-base SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-bfd-seamless-base.xml">
<!ENTITY I-D.ietf-bfd-seamless-ip SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-bfd-seamless-ip.xml">

<!ENTITY I-D.ietf-spring-oam-usecase SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-spring-oam-usecase.xml">
<!ENTITY I-D.ietf-spring-segment-routing SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-spring-segment-routing.xml">
<!ENTITY I-D.ietf-spring-sr-oam-requirement SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-spring-sr-oam-requirement.xml">

]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?><?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-ietf-bfd-seamless-use-case-08" ipr="trust200902">
<front>
<title abbrev="S-BFD Use Cases">Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases</title>

<author fullname="Sam Aldrin"  surname="Aldrin"
 initials="S.">
      <organization>Google, Inc</organization>
      <address>
        <postal>
<!--
          <street>1600 Amphitheatre Parkway </street>
          <city>Mountain View</city>
          <region>CA </region>
-->
          <street></street>
          <!-- Reorder these if your country does things differently -->
          <city></city>
          <region></region>

          <code></code>
          <country></country>
        </postal>
        <phone></phone>
        <email>aldrin.ietf@gmail.com</email>
        <!-- uri and facsimile elements may also be added -->
      </address>
</author>

    <author fullname="Carlos Pignataro" initials="C."
            surname="Pignataro">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>
      <address>
        <email>cpignata@cisco.com</email>
      </address>
    </author>

<!--

<author fullname="Manav Bhatia"  surname="Bhatia"
 initials="M.">
      <organization>Ionos Networks</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country></country>
        </postal>
        <phone></phone>
        <email>manav@ionosnetworks.com</email>
      </address>
</author>

<author fullname="Satoru Matsushima"  surname="Matsushima"
 initials="S.">
      <organization>Softbank</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country></country>
        </postal>
        <phone></phone>
        <email>satoru.matsushima@g.softbank.co.jp</email>
      </address>
</author>

-->
<author fullname="Greg Mirsky"  surname="Mirsky"
 initials="G.">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country></country>
        </postal>
        <phone></phone>
        <email>gregory.mirsky@ericsson.com</email>
      </address>
</author>    

<author fullname="Nagendra Kumar"  surname="Kumar"
 initials="N.">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country></country>
        </postal>
        <phone></phone>
        <email>naikumar@cisco.com</email>
      </address>
</author>



<date />

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

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

</abstract>

</front>

<middle>
<section title="Introduction"> <!-- 1, line 113-->
<t>
Bidirectional Forwarding Detection (BFD) is a lightweight protocol, as defined in <xref target="RFC5880"/>,
used to detect forwarding failures. Various protocols and applications 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
of sessions and faster continuity check of the data forwarding paths is necessary. This document identifies 
these use cases and consequent requirements, such that 
enhancements and extensions result in a Seamless BFD (S-BFD) protocol.
</t>
<t>
BFD is a simple 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.
</t>
<t>
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 a network node wants to perform a continuity test
   and the node completes that continuity test. Consequently, "Seamless
   BFD" (S-BFD) has been chosen as the name for this mechanism.

</t><t>
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 to the identified uses 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 at 
<xref target="I-D.ietf-bfd-seamless-base"/>
and
<xref target="I-D.ietf-bfd-seamless-ip"/>.
</t>
<section title="Terminology"> <!-- 1.1, line 122-->
<t>The reader is expected to be familiar with the BFD <xref target="RFC5880" />, IP 
<xref target="RFC0791" /> <xref target="RFC2460" />, MPLS <xref target="RFC3031" />, and
Segment Routing (SR) <xref target="I-D.ietf-spring-segment-routing"/> 
terminologies and protocol constructs.
</t>
</section> <!-- ends: "1.1 from line 122-->

        <section title="Requirements Language">
             <t>
	  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 
	  <xref target="RFC2119"></xref>.
             </t>
          </section>

</section> <!-- ends: "1 from line 113-->

<section title="Introduction to Seamless BFD"> <!-- 2, line 128-->
<t>
BFD, as defined in <xref target="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:
<list>
<t>
<xref target="RFC5881"/> defines BFD over IPv4 and IPv6 for single IP hops
</t><t>
<xref target="RFC5883"/>  defines BFD over multihop paths
</t><t>
<xref target="RFC5884"/> defines BFD for MPLS Label Switched Paths (LSPs)
</t><t>
<xref target="RFC5885"/> defines BFD for MPLS Pseudowires (PWs)
</t></list>
</t>
<t>
Currently, BFD is best suited to verify 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.  Currently, the exchange of discriminators and the
  demultiplexing of the initial BFD packets is application dependent.


</t>
<t>
   If this information is already known to the end-points 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.
</t>

<t>
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 <xref target="RFC5880"/>).

However, a key goal of a Seamless 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 allowing those network entities to use one 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 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 packet 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 BFD control packet, will transmit a response BFD control packet back to the sender.
</t>
</section> <!-- ends: "2 from line 128-->

<section title="Use Cases"> <!-- 3, line 138-->
<t>
As per the BFD protocol <xref target="RFC5880"/>, BFD sessions are established using 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 benefits of forwarding failure detection using existing BFD 
mechanics. Both these high-level goals result in the S-BFD use cases.
</t>





<section title="Unidirectional Forwarding Path Validation"> <!-- 3.1, line 143-->
<t>
Even though bidirectional verification of forwarding path 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 reachability of an egress node.  
</t>
<t>
Additionally, there are operational implications to the unidirectional path validation.
If the traditional BFD is to be used, the target network entity has to be provisioned as well as an initiator, even though the 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 the source one.
</t><t>
<!--
In this use case, a BFD session could be established in a single direction. 
When the targeted network entity receives the packet,
the Your Discriminator value in the packet instructs the network entity to process it, and send a response based on
the source address of the packet.
This does not necessitate the requirement for establishment of a bi-directional 
session, hence the two way handshake to exchange discriminators is not needed. The target node
does not need to know the My Discriminator of the source node.
-->
  In this use case, a BFD session could be established in a single
  direction.  When the targeted network entity receives the packet, it
  identities 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 the two way handshake to exchange
  discriminators is not needed.  The target node does not need to know
  the My Discriminator of the source node.

</t>
<t>
<!--
Thus, a requirement for BFD for this  use case is to enable session 
establishment from source network entity to 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 target back to sender can take any (in-band or out-of-band) path.
The target network entity (for the BFD session), upon receipt of 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 of discriminators for session establishment. 
-->
  Thus, a requirement for BFD for this use case is to enable session
  establishment from source network entity to 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 target back to 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 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.

</t>
</section> <!-- ends: "3.1 from line 143-->





<section title="Validation of the Forwarding Path Prior to Switching Traffic"> <!-- 3.2, line 152-->
<t>
   This use case is when BFD is used to verify reachability before
   sending traffic via a path/LSP.  This comes with a cost, which is
   that traffic is prevented to use the path/LSP until BFD is able to
   validate the reachability, which could take seconds 
due to BFD session bring-up sequences <xref target="RFC5880"/>, LSP ping bootstrapping 
<xref target="RFC5884"/>, etc.  This use
   case would be better supported by eliminating the need for the
   initial BFD session negotiation.

</t>
<t>
All it takes to be able to send BFD packets to a target, and the target properly demultiplexing these,
is for the source network entities to know what the discriminator values to be 
used for the session. The same is the case for S-BFD: the three-way handshake mechanism is eliminated during the
bootstrap 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 the handshake mechanism serves no purpose.
Elimination of the unnecessary handshake mechanism allows for faster reachability validation of BFD provisioned paths/LSPs. 
</t>
<t>
In addition, it is expected that some MPLS technologies will require traffic engineered LSPs to
be created dynamically, perhaps driven by external applications, as e.g. in Software Defined
Networks (SDN).  It will be desirable to perform BFD validation as soon as the LSPs are created, so as to use them.
</t>
<t>
In order to support this use case, an S-BFD session is established 
without the need for session negotiation and exchange of discriminators.
</t>
</section> <!-- ends: "3.2 from line 152-->









<section title="Centralized Traffic Engineering"> <!-- 3.3, line 159-->
<t>
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 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.
</t>
<t>
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 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. 
</t>
<t>
It is highly desirable in this centralized traffic engineering 
use case that the traditional BFD session establishment and validation of the forwarding path does
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 effect on a service. 
This is even more useful and necessary when the scale of the network and number of traffic engineered tunnels grows. 
</t>
<t>
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.
</t>
</section> <!-- ends: "3.3 from line 159-->





<section title="BFD in Centralized Segment Routing"> <!-- 3.4, line 168-->
<t>
A monitoring technique of a Segment Routing network based on a centralized
controller is described in <xref target="I-D.ietf-spring-oam-usecase"/>. 
Specific OAM requirements for Segment Routing are captured in <xref target="I-D.ietf-spring-sr-oam-requirement"/>.
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 criteria ensures the continuity 
check to the adjacent segment-id.
</t>
<t>
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 its domain.
</t>
</section> <!-- ends: "3.4 from line 168-->




<section title="Efficient BFD Operation under Resource Constraints"> <!-- 3.5, line 173-->
<t>
When BFD sessions are being setup, torn down or modified (i.e., when parameters such as interval and multiplier are being modified), BFD  
requires additional packets other than scheduled packet transmissions to complete the negotiation procedures (i.e., P/F bits). 
There are scenarios where network resources are constrained: a node may require BFD to monitor very large number of paths, 
or BFD may need to operate in low powered and traffic sensitive networks; these include microwave, low powered nano-cells, and others. 


In these scenarios, it is desirable for BFD to slow down, speed up, stop, or resume at-will and with minimal number of 
additional BFD packets
exchanged to modify the session or establish a new one.
</t>
<t>
The established BFD session parameters and attributes like 
transmission interval, receiver interval, etc., need to be modifiable without changing the state of the session. 
</t>
</section> <!-- ends: "3.5 from line 173-->





<section title="BFD for Anycast Addresses"> <!-- 3.6, line 178-->
<t> 
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.
</t>
<t>
 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 set of BFD agents to
collectively form one endpoint of a BFD session. The concept of a Target Listener in S-BFD solves this requirement.
</t>
<t>
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 being sent. The anycast target that receives the BFD packet, responds. 
This use case does not imply the BFD session establishment with every node hosting the anycast address.

Consequently, in this any cast 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.
</t>
</section> <!-- ends: "3.6 from line 178-->






<section title="BFD Fault Isolation"> <!-- 3.7, line 183-->
<t> 
BFD for multihop paths <xref target="RFC5883"/> and BFD for MPLS LSPs <xref target="RFC5884"/> perform end-to-end validation,
traversing multiple network nodes. BFD has been designed to declare failure upon lack of 
consecutive packet reception, which can be caused by a fault anywhere along these path. 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 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. 

In addition, the longer it 
takes from BFD session failure to starting fault isolation, the more likely that the fault will not be able to be isolated (e.g., a fault can get corrected 
or routed around).

If BFD had built-in fault isolation capability, fault isolation can get triggered at the earliest sign of fault detection. This embedded fault isolation will be more effective when those
BFD fault isolation packets are load balanced in the same way as the BFD packets that were dropped, detecting the fault.
</t>
<t>
This use case describes S-BFD fault isolation capabilities, utilizing a TTL field
(e.g., as in Section 5.1.1 of <xref target="I-D.ietf-bfd-seamless-ip"/>) or using status indicating fields. 
</t>
</section> <!-- ends: 3.7 from line 183-->





<section title="Multiple BFD Sessions to the Same Target Node"> <!-- 3.8, line 188-->
<t> 
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 a system where BFD is running, for certain events (intentionally 
or unintentionally) to cause a short interruption of BFD packet transmissions. With distributed architectures of BFD 
implementations, this case can be protected. 

In this case, the use case of an S-BFD node running multiple BFD sessions to a targets, with those sessions hosted on different
system modules (e.g., in different CPU instances). This can reduce BFD false failures, resulting in more stable network.
</t><t>
To support this use case, a mapping between the multiple discriminators on a single system, and the specific entity within the system is required.
</t>
</section> <!-- ends: 3.8 from line 188-->






<section title="An MPLS BFD Session Per ECMP Path"> <!-- 3.9, line 193-->
<t>
BFD for MPLS LSPs, defined in <xref target="RFC5884"/>, describes procedures to run BFD as LSP in-band continuity check 
mechanism, through usage of MPLS echo request <xref target="RFC4379"/> to bootstrap the BFD session on the target (i.e., egress)
node. Section 4 of <xref target="RFC5884"/> also describes a possibility of running multiple BFD sessions per alternative 
paths of LSP.


<xref target="RFC7726"/>
further clarified the procedures, both for ingress and egress nodes, of how to bootstrap, maintain, and remove multiple BFD sessions for the same <MPLS LSP, FEC> tuple.
However, this mechanism still requires the use of MPLS LSP Ping for bootstrapping, round-trips for initialization,
and keeping state at the receiver.

</t>
<t>
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 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 
<xref target="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 of bootstrapping 
via an MPLS echo request message, it would greatly simplify both implementations and operations, and benefits network devices as less 
processing are required by them.
</t>
<t>
To support this requirement, multiple S-BFD sessions need to be
established over different ECMP paths from the same source to target node.
</t>
</section> <!-- ends: "3.9 from line 193-->
</section> <!-- ends: "3 from line 138-->





<section title="Detailed Requirements for a Seamless BFD">

<t>

<list style="format REQ#%d:">
<t>

A target network entity (for the S-BFD
session), upon receipt of the S-BFD packet, 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.

</t>

<t>

The source network entity MUST be able to
establish a unidirectional S-BFD session without the bidirectional
handshake of discriminators for session establishment.


</t>
<t>
The S-BFD session MUST be able to be established without 
the need for exchange of discriminators in session negotiation.
</t>
<t>
In a Segment Routed network, S-BFD MUST be able to perform liveness detection initiated from a
centralized controller for any given segment under its domain.
</t>
<t>
The established S-BFD session parameters and attributes, such as transmission 
interval, reception interval, etc., MUST be modifiable without changing the state of the session. 
</t>
<t>
An S-BFD source network entity MUST be able to send S-BFD control packets to an anycast address which are
received by any node hosting that address, and must be able to receive responses from any of
these anycast nodes, without
establishing a separate BFD session with every node hosing the anycast
address.
</t>
<t>
S-BFD SHOULD support fault isolation capability, which MAY be triggered when a fault is encountered.
</t>
<t>
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 paths in ECMP environments. It also provides resiliency in distributed router architectures.
The mapping between BFD discriminators
and particular entities (e.g., ECMP paths, or Line Cards) is out the scope of the S-BFD specification.
</t><t>
The S-BFD protocol MUST provide mechanisms for loop detection and prevention, protecting against
malicious attacks attempting to create packet loops.
</t><t>
S-BFD MUST incorporate robust security protections against
            impersonators, malicions actors, and various active and passive attacks.  The
            simple and accelerated establishment of an S-BFD session
            should not negatively affect security. 
</t></list>

</t>


</section>
<section title="Security Considerations"> <!-- 4, line 201-->
<t>
This document details the use cases and identifies various associated requirements.
Some of these requirements are security related.

The use cases herein described 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 discriminator mismatch. If the node does not run S-BFD, the packet will be naturally discarded.
</t><t>
The proposed new protocols, extensions, and enhancements for a Seamless BFD supporting these use cases
and realizing these requirements will address the associated security considerations.
A Seamless BFD should not have reduced security capabilities as compared to traditional BFD.

</t>
</section> <!-- ends: "4 from line 201-->

<section title="IANA Considerations"> <!-- 5, line 206-->
<t>
There are no IANA considerations introduced by this document.
</t>
</section> <!-- ends: "5 from line 206-->


    <section title="Acknowledgements">
      <t>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.
</t>
    </section>


<section title="Contributors"> <!-- 8, line 276-->
<t>The following are key contributors to this document:

<list style="empty">
<?rfc subcompact="yes" ?>
<t>Manav Bhatia, Ionos Networks
</t>
<t>Satoru Matsushima, Softbank
</t>
<t>Glenn Hayden, ATT
</t>
<t>Santosh P K
</t>
<t>Mach Chen, Huawei
</t>
<t>Nobo Akiya, Big Switch Networks
</t>
</list>
<?rfc subcompact="no" ?>
</t>
<!--
<t>Carlos Pignataro
   <vspace blankLines="0" />
Cisco Systems
   <vspace blankLines="0" />
Email: cpignata@cisco.com
</t>


<t>Manav Bhatia
   <vspace blankLines="0" />
Ionos Networks
   <vspace blankLines="0" />
Email: manav@ionosnetworks.com
</t>


<t>Satoru Matsushima
   <vspace blankLines="0" />
Softbank
   <vspace blankLines="0" />
Email: satoru.matsushima@g.softbank.co.jp
</t>


<t>Glenn Hayden
   <vspace blankLines="0" />
ATT
   <vspace blankLines="0" />
Email: gh1691@att.com
</t>
<t>Santosh P K
   <vspace blankLines="0" />
Email: santosh.pallagatti@gmail.com
</t>
<t>Mach Chen
   <vspace blankLines="0" />
Huawei
   <vspace blankLines="0" />
Email: mach.chen@huawei.com
</t>
<t>Nobo Akiya
   <vspace blankLines="0" />
Big Switch Networks
   <vspace blankLines="0" />
Email: nobo.akiya.dev@gmail.com
</t>
-->
</section> <!-- ends: "8 from line 276-->



</middle>

<back>
<references title="Normative References">
&RFC2119;

    &RFC5881;

    &RFC5883;

    &RFC5880;

    &RFC5884;

    &RFC5885;

</references>

<references title="Informative References">

   &I-D.ietf-bfd-seamless-base;
   &I-D.ietf-bfd-seamless-ip;

   &I-D.ietf-spring-oam-usecase;
   &I-D.ietf-spring-segment-routing;
&I-D.ietf-spring-sr-oam-requirement;
&RFC0791;
&RFC2460;
&RFC3031;
&RFC4379;
&RFC7726;

   
</references>
</back>
</rfc>