<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.zzhang-bier-rift SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-zzhang-bier-rift-00.xml">
<!ENTITY I-D.ietf-bier-non-mpls-bift-encoding SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-bier-non-mpls-bift-encoding-01.xml">
<!ENTITY I-D.ietf-bier-ospfv3-extensions SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-bier-ospfv3-extensions-00.xml">
<!ENTITY RFC1195 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1195.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2328 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2328.xml">
<!ENTITY RFC5120 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5120.xml">
<!ENTITY RFC5304 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5304.xml">
<!ENTITY RFC5305 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5305.xml">
<!ENTITY RFC5308 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5308.xml">
<!ENTITY RFC5310 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5310.xml">
<!ENTITY RFC7684 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7684.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8279 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8279.xml">
<!ENTITY RFC8296 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8296.xml">
<!ENTITY RFC8401 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8401.xml">
<!ENTITY RFC8444 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8444.xml">
<!ENTITY RFC8126 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml">
<!ENTITY RFC8362 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8362.xml">
]>
<rfc submissionType="IETF" updates="8296" docName="draft-ietf-bier-lsr-ethernet-extensions-01" category="std"><?rfc compact="yes"?>
    <?rfc text-list-symbols="o*+-"?>
    <?rfc subcompact="no"?>
    <?rfc sortrefs="yes"?>
    <?rfc symrefs="yes"?>
    <?rfc strict="yes"?>
    <?rfc toc="yes"?>
    
    <front>
       <title abbrev="LSR Extensions for BIER over Ethernet">LSR Extensions for BIER over Ethernet</title>
       <author fullname="Senthil Dhanaraj" initials="S" role="editor" surname="Dhanaraj">
         <organization>Huawei</organization>
         <address>
           <email>senthil.dhanaraj.ietf@gmail.com</email>
         </address>
       </author>
       <author fullname="IJsbrand Wijnands" initials="IJ" surname="Wijnands">
         <organization>Cisco Systems, Inc.</organization>
         <address>
           <email>ice@cisco.com</email>
         </address>
       </author>
       <author fullname="Peter Psenak" initials="P" surname="Psenak">
         <organization>Cisco Systems, Inc.</organization>
         <address>
           <email>ppsenak@cisco.com</email>
         </address>
       </author>
       <author fullname="Zhaohui Zhang" initials="Z" surname="Zhang">
         <organization>Juniper Networks.</organization>
         <address>
           <email>zzhang@juniper.net</email>
         </address>
       </author>
       <author fullname="Gang Yan" initials="G" surname="Yan">
         <organization>Huawei</organization>
         <address>
           <email>yangang@huawei.com</email>
         </address>
       </author>
       <author fullname="Jingrong Xie" initials="J" surname="Xie">
         <organization>Huawei</organization>
         <address>
           <email>xiejingrong@huawei.com</email>
         </address>
       </author>
       <date day="08" month="July" year="2019"/>
       <workgroup>Internet Engineering Task Force</workgroup>
       <abstract>
         <t>Bit Index Explicit Replication (BIER) is an architecture that provides 
       multicast forwarding through a "BIER domain" without requiring intermediate 
       routers to maintain multicast related per-flow state. BIER can be supported 
       in MPLS and non-MPLS networks. </t>
     
       <t>This document specifies the required extensions to the IS-IS, OSPFv2 and 
       OSPFv3  protocols for supporting BIER in non-MPLS networks using BIER in 
       Ethernet encapsulation.</t>
       </abstract>
    </front>

    <middle>
    <section title="Introduction" anchor="section-1">
       
         <t>Bit Index Explicit Replication (BIER) <xref target="RFC8279"/> is an 
       architecture that provides multicast forwarding through a "BIER domain"
       without requiring intermediate routers to maintain multicast related per-flow
       state. BIER can be supported in MPLS and non-MPLS networks.</t>
   
       <t><xref target="RFC8296"/> specifies a common BIER header format for both MPLS
       and non-MPLS networks, though the first 20-bits of the BIER header (referred as BIFT-id)
       is a "MPLS Label" in case of MPLS networks and is a "domain-wide-unique-value"
       representing the combination of SD-BSL-SI in case of non-MPLS networks.
       <xref target="I-D.ietf-bier-non-mpls-bift-encoding"/> specifies two optional ways
       of statically assigning domain-wide-unique mapping between BIFT-id's and SD-BSL-SI combination.</t>

       <t>However, BIER architecture [RFC8279] does not require domain-wide-unique BIFT-id's
          to be used (even for non-MPLS encapsulation). As discussed in
          <xref target="I-D.zzhang-bier-rift"/>, the BIFT-id in case of non-MPLS encapsulation
          can also just be a local 20-bit opaque value and signaled just like in MPLS case.
          This doucment updates section 2.2.1.1 of <xref target="RFC8296"/> that the BIFT-id 
          for a SD-BSL-SI in case of non-MPLS encapsulation need not be unique through out 
          the BIER domain. In such a case when the BIFT-id is not unique, the BIFT-id in the 
          packet is expected to change as the packet travels.
       </t>

       <t>
           As an example, suppose a particular BIER domain contains a SD
           (SD 0), supports two BSLs (256 and 512), and contains
           1024 BFRs.  A BFR that is provisioned for above SD, and that supports
           both BSLs, could advertise the following set of BIFT-id's:</t>
           
           <t><list style="hanging" hangIndent="3">
           <t hangText="">BIFT-id 1:   corresponding to SD 0, BSL 256, SI 0.</t>
           <t hangText="">BIFT-id 2:   corresponding to SD 0, BSL 256, SI 1.</t>
           <t hangText="">BIFT-id 3:   corresponding to SD 0, BSL 256, SI 2.</t>
           <t hangText="">BIFT-id 4:   corresponding to SD 0, BSL 256, SI 3.</t>
           <t hangText="">BIFT-id 5:   corresponding to SD 0, BSL 512, SI 0.</t>
           <t hangText="">BIFT-id 6:   corresponding to SD 0, BSL 512, SI 1.</t>
           </list></t>
           
           <t>Notice that the example uses ranges of continuous BIFT-id's:</t>
           
           <t><list style="hanging" hangIndent="3">
           <t hangText=""> BIFT-id range [1 to 4] correspond to &lt;SD 0, BSL 256&gt;. The first BIFT-id
           in the range correspond to SI=0, the second correspond to SI=1, and so on.</t>
           
           <t hangText="">BIFT-id range [5 to 6] correspond to &lt;SD 0, BSL 512&gt;. The first BIFT-id
           in the range correspond to SI=0, the second correspond to SI=1.</t>
           </list></t>

       <t>Strictly speaking, using contiguous range is not required, but it is done
          for the purpose of simplified
          signaling similar to MPLS label blocks (notice that locally assigning
          BIFT-id ranges requires no manual processing just like in the case of
          MPLS label block allocation).
       </t>

       <t>Processing and forwarding of BIER packets requires
       special software and hardware capabilities. The BFRs supporting a BIER encapsulation type MUST 
       advertise this capability (along with the other required parameters specific to the encapsulation)
       to the other routers in BIER domain. This advertisement, for example, will enable the other BFRs in the 
       BIER domain in deciding, whether to include or exclude the advertising router from the BAR and/or IPA 
       algorithm while computing the multicast path for a specific encapsulation type.</t>
  
       <t><xref target="RFC8401"/>, <xref target="RFC8444"/> and <xref target="I-D.ietf-bier-ospfv3-extensions"/> 
       specifies the required extensions to the IS-IS <xref target="RFC1195"/>, OSPFv2 <xref target="RFC2328"/> 
       and OSPFv3 <xref target="RFC8362"/> protocols respectively for the distribution of BIER sub-domain information 
       including the Sub-sub-TLV required to support BIER in MPLS encapsulation for MPLS networks.</t>
     
       <t>This document specifies the required extensions to the IS-IS <xref target="RFC1195"/>, 
       OSPFv2 <xref target="RFC2328"/> and OSPFv3 <xref target="RFC8362"/> protocols for supporting BIER using 
       BIER in Ethernet encapsulation with dynamically and locally assigned BIFT-id's.</t>
   
       <t>Support for other encapsulation types are outside the scope of this document.</t>

    </section>
    <section title="Terminology" anchor="section-2">
         
           <t>Some of the terminology specified in <xref target="RFC8279"/> is replicated here and
           extended by necessary definitions:</t>
        
             <t>
             <list style="hanging" hangIndent="3">
             
               <t hangText="BIER:">
               Bit Index Explicit Replication
               <vspace blankLines="0"/>
               (The overall architecture of forwarding multicast using a Bit Position).</t>
        
               <t hangText="BIER-MPLS:">
               BIER in MPLS encapsulation.
               <vspace blankLines="0"/>
                (Encapsulation of BIER header inside MPLS header in MPLS networks).
               </t>

               <t hangText="BIER-ETH:">
               BIER in Ethernet encapsulation.
               <vspace blankLines="0"/>
               (Encapsulation of BIER header inside Ethernet header (EtherType=0xAB37) in non-MPLS networks).
               </t>

               <t hangText="BFR:">
               Bit Forwarding Router (A router that participates in Bit Index
               <vspace blankLines="0"/>
               Multipoint Forwarding).  A BFR is identified by a unique BFR-
                 prefix in a BIER domain.
               </t>
        
               <t hangText="BIFT:">
               Bit Index Forwarding Table used to forward the BIER packets in a domain.
               <vspace blankLines="0"/>
               </t>
        
               <t hangText="BAR:">
               BIER Algorithm.  Used to calculate underlay nexthops
               <vspace blankLines="0"/>
               as defined by the BAR value.
               </t>

               <t hangText="IPA:">
               IGP Algorithm.  May be used to modify, enhance or replace the
               <vspace blankLines="0"/>
               calculation of underlay paths as defined by the BAR value
               </t>

               <t hangText="SD:">
               BIER sub-domain
               </t>

             </list>
             </t>
             
             <section title="Requirements Language" anchor="section-2.1">
              <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"/> <xref target="RFC8174"/> when, and only when,
             they appear in all capitals, as shown here.</t>
             </section>
             
    </section>
      <section title="Specification" anchor="section-3">

           <t> A BIER sub-domain MAY support multiple BIER encapsulation types like BIER-MPLS,
           BIER-ETH. The different encapsulation types supported by a BFR in a sub-domain MUST 
           share the same BFR-id. This would allow the BFR's in transit to translate the encapsulation 
           from one type to the other while forwarding the packet in the BIER sub-domain.</t>
           
           <t>When a BFIR/BFR supports multiple BIER encapsulation types, when sending to a
              BIER neighbor it MUST use a type that the neighbor also supports. If the neighbor
              also supports more than one encapsulation type that this BFIR/BFR supports,
              the type selection could be a matter of local policy and is outside the scope of this document.</t>

        <section title="IS-IS BIER Ethernet Encapsulation Sub-sub TLV" anchor="section-3.1">

               <t> BIER Info sub-TLV defined in <xref target="RFC8401"/> is used to advertise the sub-domain id,
               and other associated parameters of the sub-domain like BFR-id, MT, BAR, IPA.</t>

               <t> This document introduces new sub-sub-TLV under BIER Info sub-TLV to advertise the 
               ethernet encapsulation capability and other associated parameters of the encapsulation.</t>
               
               <t>This sub-sub-TLV carries the information for the BIER Ethernet
               encapsulation including the BitString length supported for a certain &lt;MT,SD&gt; pair.</t>
               
               <t>It is advertised within the BIER Info sub-TLV defined in <xref target="RFC8401"/> which
               in-turn is carried within the TLVs 235, 237 <xref target="RFC5120"/> or TLVs 135 <xref target="RFC5305"/>,
               or TLV 236 <xref target="RFC5308"/>.</t>
               
               <t>This sub-sub-TLV MAY appear multiple times within a single BIER Info sub-TLV.
               If the same BitString length is repeated in multiple BIER Ethernet encapsulation
               sub-sub-TLVs inside the same BIER Info sub-TLV, the BIER Info sub-TLV MUST be
               ignored.</t>

                <figure><artwork><![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              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 ]]></artwork>
                 </figure>
                
                 <t><list style="hanging" hangIndent="-1">
                 
                    <t hangText="Type:">
                    TBD1 (To be assigned by IANA).
                    <vspace blankLines="0"/>
                    </t>
                
                    <t hangText="Length:">
                    4
                    <vspace blankLines="0"/>
                    </t>
                
                    <t hangText="Max SI:">
                    A 1 octet field encoding the Maximum Set Identifier (Section 1 of [RFC8279])
                    used in the encapsulation for this BIER subdomain 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 Set Identifier exceeds the
                    20-bit range, the sub-sub-TLV MUST be ignored.
                    </t>
                
                    <t hangText="Local BitString Length (BS Len):">
                    A 4 bit field encoding the bitstring length (as per <xref target="RFC8296"/>)
                    supported for the encapsulation.
                    </t>
                
                    <t hangText="BIFT-id:">
                    A 20 bit field encoding the first BIFT-id of the BIFT-id range.
                    </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)). These BIFT-id's are used for BIER forwarding as 
                    described in <xref target="RFC8279"/> and <xref target="RFC8296"/>.</t>
 
                    <t>The size of the BIFT-id range is determined by the number of SI's
                    (Section 1 of <xref target="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>If the BIFT-id associated with the Maximum Set Identifier exceeds the
                    20-bit range, the BIER Ethernet Encapsulation Sub-sub-TLV containing the
                    error MUST be ignored.</t>
                    
                    <t>BIFT-id ranges within all the BIER Ethernet Encapsulation sub-sub-TLVs advertised
                    by the same BFR MUST NOT overlap.  If the overlap is detected, the advertising 
                    router MUST be treated as if it did not advertise any BIER Ethernet encapsulation
                    sub-sub-TLVs. However the BIFT-id ranges may overlap across different encapsulation 
                    types and is allowed. As an example, the BIFT-id value in the Ethernet encapsulation 
                    sub-sub-TLV may overlap with the Label value in the Label range in BIER MPLS 
                    encapsulation sub-sub-TLV (<xref target="RFC8401"/> and is allowed.</t>
                
                </list></t>
        </section>
        <section title="OSPFv2 BIER Ethernet Encapsulation Sub-TLV" anchor="section-3.2">

               <t> BIER Sub-TLV defined in <xref target="RFC8444"/> is used to advertise the sub-domain id,
               and other associated parameters of the sub-domain like BFR-id, MT, BAR, IPA.</t>

               <t> This document introduces new Sub-TLV under BIER Sub-TLV to advertise the 
               ethernet encapsulation capability and other associated parameters of the encapsulation.</t>
               
               <t>This Sub-TLV carries the information for the BIER Ethernet
               encapsulation including the BitString length supported for a certain &lt;MT,SD&gt; pair.</t>
               
               <t>It is advertised within the BIER Sub-TLV defined in <xref target="RFC8444"/> which
               in-turn is carried within the OSPFv2 Extended Prefix TLV defined in <xref target="RFC7684"/>.</t>
               
               <t>This Sub-TLV MAY appear multiple times within a single BIER Sub-TLV.
               If the same BitString length is repeated in multiple BIER Ethernet encapsulation
               Sub-TLVs inside the same BIER Sub-TLV, the BIER Sub-TLV MUST be
               ignored.</t>

                <figure><artwork><![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>
                
                 <t><list style="hanging" hangIndent="-1">
                 
                    <t hangText="Type:">
                    TBD2 (To be assigned by IANA).
                    <vspace blankLines="0"/>
                    </t>
                
                    <t hangText="Length:">
                    8
                    <vspace blankLines="0"/>
                    </t>
                
                    <t hangText="Max SI:">
                    A 1 octet field encoding the Maximum Set Identifier (Section 1 of [RFC8279])
                    used in the encapsulation for this BIER subdomain 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 Set Identifier exceeds the
                    20-bit range, the sub-sub-TLV MUST be ignored.
                    </t>
                
                    <t hangText="BIFT-id:">
                    A 3-octet field, where the 20 rightmost bits represent the first BIFT-id in 
                    the BIFT-id range.  The 4 leftmost bits 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)). These BIFT-id's are used
                    for BIER forwarding as described in <xref target="RFC8279"/> and <xref target="RFC8296"/>.</t>

                     <t>The size of the BIFT-id range is determined by the number of SI's
                    (Section 1 of <xref target="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>If the BIFT-id associated with the Maximum Set Identifier exceeds the
                    20-bit range, the BIER Ethernet Encapsulation Sub-sub-TLV containing the
                    error MUST be ignored.</t>
                    
                    <t>BIFT-id ranges within all the BIER Ethernet Encapsulation sub-sub-TLVs advertised
                    by the same BFR MUST NOT overlap.  If the overlap is detected, the advertising 
                    router MUST be treated as if it did not advertise any BIER Ethernet encapsulation
                    sub-sub-TLVs. However the BIFT-id ranges may overlap across different encapsulation 
                    types and is allowed. As an example, the BIFT-id value in the Ethernet encapsulation 
                    sub-sub-TLV may overlap with the Label value in the Label range in BIER MPLS 
                    encapsulation sub-sub-TLV (<xref target="RFC8444"/> and is allowed.</t>
                    
                    <t hangText="Local BitString Length (BS Len):">
                    A 4 bit field encoding the bitstring length (as per <xref target="RFC8296"/>)
                    supported for the encapsulation.
                    </t>
                    
                    <t hangText="Reserved:">
                    SHOULD be set to 0 on transmission and MUST be ignored on reception.
                    </t>
                
                </list></t>
        </section>        
        <section title="OSPFv3 BIER Ethernet Encapsulation Sub-TLV" anchor="section-3.3">

               <t> BIER Sub-TLV defined in <xref target="I-D.ietf-bier-ospfv3-extensions"/> 
               is used to advertise the sub-domain id, and other associated parameters of the 
               sub-domain like BFR-id, MT, BAR, IPA.</t>

               <t> This document introduces new Sub-TLV under BIER Sub-TLV to advertise the 
               ethernet encapsulation capability and other associated parameters of the encapsulation.</t>
               
               <t>This Sub-TLV carries the information for the BIER Ethernet
               encapsulation including the BitString length supported for a certain &lt;MT,SD&gt; pair.</t>
               
               <t>It is advertised within the BIER Sub-TLV defined in <xref target="I-D.ietf-bier-non-mpls-bift-encoding"/> 
               which in-turn is carried within the Intra-Area-Prefix TLV or Inter-Area-Prefix TLV in 
               OSPFv2 Extended LSA TLV defined in <xref target="RFC8362"/>.</t>
               
               <t>This Sub-TLV MAY appear multiple times within a single BIER Sub-TLV.
               If the same BitString length is repeated in multiple BIER Ethernet encapsulation
               Sub-TLVs inside the same BIER Sub-TLV, the BIER Sub-TLV MUST be
               ignored.</t>

                <figure><artwork><![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>
                
                 <t><list style="hanging" hangIndent="-1">
                 
                    <t hangText="Type:">
                    TBD3 (To be assigned by IANA).
                    <vspace blankLines="0"/>
                    </t>
                
                    <t hangText="Length:">
                    8
                    <vspace blankLines="0"/>
                    </t>
                
                    <t hangText="Max SI:">
                    A 1 octet field encoding the Maximum Set Identifier (Section 1 of [RFC8279])
                    used in the encapsulation for this BIER subdomain 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 Set Identifier exceeds the
                    20-bit range, the sub-sub-TLV MUST be ignored.
                    </t>
                
                    <t hangText="BIFT-id:">
                    A 3-octet field, where the 20 rightmost bits represent the first BIFT-id in 
                    the BIFT-id range.  The 4 leftmost bits 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)). These BIFT-id's are used
                    for BIER forwarding as described in <xref target="RFC8279"/> and <xref target="RFC8296"/>.</t>

                     <t>The size of the BIFT-id range is determined by the number of SI's
                    (Section 1 of <xref target="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>If the BIFT-id associated with the Maximum Set Identifier exceeds the
                    20-bit range, the BIER Ethernet Encapsulation Sub-sub-TLV containing the
                    error MUST be ignored.</t>
                    
                    <t>BIFT-id ranges within all the BIER Ethernet Encapsulation sub-sub-TLVs advertised
                    by the same BFR MUST NOT overlap.  If the overlap is detected, the advertising 
                    router MUST be treated as if it did not advertise any BIER Ethernet encapsulation
                    sub-sub-TLVs. However the BIFT-id ranges may overlap across different encapsulation 
                    types and is allowed. As an example, the BIFT-id value in the Ethernet encapsulation 
                    sub-sub-TLV may overlap with the Label value in the Label range in BIER MPLS 
                    encapsulation sub-sub-TLV (<xref target="I-D.ietf-bier-non-mpls-bift-encoding"/>
                    and is allowed.</t>
                    
                    <t hangText="Local BitString Length (BS Len):">
                    A 4 bit field encoding the bitstring length (as per <xref target="RFC8296"/>)
                    supported for the encapsulation.
                    </t>
                    
                    <t hangText="Reserved:">
                    SHOULD be set to 0 on transmission and MUST be ignored on reception.
                    </t>
                
                </list></t>
        </section>        

         </section>
      <section title="Security Considerations" anchor="section-4">
       
         <t>Security concerns for IS-IS are addressed in <xref target="RFC5304"/> and <xref target="RFC5310"/> and
       the security concerns for IS-IS extensions for BIER are addressed in <xref target="RFC8401"/>.
       This document introduces new sub-sub-TLV for the already existing IS-IS TLVs defined for
       distributing the BIER sub-domain information in <xref target="RFC8401"/>. It does not
       introduce any new security risks to IS-IS.</t> 
       
         <t>Security concerns and required extensions for OSPFv2 are addressed in <xref target="RFC2328"/> and
       <xref target="RFC7684"/> and the security concerns for OSPFv2 extensions for BIER are addressed in 
       <xref target="RFC8444"/>. This document introduces new Sub-TLV for the already existing OSPFv2 TLV defined for
       distributing the BIER sub-domain information in <xref target="RFC8444"/>. It does not
       introduce any new security risks to OSPFv2.</t>        

    </section>
    <section title="IANA Considerations" anchor="section-5">
       
             <t>The document requests new allocations from the IANA registries as
           follows</t>
        
             <section title="IS-IS sub-sub-TLVs for BIER Info sub-TLV Registry" anchor="section-5.1">
               <t>
               <list hangIndent="3" style="hanging">
                 <t>BIER Ethernet Encapsulation sub-sub-TLV: TBD1 (suggested value 2)</t>
               </list>
               </t>
             </section>
             <section title="OSPFv2 Extended Prefix TLV Sub-TLVs Registry" anchor="section-5.2">
               <t>
               <list hangIndent="3" style="hanging">
                 <t>BIER Ethernet Encapsulation Sub-TLV: TBD2 (suggested value 11)</t>
               </list>
               </t>
             </section>
             <section title="OSPFv3 Extended LSA Sub-TLVs Registry" anchor="section-5.3">
               <t>
               <list hangIndent="3" style="hanging">
                 <t>BIER Ethernet Encapsulation Sub-TLV: TBD3 (suggested value 11)</t>
               </list>
               </t>
             </section>
       </section>
    <section title="Acknowledgments" anchor="section-6">
         <t>The author wants to thank Antonie Przygienda for his comments and suggestions.</t>
       </section>
    </middle>

    <back>
      <references title="Normative References">
      &RFC2119;
      &RFC8279;
      &RFC8296;
      &RFC8401;
      &RFC8444;
      </references>    
      <references title="Informative References">
      &RFC1195;
      &RFC2328;
      &RFC5120;
      &RFC5304;
      &RFC5305;
      &RFC5308;
      &RFC5310;
      &RFC7684;
      &RFC8174;
      &RFC8362;
      &I-D.ietf-bier-non-mpls-bift-encoding;
      &I-D.ietf-bier-ospfv3-extensions;
      &I-D.zzhang-bier-rift;
      </references>
    </back>

    </rfc>
