<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-idr-bgp-ls-sbfd-extensions-10" indexInclude="true" ipr="trust200902" number="9247" prepTime="2022-06-23T11:15:48" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-sbfd-extensions-10" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9247" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="BGP-LS Extensions for S-BFD">BGP - Link State (BGP-LS) Extensions for Seamless Bidirectional Forwarding Detection (S-BFD)</title>
    <seriesInfo name="RFC" value="9247" stream="IETF"/>
    <author fullname="Zhenbin Li" initials="Z." surname="Li">
      <organization showOnFrontPage="true">Huawei</organization>
      <address>
        <postal>
          <extaddr>Huawei Bld.</extaddr>
          <street>No.156 Beiqing Rd.</street>
          <city>Beijing</city>
          <code>100095</code>
          <country>China</country>
        </postal>
        <email>lizhenbin@huawei.com</email>
      </address>
    </author>
    <author fullname="Shunwan Zhuang" initials="S." surname="Zhuang">
      <organization showOnFrontPage="true">Huawei</organization>
      <address>
        <postal>
          <extaddr>Huawei Bld.</extaddr>
          <street>No.156 Beiqing Rd.</street>
          <city>Beijing</city>
          <code>100095</code>
          <country>China</country>
        </postal>
        <email>zhuangshunwan@huawei.com</email>
      </address>
    </author>
    <author fullname="Ketan Talaulikar" initials="K." role="editor" surname="Talaulikar">
      <organization showOnFrontPage="true">Arrcus, Inc.</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <code/>
          <country>India</country>
        </postal>
        <email>ketant.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Sam Aldrin" initials="S." surname="Aldrin">
      <organization showOnFrontPage="true">Google, Inc.</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <code/>
          <country/>
        </postal>
        <email>aldrin.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Jeff Tantsura" initials="J." surname="Tantsura">
      <organization showOnFrontPage="true">Microsoft</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <code/>
          <country/>
        </postal>
        <email>jefftant.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Greg Mirsky" initials="G." surname="Mirsky">
      <organization showOnFrontPage="true">Ericsson</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <code/>
          <country/>
        </postal>
        <email>gregimirsky@gmail.com</email>
      </address>
    </author>
    <date month="06" year="2022"/>
    <area>rtg</area>
    <workgroup>idr</workgroup>
    <keyword>BGP-LS</keyword>
    <keyword>BFD</keyword>
    <keyword>IS-IS</keyword>
    <keyword>OSPF</keyword>
    <keyword>OSPFv3</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">Seamless Bidirectional Forwarding Detection (S-BFD) defines a
      simplified mechanism to use Bidirectional Forwarding Detection (BFD)
      with large portions of negotiation aspects eliminated, thus providing
      benefits such as quick provisioning as well as improved control and
      flexibility to network nodes initiating the path monitoring. The
      link-state routing protocols (IS-IS and OSPF) have been extended to
      advertise the S-BFD Discriminators.</t>
      <t indent="0" pn="section-abstract-2">This document defines extensions to the BGP - Link State (BGP-LS) address family
      to carry the S-BFD Discriminators' information via BGP.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9247" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2022 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-bgp-ls-extensions-for-s-bfd">BGP-LS Extensions for S-BFD Discriminators</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-manageability-consideration">Manageability Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="INTRO" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">Seamless Bidirectional Forwarding Detection (S-BFD) <xref target="RFC7880" format="default" sectionFormat="of" derivedContent="RFC7880"/> defines a simplified mechanism to use Bidirectional
      Forwarding Detection (BFD) <xref target="RFC5880" format="default" sectionFormat="of" derivedContent="RFC5880"/> with large portions
      of negotiation aspects eliminated, thus providing benefits such as quick
      provisioning as well as improved control and flexibility to network
      nodes initiating the path monitoring.</t>
      <t indent="0" pn="section-1-2">For the monitoring of a service path end to end via S-BFD, the headend
      node (i.e., Initiator) needs to know the S-BFD Discriminator of the
      destination/tail-end node (i.e., Responder) of that service. The
      link-state routing protocols (IS-IS <xref target="RFC7883" format="default" sectionFormat="of" derivedContent="RFC7883"/> and OSPF
      <xref target="RFC7884" format="default" sectionFormat="of" derivedContent="RFC7884"/>) have been extended to advertise the S-BFD
      Discriminators. With this, an Initiator can learn the S-BFD
      Discriminator for all Responders within its IGP area/level or
      optionally within the domain. With networks being divided into multiple
      IGP domains for scaling and operational considerations, the service
      endpoints that require end-to-end S-BFD monitoring often span across IGP
      domains.</t>
      <t indent="0" pn="section-1-3">BGP - Link State (BGP-LS) <xref target="RFC7752" format="default" sectionFormat="of" derivedContent="RFC7752"/> enables the
      collection and distribution of IGP link-state topology information via
      BGP sessions across IGP areas/levels and domains. The S-BFD
      Discriminator(s) of a node can thus be distributed along with the
      topology information via BGP-LS across IGP domains and even across
      multiple Autonomous Systems (ASes) within an administrative domain.</t>
      <t indent="0" pn="section-1-4">This document defines extensions to BGP-LS for carrying the S-BFD
      Discriminators' information.</t>
    </section>
    <section anchor="TERM" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-2-1">This memo makes use of the terms defined in <xref target="RFC7880" format="default" sectionFormat="of" derivedContent="RFC7880"/>.</t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-2.1">
        <name slugifiedName="name-requirements-language">Requirements Language</name>
        <t indent="0" pn="section-2.1-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
        </t>
      </section>
    </section>
    <section anchor="SBFDDISC" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-bgp-ls-extensions-for-s-bfd">BGP-LS Extensions for S-BFD Discriminators</name>
      <t indent="0" pn="section-3-1">BGP-LS <xref target="RFC7752" format="default" sectionFormat="of" derivedContent="RFC7752"/> specifies the Node Network Layer
      Reachability Information (NLRI) for the advertisement of nodes and their
      attributes using the BGP-LS Attribute. The S-BFD Discriminators of a
      node are considered a node-level attribute and are advertised as such.</t>
      <t indent="0" pn="section-3-2">This document defines a new BGP-LS Attribute TLV called "S-BFD
      Discriminators TLV", and its format is as follows:</t>
      <figure align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-s-bfd-discriminators-tlv">S-BFD Discriminators TLV</name>
        <artwork align="center" name="" type="" alt="" pn="section-3-3.1">
 0                   1                   2                   3   
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Type             |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Discriminator 1                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Discriminator 2 (Optional)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               ...                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Discriminator n (Optional)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
      </figure>
      <t indent="0" pn="section-3-4">where:
</t>
      <dl indent="3" newline="false" spacing="normal" pn="section-3-5">
        <dt pn="section-3-5.1">Type:
</dt>
        <dd pn="section-3-5.2">1032
</dd>
        <dt pn="section-3-5.3">Length:
</dt>
        <dd pn="section-3-5.4">variable. It <bcp14>MUST</bcp14> be a minimum of 4 octets, and it increments
by 4 octets for each additional discriminator.
</dd>
        <dt pn="section-3-5.5">Discriminator n:
</dt>
        <dd pn="section-3-5.6">4 octets each, carrying an S-BFD local discriminator value of the node. At
least one discriminator <bcp14>MUST</bcp14> be included in the TLV.
</dd>
      </dl>
      <t indent="0" pn="section-3-6">The S-BFD Discriminators TLV can be added to the BGP-LS Attribute                                           
      associated with the Node NLRI that originates the corresponding                                                
      underlying IGP TLV/sub-TLV as described below. This information is                                             
      derived from the protocol-specific advertisements as follows:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-7">
        <li pn="section-3-7.1">IS-IS, as defined by the S-BFD Discriminators sub-TLV in <xref target="RFC7883" format="default" sectionFormat="of" derivedContent="RFC7883"/>.</li>
        <li pn="section-3-7.2">OSPFv2/OSPFv3, as defined by the S-BFD Discriminator TLV in <xref target="RFC7884" format="default" sectionFormat="of" derivedContent="RFC7884"/>.</li>
      </ul>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-4-1">IANA has permanently allocated the following code point
      in the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor,
      and Attribute TLVs" registry. The column "IS-IS TLV/Sub-TLV" defined in
      the registry does not require any value and should be left empty.</t>
      <table align="center" pn="table-1">
        <name slugifiedName="name-s-bfd-discriminators-tlv-co">S-BFD Discriminators TLV Code Point Allocation</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">TLV Code Point</th>
            <th align="left" colspan="1" rowspan="1">Description</th>
            <th align="left" colspan="1" rowspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">1032</td>
            <td align="left" colspan="1" rowspan="1">S-BFD Discriminators</td>
            <td align="left" colspan="1" rowspan="1">This document</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="Manageability" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-manageability-consideration">Manageability Considerations</name>
      <t indent="0" pn="section-5-1">The new protocol extensions introduced in this document augment the
      existing IGP topology information that was distributed via BGP-LS <xref target="RFC7752" format="default" sectionFormat="of" derivedContent="RFC7752"/>. Procedures and protocol extensions defined in this
      document do not affect BGP protocol operations and management other
      than as discussed in "Manageability Considerations" (Section <xref target="RFC7752" section="6" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7752#section-6" derivedContent="RFC7752"/>) of <xref target="RFC7752" format="default" sectionFormat="of" derivedContent="RFC7752"/>.     Specifically, the malformed NLRIs attribute tests in
      "Fault Management" (Section <xref target="RFC7752" section="6.2.2" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7752#section-6.2.2" derivedContent="RFC7752"/>) of <xref target="RFC7752" format="default" sectionFormat="of" derivedContent="RFC7752"/> now encompass
      the new TLV for the BGP-LS NLRI in this document.</t>
    </section>
    <section anchor="Security" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-6-1">The new protocol extensions introduced in this document augment the
      existing IGP topology information that can be distributed via BGP-LS
      <xref target="RFC7752" format="default" sectionFormat="of" derivedContent="RFC7752"/>. Procedures and protocol extensions defined in
      this document do not affect the BGP security model other than as
      discussed in "Security Considerations" (Section <xref target="RFC7752" section="8" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7752#section-8" derivedContent="RFC7752"/>) of <xref target="RFC7752" format="default" sectionFormat="of" derivedContent="RFC7752"/>, i.e., the aspects related to limiting
      the nodes and consumers with which the topology information is shared
      via BGP-LS to trusted entities within an administrative domain.</t>
      <t indent="0" pn="section-6-2">The TLV introduced in this document is used to propagate IGP-defined
      information (see <xref target="RFC7883" format="default" sectionFormat="of" derivedContent="RFC7883"/> and <xref target="RFC7884" format="default" sectionFormat="of" derivedContent="RFC7884"/>). The
      TLV represents information used to set up S-BFD sessions. The IGP
      instances originating this information are assumed to support any
      required security and authentication mechanisms (as described in <xref target="RFC7883" format="default" sectionFormat="of" derivedContent="RFC7883"/> and <xref target="RFC7884" format="default" sectionFormat="of" derivedContent="RFC7884"/>).</t>
      <t indent="0" pn="section-6-3">Advertising the S-BFD Discriminators via BGP-LS makes it possible for
      attackers to initiate S-BFD sessions using the advertised information.
      The vulnerabilities this poses and how to mitigate them are discussed in
      <xref target="RFC7880" format="default" sectionFormat="of" derivedContent="RFC7880"/>.</t>
    </section>
  </middle>
  <back>
    <references pn="section-7">
      <name slugifiedName="name-references">References</name>
      <references pn="section-7.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC7752" target="https://www.rfc-editor.org/info/rfc7752" quoteTitle="true" derivedAnchor="RFC7752">
          <front>
            <title>North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP</title>
            <author initials="H." surname="Gredler" fullname="H. Gredler" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Medved" fullname="J. Medved">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Previdi" fullname="S. Previdi">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Farrel" fullname="A. Farrel">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Ray" fullname="S. Ray">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="March"/>
            <abstract>
              <t indent="0">In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including Traffic Engineering (TE) information.  This is information typically distributed by IGP routing protocols within the network.</t>
              <t indent="0">This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol.  This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format.  The mechanism is applicable to physical and virtual IGP links.  The mechanism described is subject to policy control.</t>
              <t indent="0">Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7752"/>
          <seriesInfo name="DOI" value="10.17487/RFC7752"/>
        </reference>
        <reference anchor="RFC7880" target="https://www.rfc-editor.org/info/rfc7880" quoteTitle="true" derivedAnchor="RFC7880">
          <front>
            <title>Seamless Bidirectional Forwarding Detection (S-BFD)</title>
            <author initials="C." surname="Pignataro" fullname="C. Pignataro">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Ward" fullname="D. Ward">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N." surname="Akiya" fullname="N. Akiya">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Bhatia" fullname="M. Bhatia">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Pallagatti" fullname="S. Pallagatti">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="July"/>
            <abstract>
              <t indent="0">This document defines Seamless Bidirectional Forwarding Detection (S-BFD), a simplified mechanism for using BFD with a large proportion of negotiation aspects eliminated, thus providing benefits such as quick provisioning, as well as improved control and flexibility for network nodes initiating path monitoring.</t>
              <t indent="0">This document updates RFC 5880.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7880"/>
          <seriesInfo name="DOI" value="10.17487/RFC7880"/>
        </reference>
        <reference anchor="RFC7883" target="https://www.rfc-editor.org/info/rfc7883" quoteTitle="true" derivedAnchor="RFC7883">
          <front>
            <title>Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in IS-IS</title>
            <author initials="L." surname="Ginsberg" fullname="L. Ginsberg">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N." surname="Akiya" fullname="N. Akiya">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Chen" fullname="M. Chen">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="July"/>
            <abstract>
              <t indent="0">This document defines a means of advertising one or more Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators using the IS-IS Router CAPABILITY TLV.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7883"/>
          <seriesInfo name="DOI" value="10.17487/RFC7883"/>
        </reference>
        <reference anchor="RFC7884" target="https://www.rfc-editor.org/info/rfc7884" quoteTitle="true" derivedAnchor="RFC7884">
          <front>
            <title>OSPF Extensions to Advertise Seamless Bidirectional Forwarding Detection (S-BFD) Target Discriminators</title>
            <author initials="C." surname="Pignataro" fullname="C. Pignataro">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Bhatia" fullname="M. Bhatia">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Aldrin" fullname="S. Aldrin">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Ranganath" fullname="T. Ranganath">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="July"/>
            <abstract>
              <t indent="0">This document defines a new OSPF Router Information (RI) TLV that allows OSPF routers to flood the Seamless Bidirectional Forwarding Detection (S-BFD) Discriminator values associated with a target network identifier.  This mechanism is applicable to both OSPFv2 and OSPFv3.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7884"/>
          <seriesInfo name="DOI" value="10.17487/RFC7884"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references pn="section-7.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC5880" target="https://www.rfc-editor.org/info/rfc5880" quoteTitle="true" derivedAnchor="RFC5880">
          <front>
            <title>Bidirectional Forwarding Detection (BFD)</title>
            <author initials="D." surname="Katz" fullname="D. Katz">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Ward" fullname="D. Ward">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="June"/>
            <abstract>
              <t indent="0">This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency.  It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5880"/>
          <seriesInfo name="DOI" value="10.17487/RFC5880"/>
        </reference>
      </references>
    </references>
    <section anchor="Acknowledgements" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">The authors would like to thank <contact fullname="Nan Wu"/> for his
      contributions to this work. The authors would also like to thank
      <contact fullname="Gunter Van de Velde"/> and <contact fullname="Thomas       Fossati"/> for their reviews as well as
      <contact fullname="Jeff Haas"/> for his shepherd review and <contact fullname="Alvaro Retana"/> for his AD review of this document.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Zhenbin Li" initials="Z." surname="Li">
        <organization showOnFrontPage="true">Huawei</organization>
        <address>
          <postal>
            <extaddr>Huawei Bld.</extaddr>
            <street>No.156 Beiqing Rd.</street>
            <city>Beijing</city>
            <code>100095</code>
            <country>China</country>
          </postal>
          <email>lizhenbin@huawei.com</email>
        </address>
      </author>
      <author fullname="Shunwan Zhuang" initials="S." surname="Zhuang">
        <organization showOnFrontPage="true">Huawei</organization>
        <address>
          <postal>
            <extaddr>Huawei Bld.</extaddr>
            <street>No.156 Beiqing Rd.</street>
            <city>Beijing</city>
            <code>100095</code>
            <country>China</country>
          </postal>
          <email>zhuangshunwan@huawei.com</email>
        </address>
      </author>
      <author fullname="Ketan Talaulikar" initials="K." role="editor" surname="Talaulikar">
        <organization showOnFrontPage="true">Arrcus, Inc.</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <code/>
            <country>India</country>
          </postal>
          <email>ketant.ietf@gmail.com</email>
        </address>
      </author>
      <author fullname="Sam Aldrin" initials="S." surname="Aldrin">
        <organization showOnFrontPage="true">Google, Inc.</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <code/>
            <country/>
          </postal>
          <email>aldrin.ietf@gmail.com</email>
        </address>
      </author>
      <author fullname="Jeff Tantsura" initials="J." surname="Tantsura">
        <organization showOnFrontPage="true">Microsoft</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <code/>
            <country/>
          </postal>
          <email>jefftant.ietf@gmail.com</email>
        </address>
      </author>
      <author fullname="Greg Mirsky" initials="G." surname="Mirsky">
        <organization showOnFrontPage="true">Ericsson</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <code/>
            <country/>
          </postal>
          <email>gregimirsky@gmail.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
