<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" docName="draft-ietf-bier-idr-extensions-19" number="9793" ipr="trust200902" consensus="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" prepTime="2025-06-13T10:28:40" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-bier-idr-extensions-19" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9793" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="BGP Extensions for BIER">BGP Extensions for Bit Index Explicit Replication (BIER)</title>
    <seriesInfo name="RFC" value="9793" stream="IETF"/>
    <author fullname="Xiaohu Xu" initials="X." surname="Xu">
      <organization showOnFrontPage="true">China Mobile</organization>
      <address>
        <email>xuxiaohu@cmss.chinamobile.com</email>
      </address>
    </author>
    <author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen">
      <organization showOnFrontPage="true">Huawei</organization>
      <address>
        <email>mach.chen@huawei.com</email>
      </address>
    </author>
    <author fullname="Keyur Patel" initials="K." surname="Patel">
      <organization showOnFrontPage="true">Arrcus, Inc.</organization>
      <address>
        <email>keyur@arrcus.com</email>
      </address>
    </author>
    <author fullname="IJsbrand Wijnands" initials="IJ." surname="Wijnands">
      <organization showOnFrontPage="true">Individual</organization>
      <address>
        <email>ice@braindump.be</email>
      </address>
    </author>
    <author fullname="Tony Przygienda" initials="T." surname="Przygienda">
      <organization showOnFrontPage="true">Juniper</organization>
      <address>
        <email>prz@juniper.net</email>
      </address>
    </author>
    <author fullname="Zhaohui Zhang" initials="Z." role="editor" surname="Zhang">
      <organization showOnFrontPage="true">Juniper</organization>
      <address>
        <email>zzhang@juniper.net</email>
      </address>
    </author>
    <date month="06" year="2025"/>
    <area>RTG</area>
    <workgroup>bier</workgroup>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">Bit Index Explicit Replication (BIER) is a multicast forwarding
      architecture that doesn't require an explicit tree-building protocol
      and doesn't require intermediate routers to maintain per-tree multicast
      states. Some BIER-specific information and states, which are only in
      proportion to the number of BIER routers but not per-tree, do need to be advertised,
      calculated, and maintained. This document describes BGP extensions for
      advertising the BIER information and methods for calculating BIER states
	  based on the advertisements.</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/rfc9793" 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) 2025 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-bier-path-attribute">BIER Path Attribute</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-bier-mpls-encapsulation-sub">BIER MPLS Encapsulation Sub-TLV</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-bier-non-mpls-encapsulation">BIER Non-MPLS Encapsulation Sub-TLV</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-bier-nexthop-sub-tlv">BIER Nexthop Sub-TLV</xref></t>
              </li>
            </ul>
          </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-originating-propagating-upd">Originating/Propagating/Updating the BIER Attribute</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-bift-calculation-with-bgp-s">BIFT Calculation with BGP Signaling</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-example-of-bier-nexthop-usa">Example of BIER Nexthop Usage and Handling</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-operational-considerations">Operational Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <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.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.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.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">Bit Index Explicit Replication (BIER) <xref target="RFC8279" format="default" sectionFormat="of" derivedContent="RFC8279"/> is a multicast
      forwarding architecture that doesn't require an explicit tree-building
      protocol and doesn't require intermediate routers to maintain per-tree
      multicast states. It supports both direct and tunneled BIER forwarding.
   This document describes BGP extensions for advertising the BIER
   information and methods for calculating BIER states based on the
   advertisements. More
      specifically, in this document, we define a new optional
      transitive BGP attribute, referred to as the "BIER attribute", to convey
      the BIER-specific information such as Bit-Forwarding Router Identifier
      (BFR-ID), BitStringLength (BSL), and so on. The signaling is to be
	  used in a single Administrative Domain (AD), and <xref target="op" format="default" sectionFormat="of" derivedContent="Section 7"/> specifies
	  procedures to prevent the BIER attribute from "leaking out" of the domain.</t>
    </section>
    <section anchor="Abbreviations_Terminology" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-2-1">This document makes use of the terminology defined in <xref target="RFC4271" format="default" sectionFormat="of" derivedContent="RFC4271"/> and <xref target="RFC8279" format="default" sectionFormat="of" derivedContent="RFC8279"/>. Some terms are listed below for
      convenience.</t>
      <dl spacing="normal" newline="false" indent="3" pn="section-2-2">
        <dt pn="section-2-2.1">BIER:</dt>
        <dd pn="section-2-2.2">Bit Indexed Explicit Replication</dd>
        <dt pn="section-2-2.3">BFR:</dt>
        <dd pn="section-2-2.4">Bit-Forwarding Router</dd>
        <dt pn="section-2-2.5">BFR-ID:</dt>
        <dd pn="section-2-2.6">BFR Identifier</dd>
        <dt pn="section-2-2.7">BSL:</dt>
        <dd pn="section-2-2.8">BitStringLength</dd>
        <dt pn="section-2-2.9">BIFT:</dt>
        <dd pn="section-2-2.10">Bit Index Forwarding Table</dd>
        <dt pn="section-2-2.11">BIFT-id:</dt>
        <dd pn="section-2-2.12">Bit Index Forwarding Table Identifier</dd>
        <dt pn="section-2-2.13">BFER:</dt>
        <dd pn="section-2-2.14">Bit-Forwarding Egress Router</dd>
        <dt pn="section-2-2.15">BFR-prefix:</dt>
        <dd pn="section-2-2.16">Each BFR is assigned a single "BFR-prefix" for each
	sub-domain to which it belongs. It is recommended that the BFR-prefix
	be a loopback address of the BFR.</dd>
        <dt pn="section-2-2.17">NLRI:</dt>
        <dd pn="section-2-2.18">Network Layer Reachability Information <xref target="RFC4271" format="default" sectionFormat="of" derivedContent="RFC4271"/></dd>
        <dt pn="section-2-2.19">AFI:</dt>
        <dd pn="section-2-2.20">Address Family Identifier <xref target="RFC4760" format="default" sectionFormat="of" derivedContent="RFC4760"/></dd>
        <dt pn="section-2-2.21">SAFI:</dt>
        <dd pn="section-2-2.22">Subsequent Address Family Identifier <xref target="RFC4760" format="default" sectionFormat="of" derivedContent="RFC4760"/></dd>
      </dl>
      <section numbered="true" removeInRFC="false" toc="include" 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="attr" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-bier-path-attribute">BIER Path Attribute</name>
      <t indent="0" pn="section-3-1">This specification defines an optional, transitive BGP path attribute,
      referred to as the "BIER attribute". This attribute can be attached to a
      BGP UPDATE message by the originator for NLRIs of AFI 1 or 2 and
	  SAFI 1, 2, or 4 to indicate the BIER-specific information of a
	  particular BFR identified by the /32 (for IPv4) or /128 (for IPv6)
	  host address prefix contained in the NLRI. The attachment of the BIER
	  attribute to non-host address prefixes is not defined by this document.
	  It may be specified in the future, for example, by
	  <xref target="I-D.ietf-bier-prefix-redistribute" format="default" sectionFormat="of" derivedContent="BIER-Prefix-Redistribute"/>.
      </t>
      <t indent="0" pn="section-3-2">
	  If the BIER path attribute is present, the NLRI is referred to as a
      "BFR-prefix". Use of the attribute with other AFIs/SAFIs is outside the
	  scope of this document.
      </t>
      <t indent="0" pn="section-3-3">
   The BIER path attribute is an optional, transitive BGP path attribute
   with type code 41 and of variable length. The attribute value portion
   carries BIER TLVs, which are encoded as follows:
      </t>
      <artwork align="center" name="" type="" alt="" pn="section-3-4">
   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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                        Value (variable)                       ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
      <t indent="0" pn="section-3-5">
The Length field defines the length of the value portion in octets (thus, a TLV with no value portion would have a length of zero). The TLV is not padded to 4-octet alignment. Unknown and unsupported types <bcp14>MUST</bcp14> be preserved and propagated within the BIER attribute. The presence of unknown or unexpected TLVs <bcp14>MUST NOT</bcp14> result in the NLRI or the BIER attribute being considered malformed.
      </t>
      <t indent="0" pn="section-3-6">
	  When creating a BIER attribute, a BFR <bcp14>MUST</bcp14> include one
      BIER TLV for every sub-domain that the prefix belongs to. The
      attribute type code for the BIER attribute is 41. The value field of
      the BIER attribute contains one or more BIER TLVs as shown below:</t>
      <artwork align="center" name="" type="" alt="" pn="section-3-7">
    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 = 1            |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-domain   |            BFR-ID             |   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   |                           Sub-TLVs                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................
</artwork>
      <dl newline="false" spacing="normal" indent="3" pn="section-3-8">
        <dt pn="section-3-8.1">Type:</dt>
        <dd pn="section-3-8.2">1</dd>
        <dt pn="section-3-8.3">Length:</dt>
        <dd pn="section-3-8.4">2 octets encoding the length in octets of the
        Value part.</dd>
        <dt pn="section-3-8.5">Sub-domain:</dt>
        <dd pn="section-3-8.6">A
        1-octet field encoding the sub-domain ID corresponding to the
        BFR-ID (see <xref target="RFC8279" format="default" sectionFormat="of" derivedContent="RFC8279"/>).</dd>
        <dt pn="section-3-8.7">BFR-ID:</dt>
        <dd pn="section-3-8.8">A
        2-octet field encoding the BFR-ID (see <xref target="RFC8279" format="default" sectionFormat="of" derivedContent="RFC8279"/>).</dd>
        <dt pn="section-3-8.9">Reserved:</dt>
        <dd pn="section-3-8.10">
          <bcp14>SHOULD</bcp14> be set to 0 on
        transmission and <bcp14>MUST</bcp14> be ignored on reception.</dd>
        <dt pn="section-3-8.11">Sub-TLVs:</dt>
        <dd pn="section-3-8.12">Contains one or more sub-TLVs.</dd>
      </dl>
      <t indent="0" pn="section-3-9">The BIER TLV <bcp14>MAY</bcp14> appear multiple times in the BIER path attribute, one for each sub-domain. There <bcp14>MUST</bcp14> be no more than
        one BIER TLV with the same Sub-domain value; if there is, the
        entire BIER path attribute <bcp14>MUST</bcp14> be ignored.
      </t>
      <t indent="0" pn="section-3-10">A BIER TLV may have sub-TLVs, which may have their own sub-TLVs.
        All those are referred to as sub-TLVs and share the same Type space,
        regardless of the level.
      </t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-bier-mpls-encapsulation-sub">BIER MPLS Encapsulation Sub-TLV</name>
        <t indent="0" pn="section-3.1-1">The BIER MPLS Encapsulation sub-TLV has the following format.
	  It <bcp14>MAY</bcp14> appear multiple times in the BIER TLV.
        </t>
        <t indent="0" pn="section-3.1-2">
   The BIER MPLS Encapsulation sub-TLV has the following format:
        </t>
        <artwork align="center" name="" type="" alt="" pn="section-3.1-3">
    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 = 2            |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Max SI    |BS Len |             Label                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                        sub-TLVs                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
        <dl newline="false" spacing="normal" indent="3" pn="section-3.1-4">
          <dt pn="section-3.1-4.1">Type:</dt>
          <dd pn="section-3.1-4.2">2</dd>
          <dt pn="section-3.1-4.3">Length:</dt>
          <dd pn="section-3.1-4.4">2 octets encoding the length in octets of the Value
          part. The value is 4 or other (depending on sub-TLVs).</dd>
          <dt pn="section-3.1-4.5">Max SI:</dt>
          <dd pn="section-3.1-4.6">A 1-octet field encoding the Maximum Set
	  Identifier (see <xref section="1" sectionFormat="of" target="RFC8279" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8279#section-1" derivedContent="RFC8279"/>) used in the encapsulation for this BIER
	  sub-domain for this BitString length.</dd>
          <dt pn="section-3.1-4.7">BS Len:</dt>
          <dd pn="section-3.1-4.8">BitString Length. A 4-bit field encoding the
	  supported BitString length associated with this BFR-prefix.  The
	  values allowed in this field are specified in <xref section="2" sectionFormat="of" target="RFC8296" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8296#section-2" derivedContent="RFC8296"/>.</dd>
          <dt pn="section-3.1-4.9">Label:</dt>
          <dd pn="section-3.1-4.10">A 20-bit value representing the first label in the label range.</dd>
        </dl>
        <t indent="0" pn="section-3.1-5"> The "label range" is the set of labels beginning with the Label
        and ending with (Label + (Max SI)).  A unique label range is allocated
        for each BitString length and sub-domain-id.  These labels are used
        for BIER forwarding, as described in <xref target="RFC8279" format="default" sectionFormat="of" derivedContent="RFC8279"/> and <xref target="RFC8296" format="default" sectionFormat="of" derivedContent="RFC8296"/>.
        </t>
        <t indent="0" pn="section-3.1-6"> The size of the label range is determined by the number of SIs
        (<xref section="1" sectionFormat="of" target="RFC8279" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8279#section-1" derivedContent="RFC8279"/>) that are used
        in the network.  Each SI maps to a single label in the label range:
        the first label is for SI=0, the second label is for SI=1, etc.
        </t>
        <t indent="0" pn="section-3.1-7">

   If the label associated with the Maximum SI exceeds the
   20-bit range, the BIER MPLS Encapsulation sub-TLV containing the
   error <bcp14>MUST</bcp14> be ignored.
        </t>
        <t indent="0" pn="section-3.1-8">

   If the same BitString length is repeated in multiple BIER MPLS Encapsulation sub-TLVs inside the same BIER TLV, all BIER MPLS Encapsulation sub-TLVs in the BIER TLV <bcp14>MUST</bcp14> be ignored.
        </t>
        <t indent="0" pn="section-3.1-9">

   Label ranges within all BIER MPLS Encapsulation sub-TLVs advertised
   by the same BFR <bcp14>MUST NOT</bcp14> overlap.  If an overlap is detected, all
   BIER MPLS Encapsulation sub-TLVs advertised by the BFR <bcp14>MUST</bcp14> be ignored.
        </t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-bier-non-mpls-encapsulation">BIER Non-MPLS Encapsulation Sub-TLV</name>
        <t indent="0" pn="section-3.2-1">The BIER non-MPLS Encapsulation sub-TLV is used for non-MPLS encapsulation and has the following format. It <bcp14>MAY</bcp14> appear multiple times within a
   single BIER TLV.  If the same BitString length is repeated in
   multiple BIER non-MPLS Encapsulation sub-TLVs inside the same BIER
   TLV, the BIER TLV <bcp14>MUST</bcp14> be ignored.
        </t>
        <artwork align="center" name="" type="" alt="" pn="section-3.2-2">
    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 = 3            |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Max SI    |BS Len |                  BIFT-id              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                        sub-TLVs                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
        <dl newline="false" spacing="normal" indent="3" pn="section-3.2-3">
          <dt pn="section-3.2-3.1">Type:</dt>
          <dd pn="section-3.2-3.2">3</dd>
          <dt pn="section-3.2-3.3">Length:</dt>
          <dd pn="section-3.2-3.4">2 octets encoding the length in octets of the Value
          part. The value is 4 or other (depending on sub-TLVs).</dd>
          <dt pn="section-3.2-3.5">Max SI:</dt>
          <dd pn="section-3.2-3.6">A 1-octet field encoding the Maximum Set
	  Identifier (<xref section="1" sectionFormat="of" target="RFC8279" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8279#section-1" derivedContent="RFC8279"/>)
	  used in the encapsulation for this BIER sub-domain for this BitString
	  length. The first BIFT-id is for SI=0, the second BIFT-id is for
	  SI=1, etc. If the BIFT-id associated with the Maximum SI
	  exceeds the 20-bit range, the sub-TLV <bcp14>MUST</bcp14> be
	  ignored.</dd>
          <dt pn="section-3.2-3.7">BS Len:</dt>
          <dd pn="section-3.2-3.8">BitString Length. A 4-bit field encoding the
	  BitString length (as per <xref target="RFC8296" format="default" sectionFormat="of" derivedContent="RFC8296"/>)
	  supported for the encapsulation.</dd>
          <dt pn="section-3.2-3.9">BIFT-id:</dt>
          <dd pn="section-3.2-3.10">A 20-bit field representing the first BIFT-id
	  in the BIFT-id range.</dd>
        </dl>
        <t indent="0" pn="section-3.2-4">
   The "BIFT-id range" is the set of 20-bit values beginning with the
   BIFT-id and ending with (BIFT-id + (Max SI)).  These BIFT-ids are
   used for BIER forwarding, as described in <xref target="RFC8279" format="default" sectionFormat="of" derivedContent="RFC8279"/> and <xref target="RFC8296" format="default" sectionFormat="of" derivedContent="RFC8296"/>.
        </t>
        <t indent="0" pn="section-3.2-5">
   The size of the BIFT-id range is determined by the number of SIs
   (<xref section="1" sectionFormat="of" target="RFC8279" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8279#section-1" derivedContent="RFC8279"/>) that are used in the network.  Each SI maps
   to a single BIFT-id in the BIFT-id range: the first BIFT-id is for
   SI=0, the second BIFT-id is for SI=1, etc.
        </t>
        <t indent="0" pn="section-3.2-6">

   If the BIFT-id associated with the Maximum SI exceeds
   the 20-bit range, the BIER non-MPLS Encapsulation sub-TLV
   containing the error <bcp14>MUST</bcp14> be ignored.
        </t>
        <t indent="0" pn="section-3.2-7">

	  BIFT-id ranges within all the BIER non-MPLS Encapsulation sub-TLVs
	  advertised by the same BFR <bcp14>MUST NOT</bcp14> overlap.  If an overlap is
   detected, all the BIER non-MPLS Encapsulation sub-TLVs advertised
   by the BFR <bcp14>MUST</bcp14> be ignored. However, the
   BIFT-id ranges may overlap across different encapsulation types and
   that is allowed.  As an example, the BIFT-id value in the non-MPLS Encapsulation sub-TLV may overlap with the Label value in the
   Label range in the BIER MPLS Encapsulation sub-TLV.
        </t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-3.3">
        <name slugifiedName="name-bier-nexthop-sub-tlv">BIER Nexthop Sub-TLV</name>
        <t indent="0" pn="section-3.3-1">The BIER Nexthop sub-TLV <bcp14>MAY</bcp14> be included, and it <bcp14>MUST NOT</bcp14> be included
	  more than once in each of the MPLS or non-MPLS
        Encapsulation sub-TLVs or in the top-level BIER TLV. It is used
		when calculating BIFT entries, as described in <xref target="bift" format="default" sectionFormat="of" derivedContent="Section 5"/>
		and illustrated in <xref target="biernh" format="default" sectionFormat="of" derivedContent="Section 6"/>.
        </t>
        <artwork align="center" name="" type="" alt="" pn="section-3.3-2">
    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 = 4           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Nexthop                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
        <dl newline="false" spacing="normal" indent="3" pn="section-3.3-3">
          <dt pn="section-3.3-3.1">Type:</dt>
          <dd pn="section-3.3-3.2">4</dd>
          <dt pn="section-3.3-3.3">Length:</dt>
          <dd pn="section-3.3-3.4">2 octets. The value is 4 if the Nexthop is an
          IPv4 address and 16 if the Nexthop is an IPv6 address.</dd>
          <dt pn="section-3.3-3.5">Nexthop:</dt>
          <dd pn="section-3.3-3.6">4 or 16 octets of an IPv4/IPv6 address.</dd>
        </dl>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-originating-propagating-upd">Originating/Propagating/Updating the BIER Attribute</name>
      <t indent="0" pn="section-4-1">A Bit-Forwarding Egress Router (BFER) <bcp14>MUST</bcp14> attach a BIER attribute
        to its own /32 (for IPv4) or /128 (for IPv6)
		host BFR-prefix NLRI. The BIER attribute <bcp14>MUST</bcp14> include one
        BIER TLV for each BIER sub-domain that it supports. Each BIER TLV
        <bcp14>MUST</bcp14> include an MPLS and/or non-MPLS Encapsulation sub-TLV and <bcp14>MAY</bcp14>
        include a BIER Nexthop sub-TLV with the Nexthop set to the
        BIER prefix. If the BIER Nexthop sub-TLV is not included, the BIER prefix
        will be used by receiving BFRs as the BIER next hop when calculating BIFT.
      </t>
      <t indent="0" pn="section-4-2">When a BFR receives an update with the BIER path attribute, the
        attribute is parsed with the following validations:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-3">
        <li pn="section-4-3.1">
          <t indent="0" pn="section-4-3.1.1">Syntactic checking based on the Length field of TLVs and sub-TLVs:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-3.1.2">
            <li pn="section-4-3.1.2.1">The total length of BIER TLVs (including the Type and Length
            fields) <bcp14>MUST</bcp14> be equal to the BIER path attribute
            length.</li>
            <li pn="section-4-3.1.2.2">The total length of sub-TLVs (including the Type and Length
            fields) of a TLV <bcp14>MUST</bcp14> be equal to the length of the
            TLV.</li>
          </ul>
        </li>
        <li pn="section-4-3.2">Semantic checking as per <xref target="attr" format="default" sectionFormat="of" derivedContent="Section 3"/>.</li>
      </ul>
      <t indent="0" pn="section-4-4">
   If the syntactic checking fails, the attribute is considered	
   malformed and the "attribute discard" action <xref target="RFC7606" format="default" sectionFormat="of" derivedContent="RFC7606"/>
   for the BIER attribute <bcp14>MUST</bcp14> be taken. If the semantic checking passes,
   BIFT	 entries are calculated as described in <xref target="bift" format="default" sectionFormat="of" derivedContent="Section 5"/>.  Otherwise
   (i.e., if semantic checking fails), some or all BIER TLVs are ignored, per the rules
   given in <xref target="attr" format="default" sectionFormat="of" derivedContent="Section 3"/>, and if the remaining data permits,
   BIFT entries are calculated per <xref target="bift" format="default" sectionFormat="of" derivedContent="Section 5"/>.
      </t>
      <t indent="0" pn="section-4-5">When a BFR re-advertises a BGP NLRI with a BIER attribute, for the
		sub-domains that this BFR supports, in the corresponding BIER TLV, it
        <bcp14>SHOULD</bcp14> set/update the BIER Nexthop sub-TLV to use its own BIER prefix;
        in which case, it <bcp14>MUST</bcp14> replace the MPLS or non-MPLS Encapsulation sub-TLV
        with its own, i.e., as if the BFR is attaching the
        encapsulation sub-TLV for its own BIER prefix. If it does not
        update the BIER Nexthop sub-TLVs, it <bcp14>MUST NOT</bcp14> update the MPLS or
        non-MPLS Encapsulation sub-TLV. If it does not support a sub-domain,
		it <bcp14>MUST NOT</bcp14> update the corresponding BIER TLV.
      </t>
      <t indent="0" pn="section-4-6">It's possible that the BFR supports some but not all
		BitStringLengths (BSLs)
        in the received MPLS or non-MPLS Encapsulation sub-TLVs.
        After setting/updating the BIER Nexthop sub-TLV in the top BIER TLV
        to itself, for the BSLs that it does support, the BFR <bcp14>MUST</bcp14> remove
        the BIER Nexthop sub-TLV (if present) in the corresponding Encapsulation
        sub-TLVs. For the BSLs that it does not support:
      </t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-7">
        <li pn="section-4-7.1">
          <t indent="0" pn="section-4-7.1.1">If a BIER Nexthop sub-TLV is included in the Encapsulation sub-TLV,
		  it <bcp14>MUST NOT</bcp14> be updated.</t>
        </li>
        <li pn="section-4-7.2">
          <t indent="0" pn="section-4-7.2.1">Otherwise, if a BIER Nexthop sub-TLV is included in the received
		  BIER TLV, its original value (before changed for supported BSLs by
		  this BFR) <bcp14>MUST</bcp14> be copied into the Encapsulation sub-TLV.</t>
        </li>
        <li pn="section-4-7.3">
          <t indent="0" pn="section-4-7.3.1">Otherwise, a BIER Nexthop sub-TLV <bcp14>MUST</bcp14> be added to the
		  Encapsulation sub-TLV with its value set to the BFR-prefix.</t>
        </li>
      </ul>
      <t indent="0" pn="section-4-8">
		  All impacted Length fields (e.g.,
        the Encapsulation sub-TLV Length and the top-level BIER TLV Length) <bcp14>MUST</bcp14>
        be updated accordingly.
      </t>
      <t indent="0" pn="section-4-9">Since the BIER attribute is an optional, transitive BGP path
      attribute, a non-BFR BGP speaker could still re-advertise the received
      route with a BIER attribute.
      </t>
      <t indent="0" pn="section-4-10">Two different BFR-prefixes <bcp14>MUST NOT</bcp14> have the same non-zero BFR-ID
	  in the same sub-domain. If a duplication is detected, the receiving
	  BFR <bcp14>MUST NOT</bcp14> use the BFR-prefixes with the same BFR-ID for BIFT
	  calculation for the sub-domain and an error <bcp14>SHOULD</bcp14> be logged.
      </t>
    </section>
    <section anchor="bift" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-bift-calculation-with-bgp-s">BIFT Calculation with BGP Signaling</name>
      <t indent="0" pn="section-5-1">As pointed out in <xref target="RFC8279" format="default" sectionFormat="of" derivedContent="RFC8279"/>, BIFTs are derived from
	  the unicast FIB by adding BIER-specific information.
      </t>
      <t indent="0" pn="section-5-2">For each sub-domain, a BFR calculates the corresponding BIFTs
      by going through the BIER prefixes whose BIER attribute includes
      a BIER TLV for the sub-domain.
      For a non-zero BFR-id in the BIER TLV,
      a BIFT entry is created or updated. The entry's BFR Neighbor
      (BFR-NBR) <xref target="RFC8279" format="default" sectionFormat="of" derivedContent="RFC8279"/> is the Nexthop in the BIER
      Nexthop sub-TLV in the corresponding Encapsulation sub-TLV or
      in the top-level BIER TLV if the Encapsulation sub-TLV does not
      have a BIER Nexthop sub-TLV. If there is no BIER Nexthop sub-TLV at all,
      the entry's BFR-NBR is the BIER prefix itself. The BIER label
      or BIFT-id for the entry is derived from the label range in the
      MPLS Encapsulation sub-TLV or from the BIFT-id range in the
      non-MPLS Encapsulation sub-TLV.
      </t>
      <t indent="0" pn="section-5-3">BIER traffic is sent to the BFR-NBR either directly (BIER header
      directly follows a Layer 2 header) if the BFR-NBR is directly
      connected or via a tunnel. Notice that, if a non-BFR
      BGP speaker re-advertises a BIER prefix (in this case, it cannot update
      the BIER attribute since it is not capable), or if a BFR BGP speaker
      re-advertises a BIER prefix without updating the BIER Nexthop
      sub-TLV, the BFR receiving the prefix will tunnel BIER traffic --  
      the BGP speaker re-advertising the BIER prefix will not see the
      BIER traffic for the BIER prefix.
      </t>
      <t indent="0" pn="section-5-4">How the tunnel is set up and chosen is outside the scope of this
	  document. It can be any kind of tunnel, e.g., MPLS Label Switched Path
	  or IP/GRE, as long as the tunnel header can indicate that the payload
	  is BIER.
      </t>
    </section>
    <section anchor="biernh" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-example-of-bier-nexthop-usa">Example of BIER Nexthop Usage and Handling</name>
      <t indent="0" pn="section-6-1">Consider a simple topology as follows:
      </t>
      <artwork name="" type="" align="left" alt="" pn="section-6-2">
                                      ----- BFER1
                                     /
           BFR1 --- non-BFR --- BFR2 ------ BFER2
                                     \
                                      ----- BFER3
</artwork>
      <t indent="0" pn="section-6-3">The BFER1/2/3 each advertises a route for its loopback address with a
      BIER path attribute, listing one BIER TLV for each sub-domain that it is
      in, with a non-zero BFR-ID and an MPLS Encapsulation sub-TLV.  A BIER
      Nexthop sub-TLV is not included in the one from BFER1 but is included in
      the ones from BFER2/3. The BIER Nexthop sub-TLV encodes the BFR-prefix
      of BFER2 and BFER3, respectively.
      </t>
      <t indent="0" pn="section-6-4">When BFR2 receives the route, it calculates its BIFT entries.
	  Because the route from BFER1 does not include a BIER Nexthop, BFR2
	  uses BFR1's BFR-prefix as the next hop.
      </t>
      <t indent="0" pn="section-6-5">When BFR2 re-advertises the routes to the non-BFR, it adds
	  a BIER Nexthop sub-TLV to the BFER1 route and updates the BIER Nexthop
	  sub-TLV in the BFER2/3 routes, all encoding BFR2's own address.
	  It also updates the MPLS Encapsulation sub-TLV to encode its own labels.
      </t>
      <t indent="0" pn="section-6-6">When the non-BFR receives the routes, since it does not support BIER,
	  no BIER-specific action is taken and the routes are re-advertised to
	  BFR1 with the BIER path attribute unchanged.
      </t>
      <t indent="0" pn="section-6-7">When BFR1 receives the routes, it calculates the BIFT entries,
	  using BFR2's address encoded in the BIER Nexthop sub-TLV as the
	  next hop. Because BFR2 is not directly connected, a tunnel must be used.
      </t>
    </section>
    <section anchor="op" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-operational-considerations">Operational Considerations</name>
      <t indent="0" pn="section-7-1">In this document, it is assumed that the BIER domain
	  <xref target="RFC8279" format="default" sectionFormat="of" derivedContent="RFC8279"/> is aligned with
      an Administrative Domain (AD), which may be composed of multiple
	  Autonomous Systems. Use of the BIER attribute in other
      scenarios is outside the scope of this document.</t>
      <t indent="0" pn="section-7-2">BFR-prefixes are typically loopback addresses on the BFRs. They
	  are distributed throughout the AD, but they do not need to be
	  distributed outside the AD for the BIER's purposes. This is analogous
	  to the Provider Edge router's loopback addresses that are distributed
	  inside the AD, but they do not need to be distributed outside the AD.
      </t>
      <t indent="0" pn="section-7-3">If prefixes are distributed outside of the AD with the BIER
	  attribute attached and the neighboring AD also deploying BIER,
	  then the two BIER domains, which should be independent of each other,
	  may be incorrectly joined together and most likely have conflicting
	  configurations, causing security risks and operational troubles.
      </t>
      <t indent="0" pn="section-7-4">To prevent that, a boundary router of the AD that supports the BIER
	  attribute <bcp14>MUST</bcp14>
      support a policy based on an External BGP (EBGP) session/group that indicates whether the
      attribute is allowed; by default, it is NOT allowed.
	  If it is not allowed, the BIER
      attribute <bcp14>MUST NOT</bcp14> be sent to any EBGP peer of the session/group.
      If a BIER attribute is received from the peer, it <bcp14>MUST</bcp14> be treated
      exactly as if it were an unrecognized non-transitive attribute.
	  That is, it <bcp14>MUST</bcp14> be quietly ignored and not passed along to other
	  BGP peers.</t>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-8-1">IANA has assigned codepoint 41 to the BIER attribute in the "BGP Path
      Attributes" registry
      <eref brackets="angle" target="https://www.iana.org/assignments/bgp-parameters"/> as follows:</t>
      <table align="center" pn="table-1">
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Value</th>
            <th align="left" colspan="1" rowspan="1">Code</th>
            <th align="left" colspan="1" rowspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">41</td>
            <td align="left" colspan="1" rowspan="1">BIER</td>
            <td align="left" colspan="1" rowspan="1">RFC 9793</td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-8-3">IANA has created the "BGP BIER TLV and Sub-TLV Types" registry within the "Border Gateway Protocol (BGP) Parameters" registry group.  The type field for the
      registry consists of 2 octets, with possible values from 0 to 65535
      (the value 0 is reserved). The allocation policy for this field is
      First Come First Served <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>.</t>
      <t indent="0" pn="section-8-4">The five initial values have been allocated as follows:</t>
      <table align="center" pn="table-2">
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Value</th>
            <th align="left" colspan="1" rowspan="1">Name</th>
            <th align="left" colspan="1" rowspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">0</td>
            <td align="left" colspan="1" rowspan="1">Reserved</td>
            <td align="left" colspan="1" rowspan="1">RFC 9793</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">1</td>
            <td align="left" colspan="1" rowspan="1">BIER TLV</td>
            <td align="left" colspan="1" rowspan="1">RFC 9793</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">2</td>
            <td align="left" colspan="1" rowspan="1">MPLS Encapsulation sub-TLV</td>
            <td align="left" colspan="1" rowspan="1">RFC 9793</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">3</td>
            <td align="left" colspan="1" rowspan="1">non-MPLS Encapsulation sub-TLV</td>
            <td align="left" colspan="1" rowspan="1">RFC 9793</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">4</td>
            <td align="left" colspan="1" rowspan="1">BIER Nexthop sub-TLV</td>
            <td align="left" colspan="1" rowspan="1">RFC 9793</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">5-65535</td>
            <td colspan="2" align="left" rowspan="1">Unassigned</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="Security" numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-9-1">This document introduces no new security considerations beyond those
      already discussed in <xref target="RFC4271" format="default" sectionFormat="of" derivedContent="RFC4271"/>, <xref target="RFC8279" format="default" sectionFormat="of" derivedContent="RFC8279"/>, and the operational considerations
      (<xref target="op" format="default" sectionFormat="of" derivedContent="Section 7"/>) of this document.</t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-bier-prefix-redistribute" to="BIER-Prefix-Redistribute"/>
    <references pn="section-10">
      <name slugifiedName="name-references">References</name>
      <references pn="section-10.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 fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <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="RFC4271" target="https://www.rfc-editor.org/info/rfc4271" quoteTitle="true" derivedAnchor="RFC4271">
          <front>
            <title>A Border Gateway Protocol 4 (BGP-4)</title>
            <author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rekhter"/>
            <author fullname="T. Li" initials="T." role="editor" surname="Li"/>
            <author fullname="S. Hares" initials="S." role="editor" surname="Hares"/>
            <date month="January" year="2006"/>
            <abstract>
              <t indent="0">This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.</t>
              <t indent="0">The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.</t>
              <t indent="0">BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.</t>
              <t indent="0">This document obsoletes RFC 1771. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4271"/>
          <seriesInfo name="DOI" value="10.17487/RFC4271"/>
        </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 fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <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>
        <reference anchor="RFC8279" target="https://www.rfc-editor.org/info/rfc8279" quoteTitle="true" derivedAnchor="RFC8279">
          <front>
            <title>Multicast Using Bit Index Explicit Replication (BIER)</title>
            <author fullname="IJ. Wijnands" initials="IJ." role="editor" surname="Wijnands"/>
            <author fullname="E. Rosen" initials="E." role="editor" surname="Rosen"/>
            <author fullname="A. Dolganow" initials="A." surname="Dolganow"/>
            <author fullname="T. Przygienda" initials="T." surname="Przygienda"/>
            <author fullname="S. Aldrin" initials="S." surname="Aldrin"/>
            <date month="November" year="2017"/>
            <abstract>
              <t indent="0">This document specifies a new architecture for the forwarding of multicast data packets. It provides optimal forwarding of multicast packets through a "multicast domain". However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state. This architecture is known as "Bit Index Explicit Replication" (BIER). When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The procedures for forwarding a packet based on its BIER header are specified in this document. Elimination of the per-flow state and the explicit tree-building protocols results in a considerable simplification.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8279"/>
          <seriesInfo name="DOI" value="10.17487/RFC8279"/>
        </reference>
        <reference anchor="RFC8296" target="https://www.rfc-editor.org/info/rfc8296" quoteTitle="true" derivedAnchor="RFC8296">
          <front>
            <title>Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks</title>
            <author fullname="IJ. Wijnands" initials="IJ." role="editor" surname="Wijnands"/>
            <author fullname="E. Rosen" initials="E." role="editor" surname="Rosen"/>
            <author fullname="A. Dolganow" initials="A." surname="Dolganow"/>
            <author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
            <author fullname="S. Aldrin" initials="S." surname="Aldrin"/>
            <author fullname="I. Meilik" initials="I." surname="Meilik"/>
            <date month="January" year="2018"/>
            <abstract>
              <t indent="0">Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The details of the encapsulation depend on the type of network used to realize the multicast domain. This document specifies a BIER encapsulation that can be used in an MPLS network or, with slight differences, in a non-MPLS network.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8296"/>
          <seriesInfo name="DOI" value="10.17487/RFC8296"/>
        </reference>
      </references>
      <references pn="section-10.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="I-D.ietf-bier-prefix-redistribute" target="https://datatracker.ietf.org/doc/html/draft-ietf-bier-prefix-redistribute-08" quoteTitle="true" derivedAnchor="BIER-Prefix-Redistribute">
          <front>
            <title>BIER Prefix Redistribute</title>
            <author fullname="Zheng Zhang" initials="Z." surname="Zhang">
              <organization showOnFrontPage="true">ZTE Corporation</organization>
            </author>
            <author fullname="Bo Wu" initials="B." surname="Wu">
              <organization showOnFrontPage="true">Individual</organization>
            </author>
            <author fullname="Zhaohui (Jeffrey) Zhang" initials="Z. J." surname="Zhang">
              <organization showOnFrontPage="true">Juniper Networks</organization>
            </author>
            <author fullname="IJsbrand Wijnands" initials="I." surname="Wijnands">
              <organization showOnFrontPage="true">Individual</organization>
            </author>
            <author fullname="Yisong Liu" initials="Y." surname="Liu">
              <organization showOnFrontPage="true">China Mobile</organization>
            </author>
            <author fullname="Hooman Bidgoli" initials="H." surname="Bidgoli">
              <organization showOnFrontPage="true">Nokia</organization>
            </author>
            <date day="23" month="February" year="2025"/>
            <abstract>
              <t indent="0">This document defines a BIER proxy function to support one single BIER sub-domain over multiple underlay routing protocol regions (Autonomous Systems or IGP areas). A new BIER proxy range sub-TLV is defined to redistribute BIER BFR-id information across the routing regions.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-bier-prefix-redistribute-08"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC4760" target="https://www.rfc-editor.org/info/rfc4760" quoteTitle="true" derivedAnchor="RFC4760">
          <front>
            <title>Multiprotocol Extensions for BGP-4</title>
            <author fullname="T. Bates" initials="T." surname="Bates"/>
            <author fullname="R. Chandra" initials="R." surname="Chandra"/>
            <author fullname="D. Katz" initials="D." surname="Katz"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <date month="January" year="2007"/>
            <abstract>
              <t indent="0">This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4760"/>
          <seriesInfo name="DOI" value="10.17487/RFC4760"/>
        </reference>
        <reference anchor="RFC7606" target="https://www.rfc-editor.org/info/rfc7606" quoteTitle="true" derivedAnchor="RFC7606">
          <front>
            <title>Revised Error Handling for BGP UPDATE Messages</title>
            <author fullname="E. Chen" initials="E." role="editor" surname="Chen"/>
            <author fullname="J. Scudder" initials="J." role="editor" surname="Scudder"/>
            <author fullname="P. Mohapatra" initials="P." surname="Mohapatra"/>
            <author fullname="K. Patel" initials="K." surname="Patel"/>
            <date month="August" year="2015"/>
            <abstract>
              <t indent="0">According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable because a session reset would impact not only routes with the offending attribute but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes.</t>
              <t indent="0">This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760, 5543, 5701, and 6368.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7606"/>
          <seriesInfo name="DOI" value="10.17487/RFC7606"/>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="June" year="2017"/>
            <abstract>
              <t indent="0">Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t indent="0">To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t indent="0">This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </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">Thanks to <contact fullname="Eric Rosen"/> and <contact fullname="Peter Psenak"/> for their valuable comments on this
      document.</t>
    </section>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-contributors">Contributors</name>
      <t indent="0" pn="section-appendix.b-1">This document has the following contributor:</t>
      <contact fullname="Zheng (Sandy) Zhang">
        <organization showOnFrontPage="true">ZTE</organization>
        <address>
          <email>zhang.zheng@zte.com.cn</email>
        </address>
      </contact>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Xiaohu Xu" initials="X." surname="Xu">
        <organization showOnFrontPage="true">China Mobile</organization>
        <address>
          <email>xuxiaohu@cmss.chinamobile.com</email>
        </address>
      </author>
      <author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen">
        <organization showOnFrontPage="true">Huawei</organization>
        <address>
          <email>mach.chen@huawei.com</email>
        </address>
      </author>
      <author fullname="Keyur Patel" initials="K." surname="Patel">
        <organization showOnFrontPage="true">Arrcus, Inc.</organization>
        <address>
          <email>keyur@arrcus.com</email>
        </address>
      </author>
      <author fullname="IJsbrand Wijnands" initials="IJ." surname="Wijnands">
        <organization showOnFrontPage="true">Individual</organization>
        <address>
          <email>ice@braindump.be</email>
        </address>
      </author>
      <author fullname="Tony Przygienda" initials="T." surname="Przygienda">
        <organization showOnFrontPage="true">Juniper</organization>
        <address>
          <email>prz@juniper.net</email>
        </address>
      </author>
      <author fullname="Zhaohui Zhang" initials="Z." role="editor" surname="Zhang">
        <organization showOnFrontPage="true">Juniper</organization>
        <address>
          <email>zzhang@juniper.net</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
