<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc category="std" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-idr-bgp-ls-sbfd-extensions-10"
     ipr="trust200902"> number="9247" submissionType="IETF" category="std" consensus="true" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.12.6 -->

<!-- [rfced] Please note that the title has been updated as
follows. The abbreviation has been expanded per Section 3.6 of
RFC 7322 ("RFC Style Guide"), and "BGP Link-State" has been
updated to "BGP - Link State (BGP-LS)" per standard usage in past
RFCs.

Also, since "Seamless" BFD is used, we updated the acronym to "S-BFD".
If that is not correct, please let us know.

Original:
   BGP Link-State Extensions for Seamless BFD

Current:
   BGP - Link State (BGP-LS) Extensions for Seamless
   Bidirectional Forwarding Detection (S-BFD)
 -->
  <front>
    <title abbrev="BGP-LS Extensions for S-BFD">BGP Link-State - Link State (BGP-LS) Extensions for
    Seamless BFD</title> Bidirectional Forwarding Detection (S-BFD)</title>
    <seriesInfo name="RFC" value="9247"/>
    <author fullname="Zhenbin Li" initials="Z. " surname="Li">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>Huawei Bld., No.156
	  <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>Huawei</organization>
      <address>
        <postal>
          <street>Huawei Bld., No.156
	  <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>Arrcus Inc</organization>
      <organization>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>Google, Inc</organization> 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>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>Ericsson</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <code/>
          <country/>
        </postal>
        <email>gregimirsky@gmail.com</email>
      </address>
    </author>
    <date year=""/>

    <area>Routing</area>

    <workgroup>Inter-Domain Routing</workgroup> year="2022" month="June" />

    <area>rtg</area>
    <workgroup>idr</workgroup>

    <keyword>BGP-LS</keyword>
    <keyword>BFD</keyword>
    <keyword>IS-IS</keyword>
    <keyword>OSPF</keyword>
    <keyword>OSPFv3</keyword>
    <abstract>
      <t>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 Seamless BFD (S-BFD) S-BFD Discriminators.</t>
      <t>This document defines extensions to the BGP Link-state address-family - Link State (BGP-LS) address family
      to carry the S-BFD Discriminators' information via BGP.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="INTRO" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>Seamless Bidirectional Forwarding Detection (S-BFD) <xref
      target="RFC7880"/> target="RFC7880" format="default"/> defines a simplified mechanism to use Bidirectional
      Forwarding Detection (BFD) <xref target="RFC5880"/> target="RFC5880" format="default"/> 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>For the monitoring of a service path end-to-end end to end via S-BFD, the headend
      node (i.e. (i.e., Initiator) needs to know the S-BFD Discriminator of the
      destination/tail-end node (i.e. (i.e., Responder) of that service. The
      link-state routing protocols (IS-IS <xref target="RFC7883"/> target="RFC7883" format="default"/> and OSPF
      <xref target="RFC7884"/>) target="RFC7884" format="default"/>) have been extended to advertise the S-BFD
      Discriminators. With this, an Initiator can learn the S-BFD
      discriminator
      Discriminator for all Responders within its IGP area/level, 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 end-to-end S-BFD monitoring often span across IGP
      domains.</t>
      <t>BGP Link-State - Link State (BGP-LS) <xref target="RFC7752"/> target="RFC7752" format="default"/> 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)
      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 (AS) (ASes) within an administrative domain.</t>
      <t>This document defines extensions to BGP-LS for carrying the S-BFD
      Discriminators
      Discriminators' information.</t>
    </section>
    <section anchor="TERM" title="Terminology"> numbered="true" toc="default">
      <name>Terminology</name>
      <t>This memo makes use of the terms defined in <xref
      target="RFC7880"/>.</t> target="RFC7880" format="default"/>.</t>
      <section title="Requirements Language">
        <t>The numbered="true" toc="default">
        <name>Requirements Language</name>

        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<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
        "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP
        14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>

      </section>
    </section>
    <section anchor="SBFDDISC"
             title="BGP-LS numbered="true" toc="default">
      <name>BGP-LS Extensions for S-BFD Discriminator"> Discriminators</name>
      <t>BGP-LS <xref target="RFC7752"/> target="RFC7752" format="default"/> 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 Discriminators of a
      node are considered a node-level attribute and are advertised as such.</t>
      <t>This document defines a new BGP-LS Attribute TLV called the S-BFD "S-BFD
      Discriminators TLV TLV", and its format is as follows:</t>

      <t><figure>
<figure title="S-BFD Discriminators TLV ">
      <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
 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)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 1: S-BFD Discriminators TLV

where:
]]></artwork>
        </figure><list style="symbols">
          <t>Type: 1032</t>

          <t>Length: variable.
</figure>
<t>where:
</t>

<dl>

 <dt>Type:
</dt>
<dd>1032
</dd>

 <dt>Length:
</dt>
<dd>variable. It MUST <bcp14>MUST</bcp14> be a minimum of 4 octets octets, and it increments
by 4 octets for each additional discriminator.</t>

          <t>Discriminator discriminator.
</dd>

 <dt>Discriminator n: 4
</dt>
<dd>4 octets each, carrying an S-BFD local discriminator value of the node. At
least one discriminator MUST <bcp14>MUST</bcp14> be included in the TLV.</t>
        </list></t> TLV.
</dd>

</dl>

 <t>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 protocol-specific advertisements as follows:<list
          style="symbols">
          <t>IS-IS, follows:</t>
      <ul spacing="normal">
        <li>IS-IS, as defined by the S-BFD Discriminators sub-TLV in <xref
          target="RFC7883"/>.</t>

          <t>OSPFv2/OSPFv3, target="RFC7883" format="default"/>.</li>
        <li>OSPFv2/OSPFv3, as defined by the S-BFD Discriminator TLV in <xref
          target="RFC7884"/>.</t>
        </list></t> target="RFC7884"
format="default"/>.</li>
      </ul>

</section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA is requested to has permanently allocate allocated the following code-point
      from 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>

      <figure>
        <artwork align="center"><![CDATA[
+------------+--------------------------+---------------+
| Code Point | Description              | Reference     |
+------------+--------------------------+---------------+
|   1032     | S-BFD Discriminators TLV | This document |
+---------------+--------------------------+------------+

<!--[rfced] FYI: per IANA's note, the authors have agreed to remove
"TLV" from the description in Table 1: S-BFD 1 to match the IANA registry;
this change is now reflected.
-->

<table>
  <name>S-BFD Discriminators TLV Code-Point Allocation

]]></artwork>
      </figure> Code Point Allocation</name>
  <thead>
    <tr>
      <th>TLV Code Point</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>1032</td>
      <td>S-BFD Discriminators</td>
      <td>This document</td>
    </tr>
  </tbody>
</table>

</section>
    <section anchor="Manageability" title="Manageability Considerations"> numbered="true" toc="default">
      <name>Manageability Considerations</name>
      <t>The new protocol extensions introduced in this document augment the
      existing IGP topology information that was distributed via BGP-LS <xref
      target="RFC7752"/>. target="RFC7752" format="default"/>. Procedures and protocol extensions defined in this
      document do not affect the BGP protocol operations and management other
      than as discussed in the Manageability Considerations section "Manageability Considerations" (Section <xref target="RFC7752"
      section="6" sectionFormat="bare"/>) of <xref
      target="RFC7752"/>. target="RFC7752" format="default"/>.     Specifically, the malformed NLRIs attribute tests in
      the Fault Management section
      "Fault Management" (Section <xref target="RFC7752"
      section="6.2.2" sectionFormat="bare"/>) of <xref target="RFC7752"/> target="RFC7752" format="default"/> now encompass
      the new TLV for the BGP-LS NLRI in this document.</t>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The new protocol extensions introduced in this document augment the
      existing IGP topology information that can be distributed via BGP-LS
      <xref target="RFC7752"/>. target="RFC7752" format="default"/>. Procedures and protocol extensions defined in
      this document do not affect the BGP security model other than as
      discussed in the Security Considerations section "Security Considerations" (Section <xref target="RFC7752"
      section="8" sectionFormat="bare"/>) of <xref
      target="RFC7752"/>. More specifically, target="RFC7752" format="default"/>, 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>The TLV introduced in this document is used to propagate IGP defined IGP-defined
      information (<xref target="RFC7883"/> (see <xref target="RFC7883" format="default"/> and <xref target="RFC7884"/>). target="RFC7884" format="default"/>). 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"/> target="RFC7883" format="default"/> and <xref target="RFC7884"/>).</t> target="RFC7884" format="default"/>).</t>
      <t>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"/>.</t> target="RFC7880" format="default"/>.</t>
    </section>

  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7752.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7880.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7883.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7884.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml"/>
      </references>
    </references>

        <section anchor="Acknowledgements" title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors would like to thank Nan Wu <contact fullname="Nan Wu"/> for his
      contributions to this work. The authors would also like to thank Gunter
      <contact fullname="Gunter Van De Velde de Velde"/> and
      Thomas Fossati <contact fullname="Thomas
      Fossati"/> for their reviews. The authors would also like to thank
      Jeff Haas reviews as well as
      <contact fullname="Jeff Haas"/> for his shepherd review and Alvaro Retana <contact
      fullname="Alvaro Retana"/> for his AD review of this document.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include='reference.RFC.7752'?>

      <?rfc include='reference.RFC.7880'?>

      <?rfc include='reference.RFC.7883'?>

      <?rfc include='reference.RFC.7884'?>

      <?rfc include='reference.RFC.8174'?>
    </references>

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

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.

Note that we did not find any words that might require consideration, but this
should still be reviewed as a best practice.
-->

  </back>
</rfc>