One document matched: draft-akiya-bfd-seamless-alert-discrim-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-alert-discrim-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="S-BFD Alert Discriminator">
Seamless Bidirectional Forwarding Detection (S-BFD) Alert Discriminator
</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="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>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 document defines the Alert Discriminator which operates on the Seamless Bidirectional Forwarding Detection (S-BFD), and Alert Discriminator Diagnostic Codes which operates on the Alert Discriminator.</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="I-D.ietf-bfd-seamless-base" /> defines the Seamless Bidirectional Forwarding Detection (S-BFD): a simplified mechanism which uses Bidirectional Forwarding Detection (BFD) with large portions of negotiation aspects eliminated.</t>
<t>This document defines the Alert Discriminator which operates on the S-BFD, and the Alert Discriminator Diagnostic Codes which operates on the Alert Discriminator, for extended S-BFD use cases described in <xref target="_AD_USE" />.</t>
</section>
<section title="Extended S-BFD Use Cases" anchor="_AD_USE">
<t>This section describes extended S-BFD use cases.</t>
<section title="Target S-BFD Discriminator Discovery">
<t>IS-IS (<xref target="I-D.ietf-isis-sbfd-discriminator" />) and OSPF (<xref target="I-D.ietf-ospf-sbfd-discriminator" />) protocols have been extended to advertise S-BFD discriminator values. These extensions will suffice for number of scenarios where S-BFD is used to verify the network reachability to other network devices. Other protocols may be extended to support S-BFD in further scenarios.</t>
<t>There are, however, some scenarios where it is desirable to have a mechanism within the S-BFD protocol to discover the target S-BFD discriminator value.
<list style="symbols">
<t>In some scenarios, direct protocol communications are intentionally kept minimal for reasons such as administrative policy. One such example is the usage of S-BFD across Autonomous System (AS) boundaries (i.e. inter-AS).</t>
<t>In some scenarios, there is no control plane which can easily advertise S-BFD discriminators. MPLS-TP and static routes are such examples.</t>
<t>In some scenarios, defining and standardizing protocol extensions to advertise S-BFD discriminator values may be more work than the value it brings.</t>
</list>
To accommodate the two scenarios described, it is desirable to have a mechanism within the S-BFD protocol to discover the target S-BFD discriminator value.
</t>
</section>
<section title="S-BFD Path Tracing">
<t>When a multihop S-BFD session, IP based or MPLS based, determines a loss of reachability to the target entity, the responsibility of identifying the problematic point in the paths is often left to operators. ICMP echo request/reply (IP Ping/Trace) <xref target="RFC0792" /> and MPLS echo request/reply (LSP Ping/Trace) <xref target="RFC4379" /> allow for tracing of hops to a specific target, and these are often used by operators, manually or automatically, to attempt to isolate faults. However, when it comes to identifying the problematic point that caused the S-BFD session to declare the failure, there are couple of issues.
<list style="symbols">
<t>Usage of non-S-BFD packets can result in them being load balanced differently along the paths, causing those packets to traverse different paths than S-BFD packets did.</t>
<t>Usage of non-S-BFD packets may not identify the problematic points which only affect specific flows (which affects S-BFD packets).</t>
<t>In order to isolate short lived transient issues, it is desirable to immediately perform the task of fault isolation. IP/MPLS Ping/Trace implementations often require more processing overhead than S-BFD. Usage of heavier tool to attempt to isolate fault can result in missing more instances of identifying short lived transient issues.</t>
</list>
Although the task of "fault isolation" does not belong in the BFD/S-BFD protocols, if the task of "fault isolation" can be done with simple extensions within the S-BFD protocol, the result does provide additional benefit to operators.
</t>
</section>
</section>
<section title="Alert Discriminator">
<t>This document reserves the value zero of the S-BFD discriminator pool as the Alert Discriminator. A reflector BFD session is to monitor incoming S-BFD packets with value zero in the "Your Discriminator" field. The reflector BFD session is to process the S-BFD packets according to the value specified in the received "Diagnostic" field. Procedures specific to each "Diagnostic" code are described in <xref target="_AD_DIAG" />.</t>
</section>
<section title="Alert Discriminator Diagnostic Codes" anchor="_AD_DIAG">
<t>This section defines the Alert Discriminator Diagnostic Codes, and procedures for each defined code point. The Alert Discriminator Diagnostic Codes MUST operate on the Alert Discriminator. Specifically:
<list style="symbols">
<t>In the direction from an SBFDInitiator to an SBFDReflector, the Alert Discriminator Diagnostic Codes MUST only be used with "Your Discriminator" field set to the Alert Discriminator.</t>
<t>In the direction from an SBFDReflector to an SBFDInitiator, the Alert Discriminator Diagnostic Code MUST only be used in a reply S-BFD packet if received S-BFD packet contained "Your Discriminator" field set to the Alert Discriminator.</t>
</list>
</t>
<section title="Diagnostic Code: Target S-BFD Discriminator Discovery">
<t>The Alert Discriminator Diagnostic Code 29 is defined for the purpose of discovering the target S-BFD discriminator.
<figure align="left"><preamble></preamble><artwork align="left">
Value Alert Discriminator Diagnostic Code Name
------ ----------------------------------------
29 Target S-BFD Discriminator Discovery
</artwork></figure>
When a reflector BFD session receives an S-BFD packet containing the Alert Discriminator and the Alert Discriminator Diagnostic Code of 29, then the reflector BFD session SHOULD send a reply S-BFD packet. The format and the contents of the generated reply S-BFD packet MUST follow the definition in the S-BFD protocol documents, except for following fields:
<list style="symbols">
<t>"My Discriminator" field MUST be set to one of local S-BFD discriminators.</t>
<t>"Diagnostic" field MUST be set to value 29.</t>
</list>
</t>
</section>
<section title="Diagnostic Code: S-BFD Path Tracing">
<t>The Alert Discriminator Diagnostic Code 30 is defined for the purpose of S-BFD path tracing.
<figure align="left"><preamble></preamble><artwork align="left">
Value Alert Discriminator Diagnostic Code Name
------ ----------------------------------------
30 S-BFD Path Trace
</artwork></figure>
When a reflector BFD session receives an S-BFD packet containing the Alert Discriminator and the Alert Discriminator Diagnostic Code of 30, then the reflector BFD session SHOULD send a reply S-BFD packet. The format and the contents of the generated reply S-BFD packet MUST follow the definition in the S-BFD protocol documents, except for following fields:
<list style="symbols">
<t>"My Discriminator" field MUST be set to zero.</t>
<t>"Diagnostic" field MUST be set to value 30.</t>
</list>
</t>
</section>
<section title="Diagnostic Code: Not Supported">
<t>The Alert Discriminator Diagnostic Code 31 is defined for a reflector BFD session to communicate, in reply S-BFD packet, that specified Alert Discriminator Diagnostic Code in received S-BFD packet is not understood or is not supported.
<figure align="left"><preamble></preamble><artwork align="left">
Value Alert Discriminator Diagnostic Code Name
------ ----------------------------------------
31 Not Supported
</artwork></figure>
When a reflector BFD session receives an S-BFD packet containing the Alert Discriminator and an Alert Discriminator Diagnostic Code which is not understood or supported by the reflector BFD session, then the reflector BFD session SHOULD send a reply S-BFD packet. The format and the contents of the generated reply S-BFD packet MUST follow the definition in the S-BFD protocol documents, except for following fields:
<list style="symbols">
<t>"My Discriminator" field MUST be set to zero.</t>
<t>"Diagnostic" field MUST be set to value 31.</t>
</list>
Note that in the direction from an SBFDInitiator to an SBFDReflector, the Alert Discriminator Diagnostic Code 31 MUST NOT be used. If a reflector BFD session receives an S-BFD packet with the Alert Discriminator and the Alert Discriminator Diagnostic Code 31, then the reflector BFD session MUST drop the packet.
</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>Conceptually the Alert Discriminator is similar to an IP Router Alert Option or an MPLS Router Alert Label. The Alert Discriminator introduces a way which remote network devices can instruct a reflector BFD sessions to perform specific tasks corresponding to specified Alert Discriminator Diagnostic Codes, and without remote network devices knowing a valid S-BFD discriminator on the target device. Hence, it is very critical that reflector BFD session services the Alert Discriminator only from trusted sources and for allowed Alert Diagnostic Codes for those sources. Therefore, this document RECOMMENDS following security procedures to be implemented:
<list style="symbols">
<t>S-BFD packets with Alert Discriminator is accepted only from trusted sources. An implementation SHOULD provide a mechanism for operators to specify an access-list to describe the trusted sources.</t>
<t>An implementation SHOULD provide a mechanism for operators to specify the Alert Discriminator Diagnostic Codes which are supported on the device. If required, such configuration should be set per a trusted source.</t>
</list>
Additionally, it is RECOMMENDED that implementations supporting the Alert Discriminator considers the security considerations described in <xref target="I-D.ietf-bfd-seamless-base" />, <xref target="I-D.ietf-bfd-seamless-ip" /> and <xref target="I-D.akiya-bfd-seamless-sr" /> documents.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document requests IANA to create a new registry within <xref target="IANA-BFD" /> protocol to maintain "Alert Discriminator Diagnostic Codes" field. Initial values are described in immediate sub-section to follow.</t>
<section title="Alert Discriminator Diagnostic Codes Registry">
<t>The IANA is requested to create and maintain a registry entitled "Alert Discriminator Diagnostic Codes" with the following registration procedures:
<figure align="left"><preamble></preamble><artwork align="left">
Registry Name: Alert Discriminator Diagnostic Codes
Value Alert Discriminator Diagnostic Code Name Reference
------ ---------------------------------------- -------------
0-7 Experimental This document
8-28 Reserved This document
29 Target S-BFD Discriminator Discovery This document
30 S-BFD Path Trace This document
31 Not Supported This document
</artwork></figure>
Assignments of Alert Discriminator Diagnostic Codes are via Standards Action <xref target="RFC5226" />.
</t>
</section>
</section>
<section title="Acknowledgements">
<t>Authors would like to thank Srihari Raghavan and Girija Raghavendra Rao for reviewing and providing comments on this document.</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&T
<vspace blankLines="0" />
Email: ar2521@att.com</t>
<t>Glenward D. Hayden
<vspace blankLines="0" />
AT&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.I-D.ietf-bfd-seamless-base"?>
<?rfc include="reference.I-D.ietf-bfd-seamless-ip"?>
<?rfc include="reference.I-D.akiya-bfd-seamless-sr"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.0792"?>
<?rfc include="reference.RFC.4379"?>
<?rfc include="reference.RFC.5226"?>
<?rfc include="reference.I-D.ietf-isis-sbfd-discriminator"?>
<?rfc include="reference.I-D.ietf-ospf-sbfd-discriminator"?>
<reference anchor="IANA-BFD" target="http://www.iana.org/assignments/bfd-parameters/bfd-parameters.xhtml">
<front>
<title>Bidirectional Forwarding Detection (BFD) Parameters</title>
<author><organization>IANA</organization></author>
<date/>
</front>
</reference>
</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>
| PAFTECH AB 2003-2026 | 2026-04-24 01:53:16 |