One document matched: draft-ietf-bfd-seamless-use-case-04.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 I-D.ietf-spring-oam-usecase SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-spring-oam-usecase-01.xml">
<!ENTITY I-D.ietf-spring-segment-routing SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-spring-segment-routing-07.xml">
<!ENTITY I-D.ietf-spring-sr-oam-requirement SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-spring-sr-oam-requirement-01.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-04" ipr="trust200902">
<front>
<title abbrev="S-BFD Use Case">Seamless Bidirectional Forwarding Detection (BFD) Use Case</title>

<author fullname="Sam Aldrin"  surname="Aldrin"
 initials="S.">
      <organization>Google, Inc</organization>
      <address>
        <postal>
          <street>1600 Amphitheatre Parkway </street>
          <!-- Reorder these if your country does things differently -->
          <city>Mountain View</city>
          <region>CA </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="Manav Bhatia"  surname="Bhatia"
 initials="M.">
      <organization>Ionos Networks</organization>
      <address>
        <postal>
          <street></street>
          <!-- Reorder these if your country does things differently -->
          <city></city>
          <region></region>
          <code></code>
          <country></country>
        </postal>
        <phone></phone>
        <email>manav@ionosnetworks.com</email>
        <!-- uri and facsimile elements may also be added -->
      </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>Cisco</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country></country>
        </postal>
        <phone></phone>
        <email>naikumar@cisco.com</email>
      </address>
</author>

<date day="21" month="March" year="2016" />

<abstract>
	<t>
   This document provides various use cases for Bidirectional Forwarding
   Detection (BFD) and various requirements such that extensions could be
   developed to allow for simplified detection of forwarding failures.
	 </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 for failure detection. Even
though the protocol is simple, there are certain use cases, where faster setting up
of sessions and continuity check of the data forwarding paths is necessary. This document identifies 
various use cases and requirements related to those, such that 
necessary enhancements could be made to 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 creates complexity, not only from an operations point of view, but also in terms of the speed
at which these sessions could be established or deleted. 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. 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.
</t>
<section title="Terminology"> <!-- 1.1, line 122-->
<t>
The reader is expected to be familiar with the BFD, IP, MPLS and 
Segment Routing (SR) <xref target="I-D.ietf-spring-segment-routing"/> 
terminology and protocol constructs. This section identifies only the new terminology introduced.
</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.  The discriminator enables identification of the sender and receiver of BFD
packets of the particular session and perform proactive continuity monitoring of the forwarding path between the two.
<xref target="RFC5881"/> defines single hop BFD whereas 
<xref target="RFC5883"/>  defines multi-hop BFD, <xref target="RFC5884"/> BFD for MPLS LSPs, and
<xref target="RFC5885"/> - BFD for PWs.
</t>
<t>
Currently, BFD is best suited to verify that two end points are 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 end points, it is necessary to provide the
   node information associated with the connection at each end point 
   prior to initiating BFD sessions, such that this information can be used 
   to verify that the connection is up and verifiable.
</t>
<t>
   If this information is already known to the end-points of a potential BFD
   session, the initial handshake including an exchange of this node-specific
   information is unnecessary and it is possible for the end points to begin
   BFD messaging seamlessly.  In fact, the initial exchange of discriminator
   information is an unnecessary extra step that may be avoided for these
   cases.
</t>
<!--
<t>
In order to establish BFD sessions between network entities and seamlessly be able to have the session up 
and running, BFD protocol should be capable of doing that. These sessions have to be established a priori to 
traffic flow and ensure the forwarding path is available and connectivity is present. With handshake mechanism 
within BFD protocol, establishing sessions at a rapid rate and ensuring the validity or existence of working forwarding 
path, prior to the session being up and running, becomes complex and time consuming. In order to achieve 
seamless BFD sessions, it requires a mechanism where the ability to specify the discriminators and the ability 
to respond to the BFD control packets by the network node, should already be negotiated ahead of the session 
becoming active. Seamless BFD by definition will be able to provide those mechanisms within the BFD protocol 
in order to meet the requirements and establish BFD sessions seamlessly, with minimal overhead, in order to 
detect forwarding failures. 
</t>
-->
<t>
In a given scenario, where an entity (such as an operator, or centralized controller) determines 
a set of network entities to which BFD 
sessions might need to be established. Each of those network entities  is assigned a BFD discriminator, 
to establish a BFD session. These network entities will create a BFD session instance that listens for incoming 
BFD control packets. Mappings between selected network entities and corresponding BFD discriminators 
are known to other network nodes belonging in the same network by some means. A network entity in this network is then able to 
send a BFD control packet to a particular target with the corresponding BFD discriminator. 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 
specifications.
</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 
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 
networks.  Another example is when a unidirectional tunnel uses BFD to validate reachability of an egress node.  
</t>
<t>
If the traditional BFD is to be used, the target network entity has to be provisioned as well, even though the reverse path 
validation with BFD session is not required. However, in the case 
of unidirectional BFD, there is no need for provisioning on the target network entity 
. 
Once the mechanism within the BFD protocol is in place, session could be established in a single direction. 
When the targeted network entity receives the packet, it 
knows that BFD packet, based on the discriminator and processes it. 
This does not necessitates the requirement for establishment of a bi-directional 
session, hence the two way handshake to exchange discriminators is not needed. 
</t>
<t>
Thus the 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 in the reverse direction. 
This requires  to ensure that the target network entity (for the BFD session), upon receipt of BFD packet, 
MUST start processing 
for the discriminator received in the BFD packet. The source network entity 
MUST be able to establish a unidirectional BFD session without 
the bidirectional handshake of discriminators for session establishment. 
</t>
</section> <!-- ends: "3.1 from line 143-->

<section title="Validation of forwarding path prior to traffic switching"> <!-- 3.2, line 152-->
<t>
BFD provides data delivery confidence when reachability validation is performed prior to traffic utilizing specific paths/LSPs. 
However this comes with a cost, where, traffic is prevented to use such paths/LSPs 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 could be well supported by eliminating the need for
session negotiation and discriminator 
exchanges in order to establish the BFD session. 
</t>
<t>
All it takes is for the network entities to know what the discriminator values to be 
used for the session. The same is the case for S-BFD, i.e., the three-way handshake mechanism is eliminated during 
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, e.g. in Software Defined
Networks (SDN).  It will be desirable to perform BFD validation as soon as the LSP?s are created, in order to use them.
</t>
<t>
In order to support this use case, the BFD session MUST be able to be 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 where intelligence, 
traditionally placed in a distributed and dynamic control plane, is separated from 
the networking entities along the data path, instead resides in a logically 
centralized place. There are various controllers that  perform this exact function in establishment of forwarding paths for the 
data flow. Traffic engineering is one important function, where 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, ability to manage and maintain the dynamic network 
becomes a challenge. One way to ensure the forwarding paths are valid, and working, is done by validation of  
the network 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 control plane protocols, it may be  
desirable to verify, not only the forwarding path but also of any arbitrary 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>
Traditional BFD session establishment and validation of the forwarding path must not become a bottleneck in the case of 
centralized traffic engineering. If the controller or other centralized entity is able to instantly verify a forwarding path of the 
TE tunnel , it could steer the traffic onto the traffic engineered tunnel very quickly thus minimizing adverse effect on a service. 
This is especially useful and needed when the scale of the network and number of TE tunnels is very high. 
</t>
<t>
The cost associated with BFD session negotiation and establishment of BFD sessions to identify valid paths is very high 
and providing network redundancy becomes 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"/>. 
Various OAM requirements for Segment Routing were captured in <xref target="I-D.ietf-spring-sr-oam-requirement"/>.
In validating this use case, one of the requirements is to ensure the BFD packet's behavior is according to the requirement 
and monitoring of the segment, where the packet is U-turned at the expected node. One of the criterion is to ensure the continuity 
check to the adjacent segment-id.
</t>
<t>
To support this use case, BFD MUST be able to perform liveness detection 
initated from centralized controller 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. parameters ? such as  interval, multiplier, etc 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, i.e. microwave, low powered nano-cells, etc. In these 
scenarios, it is desirable for BFD to slow down, speed up, stop or resume at will witho minimal additional BFD packets
exchanged to establish a new or modified session.
</t>
<t>
The established BFD session parameters and attributes like 
transmission interval, receiver interval, etc., MUST be modifiable without changing the state of the session. 
</t>
</section> <!-- ends: "3.5 from line 173-->

<section title="BFD for Anycast Address"> <!-- 3.6, line 178-->
<t> 
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>
To support this use case, the BFD MUST be able to send packets in order to be received 
by any of nodes hosting anycast address to which the BFD packets being sent and to respond. 
This requirement does not require BFD session establishment with every node hosting the anycast address.
</t>
</section> <!-- ends: "3.6 from line 178-->

<section title="BFD Fault Isolation"> <!-- 3.7, line 183-->
<t> 
BFD multi-hop <xref target="RFC5883"/>and BFD MPLS <xref target="RFC5884"/> 
traverse 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 the path. Fast failure detection allows
for 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. Usage of other tools to 
isolate the fault may cause the packets to traverse a different path through the network (e.g. if ECMP is used). In addition, the longer it 
takes from BFD session failure to fault isolation attempt, more likely that the fault cannot 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 and 
such packets will get load balanced in very similar way, if not the same, as BFD packets that went missing.
</t>
<t>
To support this requirement, BFD SHOULD support fault isolation capability using status indicating fields, when encountered. 
</t>
</section> <!-- ends: "3.7 from line 183-->

<section title="Multiple BFD Sessions to Same Target"> <!-- 3.8, line 188-->
<t> 
BFD is capable of providing very fast failure detection, as relevant network nodes continuously transmit BFD packets 
at negotiated rate. If BFD packet transmission is interrupted, even for a very short period of time, that can result in BFD to 
declare 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 can be protected, if a node was to run multiple BFD sessions to targets, hosted on different parts 
of the system (ex: different CPU instances). This can reduce BFD false failures, resulting in more stable network.
</t>
</section> <!-- ends: "3.8 from line 188-->

<section title="MPLS BFD Session Per ECMP Path"> <!-- 3.9, line 193-->
<t>
BFD for MPLS, 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 egress 
node. Section 4 of <xref target="RFC5884"/> also describes a possibility of running multiple BFD sessions per alternative 
paths of LSP.  However, details on how to bootstrap and maintain correct set of BFD sessions on the egress node is absent.
</t>
<t>
When an LSP has ECMP segment, it may be desirable to run in-band monitoring that exercises every path of ECMP.  
Otherwise there will be scenarios where in-band BFD session remains up through one path but traffic is black-holing 
over another path.  BFD session per ECMP path of LSP requires definition of  procedures that update 
<xref target="RFC5884"/> in terms of how to bootstrap and maintain correct set of BFD sessions on the egress node.  
However, that may require 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 MPLS echo request, it would simplify implementations and operations, and benefits network devices as less 
processing are required by them.
</t>
<t>
To support this requirement, multiple BFD sessions MUST be able 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">

<t>

REQ#1- A target network entity (for the BFD
session), upon receipt of BFD packet, MUST start processing for the discriminator received in
the BFD packet.

</t>

<t>

REQ#2- The source network entity MUST be able to
establish a unidirectional BFD session without the bidirectional
handshake of discriminators for session establishment.
</t>
<t>
REQ#3 - The BFD session MUST be able to be established without 
the need for session negotiation and exchange of discriminators.
</t>
<t>
REQ#4 - BFD MUST be able to perform liveness detection initated from 
centralized controller for any given segment under its domain.
</t>
<t>
REQ#5 - The established BFD session parameters and attributes like transmission 
interval, receiver interval, etc., MUST be modifiable without changing the state of the session. 
</t>
<t>
REQ#6 - The BFD MUST be able to send and receive response to
control packets addressed to an anycast address to be received 
by any of nodes hosting that address. This requirement does not require BFD session 
establishment with every node hosting the anycast address.
</t>
<t>
REQ#7 - BFD SHOULD support fault isolation capability and to indicate the same, when fault is encountered.
</t>
<t>
REQ#8 ? BFD MUST be able to establish multiple sessions between 
the same pair of source and target nodes. This requirement enables but does not guarantee
ability to monitor diverge paths in ECMP environment. The mapping between BFD session
and particular ECMP path is out the scope of BFD  specification.

</t>


</section>
<section title="Security Considerations"> <!-- 4, line 201-->
<t>
This document details the use cases and identifies various requirements for the same. 
As this document do not propose any new protocol or changes to the existing ones,  
no new security considerations have been identified with this draft.
</t>
</section> <!-- ends: "4 from line 201-->

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

<section title="Contributors"> <!-- 8, line 276-->
<t>Carlos Pignataro
</t>
<t>Cisco Systems
</t>
<t>Email: cpignata@cisco.com
</t>
<t>Glenn Hayden
</t>
<t>ATT
</t>
<t>Email: gh1691@att.com
</t>
<t>Santosh P K
</t>
<t>Juniper
</t>
<t>Email: santoshpk@juniper.net
</t>
<t>Mach Chen
</t>
<t>Huawei
</t>
<t>Email: mach.chen@huawei.com
</t>
<t>Nobo Akiya
</t>
<t>Cisco Systems
</t>
<t>Email: nobo@cisco.com
</t>
</section> <!-- ends: "8 from line 276-->

    <section title="Acknowledgements">
      <t>The authors would like to thank Eric Gray for
      his useful comments.</t>
    </section>

</middle>

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

    &RFC5881;

    &RFC4379;

    &RFC5883;

    &RFC5880;

    &RFC5884;

    &RFC5885;

</references>

<references title="Informative References">

   &I-D.ietf-spring-oam-usecase;
   &I-D.ietf-spring-segment-routing;
   
&I-D.ietf-spring-sr-oam-requirement;
   
</references>
</back>
</rfc>
<!-- generated from file drafts\draft-ietf-bfd-seamless-use-case-01.nroff with nroff2xml 0.1.0 by Tomek Mrugalski -->