One document matched: draft-akiya-bfd-seamless-sr-03.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->

<rfc category="std" docName="draft-akiya-bfd-seamless-sr-03" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <title abbrev="Seamless BFD for Segment Routing">
	Seamless Bidirectional Forwarding Detection (S-BFD) for Segment Routing
    </title>

    <!-- add 'role="editor"' below for the editors if appropriate -->
    <!-- Another author who claims to be an editor -->

    <author fullname="Nobo Akiya" initials="N."
            surname="Akiya">
      <organization>Cisco Systems</organization>
      <address>
        <email>nobo@cisco.com</email>
      </address>
    </author>

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

    <author fullname="Nagendra Kumar" initials="N."
            surname="Kumar">
      <organization>Cisco Systems</organization>
      <address>
        <email>naikumar@cisco.com</email>
      </address>
    </author>

    <date year="2014" />

    <area>BFD Working Group</area>
    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
    IETF is fine for individual submissions.  
	If this element is not present, the default is "Network Working Group",
    which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>BFD</keyword>
    <keyword>seamless BFD</keyword>
    <keyword>negotiation free</keyword>
    <keyword>segment routing</keyword>
    <keyword>SPRING</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
    	<t>This document defines procedures to use Seamless Bidirectional Forwarding Detection (S-BFD) for the Segment Routing environment.</t>
    </abstract>
	
	<note title="Requirements Language">
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>.</t>
	</note>
  </front>

  <middle>
    <section title="Introduction">

<t>Seamless Bidirectional Forwarding Detection (S-BFD), <xref target="I-D.ietf-bfd-seamless-base" />, defines a generalized mechanism to allow network nodes to seamlessly perform continuity checks to remote entities. This document defines necessary procedures to use S-BFD on the Segment Routing environment described by <xref target="I-D.filsfils-spring-segment-routing" />.</t>

<t>The reader is expected to be familiar with the IP, MPLS, Segment Routing <xref target="I-D.filsfils-spring-segment-routing" />, BFD <xref target="RFC5880" /> and S-BFD <xref target="I-D.ietf-bfd-seamless-base" /> terminologies and protocol constructs.</t>

    </section>

<section title="Inheritance of Code Points and Procedures">

<t>S-BFD on the Segment Routing MUST use the code points and procedures defined in <xref target="I-D.akiya-bfd-seamless-ip" /> regarding following aspects:

<list style="symbols">
<t>S-BFD UDP Port</t>
<t>S-BFD Echo UDP Port</t>
<t>S-BFD Control Packet Demultiplexing</t>
<t>Initiator Procedures</t>
<t>Responder Procedures</t>
</list>

The Segment Routing on the MPLS data plane is to use MPLS based procedures, and the Segment Routing on the IPv6 data plane is to use IP based procedures.
</t>

</section>

<section title="SBFDInitiator Models">

<t>The S-BFD technology defines an SBFDReflector and how SBFDInitiators speak to SBFDReflectors. Outside of these definitions, implementations are free to be flexible in terms of how SBFDInitiators behave. The packet steering capability of the Segment Routing allows for, at very high level, two distinct SBFDInitiator models. This section describes the two SBFDInitiator models as an implementation reference.</t>

<section title="Uncontrolled Return Path" anchor="_UNCONTROLLED">

<t>A network node sending S-BFD control packets to a remote target with particular segment stack will allow the network node to determine whether or not such packets reach the intended remote target. The network node can conclude the reachability when valid response S-BFD control packets are received back. In opposite, the network node can conclude the lack of reachability when valid response S-BFD control packet are not received back. Because S-BFD control packets back from the responder to the initiator will be IP routed, how S-BFD control packets traverse the network back to the initiator is uncontrolled. If the network employs good set of local protection mechanisms, this may not be concerning and the model of only sending S-BFD control packets may be sufficient.</t>

<t>In this model, SBFDInitiator is to send only S-BFD control packets.</t>

</section>

<section title="Controlled Return Path">

<t>In addition to SBFDInitiator sending S-BFD control packets, described in <xref target="_UNCONTROLLED" />, S-BFD echo packets can also be sent.

<figure align="left"><preamble></preamble><artwork align="left"><![CDATA[
      +-----B-------C-----+
     /                     \
    A-----------E-----------D
     \                     /
      +-----F-------G-----+

      Forward Paths: A-B-C-D
    IP Return Paths: D-E-A

      Figure 1: S-BFD Echo Example
]]></artwork></figure>

Node A sending S-BFD control packets with segment stack {B, C, D} will cause S-BFD control packets to traverse the paths A-B-C-D in the forward direction. The response S-BFD control packets from node D back to node A will be IP routed and will traverse the paths D-E-A. The SBFDInitiator sending such packets can also send S-BFD echo packets with segment stack {B, C, D, C, A}. S-BFD echo packets will u-turn on node D and traverse the paths D-C-B-A. If required, the SBFDInitiator can possess multiple types of S-BFD echo packets, with each having varying return paths. In this particular example, the SBFDInitiator can be sending two types of S-BFD echo packets in addition to S-BFD control packets.

<list style="symbols">
<t>S-BFD control packets
  <list style="symbols">
  <t>Segment stack: {B, C, D}</t>
  <t>Return path: D-E-A</t>
  </list></t>
<t>S-BFD echo packets #1
  <list style="symbols">
  <t>Segment stack: {B, C, D, C, A}</t>
  <t>Return path: D-C-B-A</t>
  </list></t>
<t>S-BFD echo packets #2
  <list style="symbols">
  <t>Segment stack: {B, C, D, G, A}</t>
  <t>Return path: D-G-F-A</t>
  </list></t>
</list>

The SBFDInitiator can correlate the result of each packet type to determine the nature of the failure. One such example of failure correlation is described in the figure below.

<figure align="left"><preamble></preamble><artwork align="left"><![CDATA[
  +---+-----------------------------------------------------------+
  |   |                      S-BFD Echo Pkt                       |
  |   +------------------------------------+----------------------+
  |   |              Success               |       Failure        |
  +-+-+------------------------------------+----------------------+
  | |S|                                    |                      |
  |S|u|                                    |                      | 
  |||c|                                    |Forward SID stack good|
  |B|c|             All is well            |Return SID stack bad  |
  |F|e|                                    |Return IP path good   |
  |D|s|                                    |                      | 
  | |s|                                    |                      |
  |C+-+----------------------+-------------+----------------------+
  |t|F|Forward SID stack good|             |                      |
  |r|a|Return SID stack good |Send Alert   |                      |
  |l|i|Return IP path bad    |Discrim S-BFD|                      |
  | |l+--------- OR ---------+w/ Forward   |Forward SID stack bad |
  |P|u|Forward SID stack is  |SID stack to |                      | 
  |k|r|terminating on wrong  |differentiate|                      |
  |t|e|node                  |             |                      |
  +-+-+----------------------+-------------+----------------------+

      Figure 2: SBFDInitiator Failure Correlation Example
]]></artwork></figure>
</t>

</section>

</section>

<section title="S-BFD Echo Recommendations">

<t>
<list style="symbols">

<t>It is RECOMMENDED to compute and use smallest number of segment stack to describe the return path of S-BFD echo packets to prevent the segment stack being too large. How SBFDInitiator determines when to use S-BFD echo packets and how to identify corresponding segment stack for the return paths are outside the scope of this document.</t>

<t>It is RECOMMENDED that SBFDInitiator does not send only S-BFD echo packets. S-BFD echo packets are crafted to traverse the network and to come back to self, thus there is no guarantee that S-BFD echo are u-turning on the intended remote target. On the other hand, S-BFD control packets can verify that segment stack of the forward direction reaches the intended remote target. Therefore, an SBFDInitiator SHOULD send S-BFD control packets when sending S-BFD echo packets.</t>

<t>It is RECOMMENDED that, for Segment Routing on the MPLS data plane, destination IP address of S-BFD echo packets is chosen from the 127/8 range for IPv4 and from the 0:0:0:0:0:FFFF:7F00/104 range for IPv6.</t>

</list>
</t>

</section>

    <section anchor="Security" title="Security Considerations">

<t>Security considerations for S-BFD are discussed in <xref target="I-D.ietf-bfd-seamless-base" /> and <xref target="I-D.akiya-bfd-seamless-ip" />.</t>

    </section>

    <section anchor="IANA" title="IANA Considerations">
     <t>This document does not request any new code points from IANA.</t>
    </section>

    <section title="Acknowledgements">

	<t>Authors would like to thank Marc Binderberger from Cisco Systems for providing valuable comments.</t>

    </section>

    <section title="Contributing Authors">

	<t>Dave Ward
    <vspace blankLines="0" />
	Cisco Systems
    <vspace blankLines="0" />
    Email: wardd@cisco.com</t>

    <t>Tarek Saad
    <vspace blankLines="0" />
	Cisco Systems
    <vspace blankLines="0" />
    Email: tsaad@cisco.com</t>

	<t>Siva Sivabalan
    <vspace blankLines="0" />
	Cisco Systems
    <vspace blankLines="0" />
    Email: msiva@cisco.com</t>

    </section>

  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <references title="Normative References">
	  <?rfc include="reference.RFC.2119"?>
         <?rfc include="reference.I-D.filsfils-spring-segment-routing"?>
         <?rfc include="reference.I-D.ietf-bfd-seamless-base"?>
         <?rfc include="reference.I-D.akiya-bfd-seamless-ip"?>
    </references>

    <references title="Informative References">
         <?rfc include="reference.RFC.5880"?>
    </references>

    <!-- Change Log
v00-a 2013-05-20 Nobo: Initial version
v00-b 2013-05-24 Nobo: Included comments from Carlos/Nagendra
v00-c 2013-05-27 Nobo: Incorporated comments from Marc
v01-a 2013-12-04 Nobo: Minor tweak to keep draft alive
    -->
  </back>
</rfc>