<?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-alert-discrim-00" 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="S-BFD Alert Discrim &amp; Path Trace">
	Seamless Bidirectional Forwarding Detection (S-BFD) Alert Discriminator and BFD Path Tracing
    </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="Dave Ward" initials="D."
            surname="Ward">
      <organization>Cisco Systems</organization>
      <address>
        <email>wardd@cisco.com</email>
      </address>
    </author>

    <date year="2013" />

    <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>alert discriminator</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 specification defines a concept of alert discriminator which operates over Seamless Bidirectional Forwarding Detection (S-BFD). New diagnostic codes, solely to be used together with alert discriminators, are also defined in this specification.</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><xref target="RFC5880" /> defines the use of  Bidirectional Forwarding Detection (BFD) protocol as a fast failure detection mechanism between nodes which are adjacent to each other or multiple hops away. <xref target="RFC5881" /> defines single hop BFD. Specifications such as <xref target="RFC5883" /> and <xref target="RFC5884" /> define multihop BFD.</t>

<t>When multihop BFD, IP based or MPLS based, declares a failure, responsibility of identifying the problematic point in the paths is often left to operators. ICMP echo request/reply (IP ping) <xref target="RFC0792" /> and LSP echo request/reply (LSP ping) <xref target="RFC4379" /> allow for tracing of hops to a specific target, and these are often used, manually or automatically, to attempt to isolate faults. However, when it comes to identifying the problematic point that caused BFD failure, there are couple of issues.

<list style="symbols">

<t>Usage of non-BFD packets can result in them being load balanced differently along the paths, causing those packets to traverse different paths than BFD packets to the target.</t>

<t>BFD is designed with simplicity and low-overhead as goals. Thus implementations often provide more preferable scale/performance capacities over IP/LSP ping, allowing for increased probability to identify short-lived transient issues.</t>

</list>

Above points produced the desire to use BFD to trace hops to a specific target.</t>

<t>This specification defines a generic concept of alert discriminator which operates over Seamless Bidirectional Forwarding Detection (S-BFD) <xref target="I-D.akiya-bfd-seamless-base" />. New diagnostic codes, solely to be used together with alert discriminators, are also defined in this specification. Finally, BFD path tracing is described as one of the use cases of defined mechanism.
</t>

<t>It is worth noting that this specification does not reserve specific BFD discriminator value as the alert discriminator, but only defines the concept of alert discriminators.</t>
 
</section>

<section title="Overview">

<t>A group of network nodes reserves a same BFD discriminator value as the alert discriminator. Alert discriminator operates as a BFD target identifier of alert type (3). A reflector BFD session is then responsible for monitoring incoming BFD control packets with alert discriminator as &quot;your discriminator&quot;. Reflector BFD session, upon reception of BFD control packets with alert discriminator as &quot;your discriminator&quot;, would examine BFD diagnostic code. Diagnostic code instructs how reflector BFD session is to behave. A network node is able to transmit S-BFD control packets with &quot;your discriminator&quot; as this alert discriminator and well known diagnostic code, to a particular target, and expect reflector BFD session on the target network node to behave accordingly.</t>

</section>

<section title="Alert Discriminator">

<t>Alert discriminator is a BFD target identifier of type (3).

<figure align="left"><preamble></preamble><artwork align="left">
    Value    BFD Target Identifier Type
   ------    --------------------------
        3    Alert Discriminator
</artwork></figure>

Uniqueness of alert discriminator is that same BFD discriminator value is reserved on group of network nodes as the alert discriminator.</t>

<t>For example, there are 4 network nodes in a network: A, B, C, D. 0x7F7F7F7F is chosen as the alert discriminator for this network. Nodes A, B, C and D will each reserve 0x7F7F7F7F as BFD target identifier type 3.</t>

<t>How alert discriminator value is to be chosen is outside the scope of this document.</t>

</section>

<section title="Reflector BFD Session">

<t>One or more reflector BFD session(s) MUST be created on each network node which has reserved alert discriminator(s). Reflector BFD session MUST listen for incoming S-BFD control packets with &quot;your discriminator&quot; of BFD target identifier type 3, alert discriminators. Further procedures for a reflector BFD session processing incoming S-BFD control packets for BFD target identifier type 3 depends on specified BFD diagnostic code. Definition of BFD diagnostic code for alert discriminator usage and required reflector BFD session behavior for each are described in <xref target="Diag_Code" />.</t>

</section>

<section title="Alert Discriminator Diagnostic Code" anchor="Diag_Code">

<t><xref target="RFC5880" /> defines a field to describe diagnostic code in a BFD control packet, and defines set of diagnostic codes. This specification defines a new set of diagnostic codes to be used solely for S-BFD control packets using alert discriminators. New diagnostic codes specified in this document are only meaningful when used together with alert discriminators.

<list style="symbols">

<t>S-BFD control packets transmitted and received, destined for BFD target identifier of type 3, MUST NOT use diagnostic codes defined in <xref target="RFC5880" /> and MUST use diagnostic codes defined in this document.</t>

<t>[S-]BFD control packets transmitted and received, not destined for BFD target identifier of type 3, MUST use diagnostic codes defined in <xref target="RFC5880" /> and MUST NOT use diagnostic codes defined in this document.</t>

</list>

Note that BFD diagnostic codes for alert discriminators are defined from highest possible values. Any future documents claiming alert discriminator diagnostic codes MUST use next available highest values from the reserved range. Alert discriminator diagnostic codes are defined as follow:

<figure align="left"><preamble></preamble><artwork align="left">
    Value    Alert Discriminator Diagnostic Code Name
   ------    ----------------------------------------
     0-30    Reserved for future use
       31    BFD path trace
</artwork></figure>

When transmitted BFD control packet is targeted to a BFD target identifier of type 3, then BFD diagnostic code MUST NOT be zero. When receiving BFD control packet is targeted to a BFD target identifier of type 3, then packet with BFD diagnostic code of zero MUST be dropped.</t>

<t>Note that primary purpose of alert discriminator diagnostic codes are to provide hints to responder on why initiator is sending alert discriminator S-BFD packets.</t>

</section>

<section title="BFD Path Trace: Alert Discriminator Diagnostic Code 31">

<t>BFD path trace, aka BFD traceroute, is performed through making use of the alert discriminator with alert discriminator diagnostic code 31.</t>

<section title="Initiator Procedures">

<t>When a network node desires to trace hops to a BFD target, S-BFD control packets are transmitted with following contents.</t>

<section title="Transmission S-BFD Control Packets">

<t>

<list style="symbols">

<t>IP destination address or MPLS label stack MUST be set to describe the target.</t>
<t>&quot;your discriminator&quot; MUST be set to an alert discriminator.</t>
<t>BFD diagnostic code MUST be set to 31 (BFD path trace).</t>
<t>Poll (P) bit MUST be set.</t>
<t>Incrementing or decrementing IP/MPLS TTL.</t>
<t>Remaining packet contents are as per described in <xref target="I-D.akiya-bfd-seamless-ip" />.</t>

</list>

When incrementing TTL is used towards the BFD target, TTL SHOULD start at value of 1. Completion of BFD path trace is reached when locally determined so (ex: no response from one of the nodes) or when one of following conditions are hit, and initiator MUST NOT transmit BFD path trace packets to further downstream network nodes:

<list style="symbols">

<t>Response S-BFD control packet has been received from intended BFD target.</t>
<t>In case IP address(es) of intended BFD target is unknown, two consecutive response S-BFD control packets (TTL+n and TTL+(n+1)) contain same IP source address.</t>

</list>

When decrementing TTL is used, BFD path trace SHOULD start from the BFD target using TTL=N. How value of N is determined is outside the scope of this document. Completion of BFD path trace is reached when locally determined so or after performing BFD path trace operation to TTL=1.</t>

<t>Because there are no sequence numbers included in transmitted and received S-BFD control packets (without use of Authentication) for BFD path tracing, initiator SHOULD allow some delay between multiple BFD path tracing operations for a same target, if same &quot;my discriminator&quot; value is used on them. This is to ensure responses from multiple BFD path tracing operations do not conflict with each other, resulting in incorrectly recorded hops.</t>

</section>

<section title="Reception of S-BFD Control Packets">

<t>If response S-BFD control packets do not contain &quot;my discriminator&quot; of alert discriminator, then packet MUST NOT be considered as response for BFD path tracing.</t>

<t>If response S-BFD control packets do not have Final (F) bit set, then packet MUST NOT be considered as response for BFD path tracing.</t>

<t>If response S-BFD control packets do not contain BFD diagnostic code 31, then packet MUST NOT be considered as response for BFD path tracing.</t>

<t>IP source address of valid response S-BFD control packets are recorded to form trace hops to the BFD target.</t>

</section>

</section>

<section title="Responder Procedures">

<t>Reflector BFD session at the responder network node MUST operate with procedures described in <xref target="I-D.akiya-bfd-seamless-ip" />.</t>

<section title="Reception of S-BFD Control Packets">

<t>Following conditions MUST be met for received S-BFD control packets targeted to BFD target identifier of type 3 to be considered for BFD path tracing:

<list style="symbols">

<t>BFD diagnostic code is 31 (BFD path trace).</t>
<t>Poll (P) bit is set.</t>

</list>
</t>

</section>

<section title="Transmission of S-BFD Control Packets">

<t>Following procedures MUST be followed when transmitting a response S-BFD control packet for BFD path tracing:

<list style="symbols">

<t>BFD diagnostic code in response S-BFD packet MUST be set to 31 (BFD path trace).</t>
<t>Final (F) bit MUST be set.</t>

</list>

</t>

</section>

</section>

<section title="Possible Use Cases">

<t>BFD path tracing may be desirable for following occasions.

<list style="symbols">

<t>When a BFD session is determined to have lost reachability to the target (ex: state transitions from UP to DOWN), immediately trigger BFD path trace to the target to attempt to isolate the fault.</t>

<t>While a particular BFD session is in UP state, occasionally trigger BFD path trace in the background to record the paths. Compare recorded paths to see how frequently paths are changing. If determined to be more frequent than expected, then log a warning to indicate potential network instability.</t>

<t>Just trigger BFD path trace, manually or automatically, as needed basis.</t>

</list>
</t>

</section>

</section>

<section anchor="Security" title="Security Considerations">

<t>Alert discriminator selected for a network should be kept from being disclosed to anybody or anything external to the network. This will prevent attacks from knowing the exact value for the alert discriminator. It is still possible for attacks to scan a range of BFD discriminator values to identify alert discriminator being used. Therefore, as described in <xref target="I-D.akiya-bfd-seamless-base" />, implementations MUST provide filtering capability based on source IP addresses.</t>
 
<t>In addition, same security considerations as <xref target="RFC5880" />, <xref target="RFC5881" />, <xref target="RFC5883" />, <xref target="RFC5884" />, <xref target="I-D.akiya-bfd-seamless-base" /> and <xref target="I-D.akiya-bfd-seamless-ip" /> apply to this document.</t>

</section>

<section anchor="IANA" title="IANA Considerations">
<t>BFD Target Identifier types:

<figure align="left"><preamble></preamble><artwork align="left">
    Value    BFD Target Identifier Type
   ------    --------------------------
        3    Alert Discriminator
</artwork></figure>
</t>

<t>Alert Discriminator Diagnostic Code:

<figure align="left"><preamble></preamble><artwork align="left">
    Value    Alert Discriminator Diagnostic Code Name
   ------    ----------------------------------------
     0-30    Reserved for future use
       31    BFD path trace
</artwork></figure>

</t>

</section>

<section title="Acknowledgements">

<t>TBD</t>

</section>

<section title="Contributing Authors">

	<t>Nagendra Kumar
    <vspace blankLines="0" />
	Cisco Systems
    <vspace blankLines="0" />
    Email: naikumar@cisco.com</t>

	<t>Mallik Mudigonda
    <vspace blankLines="0" />
	Cisco Systems
    <vspace blankLines="0" />
    Email: mmudigon@cisco.com</t>

	<t>Aswatnarayan Raghuram
    <vspace blankLines="0" />
	AT&amp;T
    <vspace blankLines="0" />
    Email: ar2521@att.com</t>

	<t>Glenward D. Hayden
    <vspace blankLines="0" />
	AT&amp;T
    <vspace blankLines="0" />
    Email: gh1691@att.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.RFC.5880"?>
	  <?rfc include="reference.RFC.5881"?>
	  <?rfc include="reference.RFC.5883"?>
	  <?rfc include="reference.RFC.5884"?>
       <?rfc include="reference.I-D.akiya-bfd-seamless-base"?>
       <?rfc include="reference.I-D.akiya-bfd-seamless-ip"?>
    </references>
    
    <references title="Informative References">
       <?rfc include="reference.RFC.0792"?>
       <?rfc include="reference.RFC.4379"?>
    </references>

    <!-- Change Log
v00-a 2013-06-20 Nobo: Initial version
v00-b 2013-06-20 Nobo: Incorporated comments from Dave/Carlos.
v00-c 2013-06-25 Nobo: Added Mallik, Raghu, Glen.
    -->
  </back>
</rfc>
