<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.6 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes"?>
<rfc category="std" docName="draft-chen-bier-idr-bier-te-bgp-07"
     ipr="trust200902">
  <front>
   <title abbrev="BGP extensions for BIER-TE">BGP extensions for BIER-TE</title>
   
   <author fullname="Ran Chen" initials="R." surname="Chen">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city>Nanjing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <email>chen.ran@zte.com.cn</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
	
	 <author fullname="Changwang Lin" initials="L." surname="Changwang">
      <organization>New H3C Technologies</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->
         <city>Beijing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <email>linchangwang.04414@h3c.com</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
	   <author fullname="Benchong Xu" initials="B." surname="Xu">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city>Nanjing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <email>xu.benchong@zte.com.cn</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
	
	  <author fullname="Zheng Zhang" initials="Z." surname="Zhang">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city>Nanjing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <email>zhang.zheng@zte.com.cn</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
    <date year="2026"/>
    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
        in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

   <!-- Meta-data Declarations -->

   <area>Routing</area>
    <workgroup>BIER</workgroup>
    <!-- WG name at the upperleft corner of the doc,
        IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
        which is used by the RFC Editor as a nod to the history of the IETF. -->

   <keyword>Internet Draft</keyword>
    <!-- Keywords will be incorporated into HTML output
        files in a meta tag but they have no effect on text or nroff
        output. If you submit your draft to the RFC Editor, the
        keywords will be used for the search engine. -->
   
   <abstract>
	 <t> "Tree Engineering for Bit Index Explicit Replication" (BIER-TE) shares architecture and packet formats with BIER. BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies.</t>
	  <t>This document describes BGP extensions for advertising the BIER-TE specific information. </t>
    </abstract>
  </front>
  <middle>
  
    <section numbered="true" toc="default">
      <name>Introduction</name>
	 <t>"Tree Engineering for Bit Index Explicit Replication" (BIER-TE) shares architecture and packet formats with BIER as described in <xref target="RFC8279"/>. BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies as described in <xref target="RFC9262"/>.</t>
	  <t>This document describes BGP extensions for advertising the BIER-TE specific information. More specifically, in this document, we define a new optional, non-transitive BGP attribute, referred to as the BIER-TE attribute, to convey the BIER-TE specific information.</t>
	  <t> These extensions are applicable to BGP based network scenarios.</t>
	  
	   <section 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", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119" format="default"></xref> <xref target="RFC8174" format="default"></xref> when, and only when, they appear in all capitals, as shown here.</t>
      </section>  
	   </section>
	   
   <section numbered="true" toc="default">
   <name>BIER-TE TLV</name>
    <t><xref target="RFC9793"/> defines BIER Path attribute, and this document reuse the Bier Path attribute. The content of the BIER Path attribute is one or more BIER-TE TLV as shown in Figure 1. This TLV contains BIER-TE information associated with a Prefix.</t>
        <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 (TBD1)          |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-domain-id |            
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  sub-TLVs (variable)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   Figure 1: BIER-TE TLV
		    ]]></artwork>
	  <t>Type:A 2-octet field with value TBD1, see IANA Considerations section.</t>
      <t>Length: 2 octets.</t>
      <t>Subdomain-id: Unique value identifying the BIER-TE sub-domain, 1 octet.</t>  
	  <t>Sub-TLVs: contains one or more sub-TLV. In this document, it defines three sub-TLV: the BIER-TE MPLS Encapsulation sub-TLV , the BIER-TE non-MPLS Encapsulation sub-TLV and the Bitposition sub-TLV.</t>
  <section numbered="true" toc="default">
        <name>The BIER-TE MPLS Encapsulation sub-TLV</name>
	    <t>This sub-TLV carries the information for the BIER MPLS encapsulation including the label range for a specific BitString length for a certain &lt; MT,SD &gt;. It is advertised within the BIER-TE TLV. This sub-TLV MAY appear multiple times within a single BIER-TE sub-TLV. If the same BitString length is repeated in multiple sub-TLVs inside the same BIER-TE TLV, the BIER-TE TLV MUST be ignored.</t>
        <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      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Max SI      |BS Len |                    Label              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	      Figure 2: BIER-TE MPLS Encapsulation sub-TLV
		    ]]></artwork>
		<t>Type:A 2-octet field with value TBD2.</t>
        <t>Length:4</t>
	    <t>Max SI:  Maximum Set Identifier (Section 1 of <xref target="RFC8279"/>) used in the encapsulation for this BIER subdomain for this BitString length, 1 octet.  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.  If the label associated with the Maximum Set Identifier exceeds the 20-bit range, the sub-sub-TLV MUST be ignored.</t>
        <t> Local BitString Length (BS Len):  Encoded BitString length as per <xref target="RFC8296"/>. 4 bits.</t>
		<t>Label:  First label of the range, 20 bits.  The labels are as defined in <xref target="RFC8296"/>.</t>
		</section>
		
	 <section numbered="true" toc="default">
        <name>The BIER-TE non-MPLS Encapsulation sub-TLV</name>
	    <t>The sub-TLV is advertised within the BIER-TE TLV.</t>
        <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      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Max SI      |BS Len |                  BIFT-id              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	   Figure 3: BIER-TE non-MPLS Encapsulation sub-TLV
		    ]]></artwork>
		<t>Type:A 2-octet field with value TBD3.</t>
        <t>Length:4</t>
	    <t>Max SI: Maximum Set Identifier (Section 1 of <xref target="RFC8279"/>) used in the encapsulation for this BIER subdomain for this BitString length, 1 octet. 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 Set Identifier exceeds the 20-bit range, the sub-TLV MUST be ignored.</t>
        <t> Local BitString Length (BS Len):  Encoded BitString length as per <xref target="RFC8296"/>. 4 bits.</t>
		<t> BIFT-id: A 20 bit field encoding the first BIFT-id of the BIFT-id range. BIFT-id as per <xref target="I-D.ietf-bier-lsr-non-mpls-extensions"/>.</t>
		</section>	
				
	 <section numbered="true" toc="default">
        <name>The Bitposition sub-TLV</name>
        <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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           BitPosition-1       |    
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Adjacency address-1                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          BitPosition-n        |      
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Adjacency address-n                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Figure 4:Bitposition sub-TLV
		    ]]></artwork>
		<t>Type:A 2-octet field with value TBD4.</t>
        <t>Length:4 if the Nexthop is IPv4 address and 16 if the Nexthop is IPv6 address</t>
		<t>&lt;BitPosition,Adjacency address&gt;: A 2-octet field encoding the BitPosition associated with a adjacency address. Each adjacency address is a local or remote neighbor address.</t> 
		<t>The Bitposition sub-TLV is included in the BIER-TE TLV.</t>
		</section>	
		  </section>
		  
    <section anchor="Acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>The authors would like to thank Zhaohui Zhang for his valuable suggestions.</t>
    </section>
    <!-- Possibly a 'Contributors' section ... -->

	<section numbered="true" toc="default">
        <name>IANA Considerations</name>
   <t>The document requests new allocations from the IANA registries as follows:</t>
   <section numbered="true" toc="default">
        <name>The new BIER-TE TLVs</name>
      <t> This document requests assigning code-points from the "BGP BIER Path Attribute Types" registry for the new BIER-TE TLV.</t>
          <artwork align="center"><![CDATA[
 Value        Description            Reference
---------  ---------------------   ---------------
 TBD1         BIER-TE               This document     
		      ]]></artwork>
 </section> 
 <section numbered="true" toc="default">
        <name>The new BIER-TE Encapsulation sub-TLVs</name>
		  <t> This document requests assigning code-points from the "BGP BIER-TE TLV sub-TLV Types" for the new BIER-TE Encapsulation sub-TLVs.</t>
          <artwork align="center"><![CDATA[	
Value           Description                      Reference
---------  --------------------------------   ---------------
 TBD2        BIER-TE MPLS Encapsulation        This document  
 TBD3        BIER-TE non-MPLS Encapsulation    This document 
         ]]></artwork>
</section>
<section numbered="true" toc="default">
        <name>The new Bitposition sub-TLV</name>
		  <t> This document requests assigning code-points from the "BGP BIER-TE TLV sub-TLV Types" for the new Bitposition sub-TLV.</t>
          <artwork align="center"><![CDATA[		
Value           Description                Reference
---------  ----------------------------  ---------------
 TBD4        Bitposition sub-TLV          This document  
         ]]></artwork>
</section>
    </section>     
	
    <section anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>
     <t>This document introduces no new security considerations beyond those already discussed in <xref target="RFC4271"/> and <xref target="RFC9262"/>.</t>
    </section>
  </middle>
 
  
    <!-- Possibly a 'Contributors' section ... -->
  <!--  *****BACK MATTER ***** -->

 <back>
     <references title="Normative References">
	  <?rfc include='reference.RFC.2119'?>
	  <?rfc include='reference.RFC.4271'?>
	  <?rfc include='reference.RFC.8174'?>
	  <?rfc include='reference.RFC.8279'?>
	  <?rfc include='reference.RFC.8296'?>
	  <?rfc include='reference.RFC.9262'?>
	  <?rfc include='reference.RFC.9793'?>
	  <?rfc include='reference.I-D.ietf-bier-lsr-non-mpls-extensions'?>
	</references>

    <!-- Change Log

v00 2006-03-15  EBD   Initial version

v01 2006-04-03  EBD   Moved PI location back to position 1 -
                     v3.1 of XMLmind is better with them at this location.
v02 2007-03-07  AH    removed extraneous nested_list attribute,
                     other minor corrections
v03 2007-03-09  EBD   Added comments on null IANA sections and fixed heading capitalization.
                     Modified comments around figure to reflect non-implementation of
                     figure indent control.  Put in reference using anchor="DOMINATION".
                     Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH     Major changes: shortened discussion of PIs,
                     added discussion of rfc include.
v05 2007-03-10 EBD    Added preamble to C program example to tell about ABNF and alternative 
                     images. Removed meta-characters from comments (causes problems).

v06 2010-04-01 TT     Changed ipr attribute values to latest ones. Changed date to
                     year only, to be consistent with the comments. Updated the 
                     IANA guidelines reference from the I-D to the finished RFC.
v07 2020-01-21 HL    Converted the template to use XML schema version 3.
    -->
 </back>
</rfc>
