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

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-idr-bgp-ls-sbfd-extensions-10" 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">


  <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"/>
    <author fullname="Zhenbin Li" initials="Z. " surname="Li">
      <organization>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>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>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>
      <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="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 S-BFD Discriminators.</t>
      <t>This document defines extensions to the BGP - Link State (BGP-LS) address family
      to carry the S-BFD Discriminators' information via BGP.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="INTRO" numbered="true" toc="default">
      <name>Introduction</name>
      <t>Seamless Bidirectional Forwarding Detection (S-BFD) <xref target="RFC7880" format="default"/> defines a simplified mechanism to use Bidirectional
      Forwarding Detection (BFD) <xref 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 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"/> and OSPF
      <xref target="RFC7884" format="default"/>) 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>BGP - Link State (BGP-LS) <xref 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) 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>This document defines extensions to BGP-LS for carrying the S-BFD
      Discriminators' information.</t>
    </section>
    <section anchor="TERM" numbered="true" toc="default">
      <name>Terminology</name>
      <t>This memo makes use of the terms defined in <xref target="RFC7880" format="default"/>.</t>
      <section numbered="true" toc="default">
        <name>Requirements Language</name>



        <t>
    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&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
        </t>


      </section>
    </section>
    <section anchor="SBFDDISC" numbered="true" toc="default">
      <name>BGP-LS Extensions for S-BFD Discriminators</name>
      <t>BGP-LS <xref 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 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 "S-BFD
      Discriminators TLV", and its format is as follows:</t>
<figure title="S-BFD Discriminators TLV ">
      <artwork 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)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>where:
</t>

<dl>

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

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

 <dt>Discriminator n:
</dt>
<dd>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>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">
        <li>IS-IS, as defined by the S-BFD Discriminators sub-TLV in <xref target="RFC7883" format="default"/>.</li>
        <li>OSPFv2/OSPFv3, as defined by the S-BFD Discriminator TLV in <xref target="RFC7884"                       
format="default"/>.</li>
      </ul>

</section>
    <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>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> 
  <name>S-BFD Discriminators TLV 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" 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" format="default"/>. 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"/>) of <xref target="RFC7752" format="default"/>.     Specifically, the malformed NLRIs attribute tests in
      "Fault Management" (Section <xref target="RFC7752"
      section="6.2.2" sectionFormat="bare"/>) of <xref target="RFC7752" format="default"/> now encompass
      the new TLV for the BGP-LS NLRI in this document.</t>
    </section>
    <section anchor="Security" 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" format="default"/>. 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"/>) of <xref 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
      information (see <xref target="RFC7883" format="default"/> and <xref 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" format="default"/> and <xref 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" 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" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>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>

  </back>
</rfc>
