<?xml version='1.0' encoding='utf-8'?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->
<?xml-model href="rfc7991bis.rnc"?>  <!-- Required for schema validation and schema-aware editing -->
<!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> -->
<!-- This third-party XSLT can be enabled for direct transformations in XML processors, including most browsers -->

<rfc
      xmlns:xi="http://www.w3.org/2001/XInclude"
      category="std"
      docName="draft-zwx-bier-te-isis-extensions-01"
      ipr="trust200902"
      obsoletes=""
      updates=""
      submissionType="IETF"
      xml:lang="en"
      tocInclude="true"
      tocDepth="4"
      symRefs="true"
      sortRefs="true"
      version="3">
  <!-- xml2rfc v2v3 conversion 2.38.1 -->
  <!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
       or pre5378Trust200902
    you can add the attributes updates="NNNN" and obsoletes="NNNN" 
    they will automatically be output with "(if approved)" -->

 <!-- ***** FRONT MATTER ***** -->

 <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
        full title is longer than 39 characters -->

   <title abbrev="Abbreviated Title">IS-IS extensions for BIER-TE (Tree Engineering for Bit Index Explicit Replication) with MPLS and non-MPLS Encapsulation</title>
    <seriesInfo name="Internet-Draft" value="draft-zwx-bier-te-isis-extensions-01"/>
    <!-- add 'role="editor"' below for the editors if appropriate -->

   <!-- Another author who claims to be an editor -->

   <author fullname="Zheng Zhang" initials="Z" surname="Zhang">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city></city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <phone></phone>
        <email>zhang.zheng@zte.com.cn</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
    
    <author fullname="Yuehua Wei" initials="Y" surname="Wei">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city></city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <phone></phone>
        <email>wei.yuehua@zte.com.cn</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></city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <phone></phone>
        <email>xu.benchong@zte.com.cn</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
    <date year="2022"/>
    <!-- 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>template</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>This document describes the IS-IS protocol extension that is required for BIER-TE with MPLS and non-MPLS encapsulation.</t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t><xref target="I-D.ietf-bier-te-arch" format="default"/> describes per-packet stateless strict and loose path steered replication and forwarding for "Bit Index Explicit Replication" (BIER, <xref target="RFC8279" format="default"/>) packets.  It is called BIER Tree Engineering (BIER-TE) and is intended to be used as the path steering mechanism for Traffic Engineering with BIER.</t>
      <t>BIER-TE introduces a new semantic for "bit positions" (BP) of link. <xref target="I-D.ietf-bier-te-isis" format="default"/> describes IS-IS extensions for distributing BitPositions configured on the links in "Bit Index Explicit Replication Traffic Engineering" (BIER-TE) domain.</t>
      <t>As described in section 2.3 in <xref target="I-D.ietf-bier-te-arch" format="default"/>, BIER-TE inherits the encapsulation supporting from BIER unchanged. The encapsulation defined in <xref target="RFC8296" format="default"/>, which specifies a common header format for both MPLS and non-MPLS networks, though the first 20-bits (referred to as BIFT-id) of the header is an "MPLS Label" in case of MPLS networks and is a local 20-bit opaque value in case of non-MPLS networks.</t>
      <t>As described in section 4.3 of <xref target="I-D.ietf-bier-te-arch" format="default"/>, it is necessary to distinguish the BIER and BIER-TE packet and forwarding. like <xref target="RFC8401" format="default"/> and <xref target="I-D.ietf-bier-lsr-non-mpls-extensions" format="default"/>, the MPLS and non-MPLS encapsulation needs to be advertised for BIER-TE packet encapsulation.</t>
      <t>This document describes the IS-IS protocol extension that is required for BIER-TE with MPLS and non-MPLS encapsulation associated with link BitPosition distributing.</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", "MAY", and "OPTIONAL" in this
       document are to be interpreted as described in <xref target="RFC2119" format="default"/>.</t>
      </section>
    </section>
    
    <section numbered="true" toc="default">
      <name>Terminology</name>
      <t>This document does not introduce more terminologies than <xref target="RFC8279" format="default"/>, <xref target="RFC8296" format="default"/>, <xref target="RFC8401" format="default"/>, <xref target="I-D.ietf-bier-te-arch" format="default"/> and <xref target="I-D.ietf-bier-te-isis" format="default"/>.</t>
    </section>
    
    <section numbered="true" toc="default">
      <name>Flooding of the BIER-TE Encapsulation Information in IS-IS</name>
      <t><xref target="I-D.ietf-bier-te-isis" format="default"/> defines a BIER-TE Info Sub-TLV to distribute the Link BitPosition information about the link. This document defines the MPLS Encapsulation Sub-sub-TLV and the Non-MPLS Encapsulation Sub-sub-TLV associate with the BIER-TE Sub-TLV to carry the MPLS and non-MPLS encapsulation information.</t>
      
      <t>In case both of the two encapsulation sub-sub-TLVs are advertised by one node, the label in MPLS encapsulation sub-sub-TLV and BIFT-id in non-MPLS encapsulation sub-sub-TLV SHOULD NOT be overlapped.</t>
      
      <section numbered="true" toc="default">
        <name>MPLS Encapsulation Sub-sub-TLV</name>
        <t>The following description is the almost same with <xref target="RFC8401" format="default"/> since <xref target="I-D.ietf-bier-te-arch" format="default"/> inherit the encapsulation of BIER header.</t>
        
        <figure anchor="Fig1">
        <artwork align="left" name="Figure 1" 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    |                     Label                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |BS Len |                     Reserved                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ]]></artwork>
      </figure>
        
        <dl newline="true" spacing="normal" indent="8">
        <dt>Type: TBD1 (To be assigned by IANA).</dt>
        <dd></dd>
        <dt>Length: 2-octet.</dt>
        <dd></dd>
        <dt>Max SI: A 1-octet field encoding the maximum Set Identifier (SI) (see Section 1 of <xref target="RFC8279" format="default"/>) used in the encapsulation for this BIER sub-domain for this BitString length.</dt>
        <dd></dd>
        <dt>Label: A 3-octet field, where the 20 rightmost bits represent the first label in the label range. The 4 leftmost bits MUST be ignored.</dt>
        <dd></dd>
        <dt>BS Len (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 Section 2 of <xref target="RFC8296" format="default"/>.</dt>
        <dd></dd>
        <dt>Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception.</dt>
        <dd></dd>
        </dl> 
        
      <t>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.</t>
      <t>The size of the label range is determined by the number of SIs (Section 1 of <xref target="RFC8279" format="default"/>) 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>If the label associated with the Maximum Set Identifier exceeds the 20-bit range, the BIER MPLS Encapsulation Sub-TLV containing the error MUST be ignored.</t>
      <t>If the BitString length is set to a value that does not match any of the allowed values specified in <xref target="RFC8296" format="default"/>, the BIER MPLS Encapsulation Sub-TLV containing the error MUST be ignored.</t>
      <t>The "BIFT-id range" is the set of 20-bit values beginning with the BIFT-id and ending with (BIFT-id + (Max SI)).</t>
      <t>The flooding scope of this information is the same with section 5 in <xref target="RFC8401" format="default"/>.</t>      
      </section>
      
      <section numbered="true" toc="default">
        <name>Non-MPLS Encapsulation Sub-sub-TLV</name>
        <t>The following description is the almost same with section 3.1 in <xref target="I-D.ietf-bier-lsr-non-mpls-extensions" format="default"/> since <xref target="I-D.ietf-bier-te-arch" format="default"/> inherit the encapsulation of BIER header.</t>
        
        <figure anchor="Fig2">
        <artwork align="left" name="Figure 2" 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    |                   BIFT-id                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |BS Len |                     Reserved                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ]]></artwork>
      </figure>
        
        <dl newline="true" spacing="normal" indent="8">
        <dt>Type: TBD2 (To be assigned by IANA).</dt>
        <dd></dd>
        <dt>Length: 2-octet.</dt>
        <dd></dd>
        <dt>Max SI: A 1-octet field encoding the maximum Set Identifier (SI) (see Section 1 of <xref target="RFC8279" format="default"/>) used in the encapsulation for this BIER sub-domain for this BitString length.</dt>
        <dd></dd>
        <dt>BIFT-id: A 3-octet field, where the 20 rightmost bits represent the first label in the label range. The 4 leftmost bits MUST be ignored.</dt>
        <dd></dd>
        <dt>BS Len (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 Section 2 of <xref target="RFC8296" format="default"/>.</dt>
        <dd></dd>
        <dt>Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception.</dt>
        <dd></dd>
        </dl> 
        
      <t>The BIFT-id range, limitation and flooding scope is the same with the MPLS encapsulation sub-sub-TLV.</t>  

        <section numbered="true" toc="default">
          <name>BIER-TE IPv6 Encapsulation Advertisement</name>
          <t>As described in section 4 of <xref target="I-D.ietf-bier-bierin6" format="default"/>, which describes how the existing BIER encapsulation specified in <xref target="RFC8296" format="default"/> works in a non-MPLS IPv6 network, a node that requires IPv6 encapsulation MUST advertise the BIER-TE IPv6 encapsulation sub-sub-sub-TLV, which follows the Non-MPLS Encapsulation Sub-sub-TLV, according to local configuration or policy in the BIER domain to request other BFRs to always use IPv6 encapsulation.</t>
          <figure anchor="Fig3">
          <artwork align="left" name="Figure 3" 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      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ]]></artwork>
          </figure>
        
          <dl newline="true" spacing="normal" indent="8">
          <dt>Type: TBD3 (To be assigned by IANA).</dt>
          <dd></dd>
          <dt>Length: 0.</dt>
          <dd></dd>
          </dl> 
        </section>
      </section>
    </section>
    
    <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>TBD.</t>
    </section>
    <section anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document does not introduce more security considerations than <xref target="I-D.ietf-bier-te-arch" format="default"/> and <xref target="I-D.ietf-bier-te-isis" format="default"/>.</t>
    </section>
  </middle>
  <!--  *****BACK MATTER ***** -->

 <back>

   <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <?rfc include="reference.RFC.2119.xml"?>	
        <?rfc include="reference.RFC.8279.xml"?>
        <?rfc include="reference.RFC.8296.xml"?>
        <?rfc include="reference.RFC.8401.xml"?>
        <?rfc include="reference.I-D.ietf-bier-te-arch.xml"?>
        <?rfc include="reference.I-D.ietf-bier-te-isis.xml"?>
        <?rfc include="reference.I-D.ietf-bier-lsr-non-mpls-extensions.xml"?>
        <?rfc include="reference.I-D.ietf-bier-bierin6.xml"?>
      </references>
    </references>
 </back>
</rfc>
