<?xml version="1.0" encoding="US-ASCII"?>
<!-- <!DOCTYPE rfc SYSTEM "rfc2629.dtd"> -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std"
     docName="draft-ietf-bier-te-ospf-08"
     ipr="trust200902"
     submissionType="IETF"
     consensus="true">
  <front>
    <title abbrev="OSPF for BIER-TE">OSPF Extensions for BIER-TE</title>

     <author initials="H" surname="Chen" fullname="Huaimo Chen">
      <organization>Futurewei</organization>
      <address>
        <postal>
          <street></street>
          <city>Boston, MA</city>
          <region></region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>Huaimo.chen@futurewei.com</email>
      </address>
    </author>

    <author fullname="Mike McBride" initials="M" surname="McBride">
      <organization>Futurewei</organization>
      <address>
        <email>michael.mcbride@futurewei.com</email>
      </address>
    </author>


     <author initials="A" fullname="Aijun Wang" 
            surname="Wang">
      <organization>China Telecom</organization>
      <address>
        <postal>
          <street>Beiqijia Town, Changping District</street>
          <city>Beijing</city>
          <region> </region>
          <code>102209</code>
          <country>China</country>
        </postal>
        <email>wangaj3@chinatelecom.cn</email>
      </address>
    </author>

    <author fullname="Gyan S. Mishra" initials="G" surname="Mishra">
      <organization>Verizon Inc.</organization>
      <address>
        <postal>
          <street>13101 Columbia Pike</street>
          <city>Silver Spring</city>
          <code>MD 20904</code>
          <country>USA</country>
        </postal>
        <phone> 301 502-1347</phone>
        <email>gyan.s.mishra@verizon.com</email>
      </address>
    </author>

   <author initials="Y" fullname="Yanhe Fan" 
            surname="Fan">
      <organization>Casa Systems</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>yfan@casa-systems.com</email>
      </address>
    </author>

   <author initials="L" fullname="Lei Liu" 
            surname="Liu">
      <organization>Fujitsu</organization>
      <address>
        <postal>
          <street> </street>
          <city> </city>
          <region></region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>liulei.kddi@gmail.com</email>
      </address>
    </author>

   <author initials="X" fullname="Xufeng Liu" 
            surname="Liu">
      <organization>Alef Edge</organization>
      <address>
        <postal>
          <street> </street>
          <city> </city>
          <region> </region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>xufeng.liu.ietf@gmail.com</email>
      </address>
    </author>


    <date year="2023"/>

    <abstract>
      <t>This document describes OSPFv2 and OSPFv3 extensions for distributing 
         the BitPositions configured on a Bit-Forwarding Router (BFR) 
         in a "Bit Index Explicit Replication Traffic Engineering" 
         (BIER-TE) domain. 
      </t>
    </abstract>

    <note title="Requirements Language">
      <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"/> <xref target="RFC8174"/> 
      when, and only when, they appear in all capitals, as shown here.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
     <t><xref target="RFC9262"/> introduces Bit Index 
        Explicit Replication (BIER) Traffic/Tree Engineering (BIER-TE).
        It is an architecture for per-packet stateless explicit  
        point to multipoint (P2MP) multicast path/tree.
        There are three types of BitPositions (BPs) in a BIER-TE domain:
        link BitPosition (BP), routed BP and localdecap BP.

        A link BP is a BP configured on a link from 
        Bit-Forwarding Router (BFR) X to BFR Y
        for a forward connected adjacency from X to Y.

        A routed BP is a BP configured on BFR X
        for a forward routed adjacency from X to a remote BFR Z
        not directly connected to X.

        A localdecap BP is a BP configured on a BFR. 
        </t>

     <t><xref target="RFC8444"/> describes OSPFv2 Extensions for distributing
        the BFR identifier (BFR-id) configured on a BFR.

        <xref target="I-D.ietf-bier-ospfv3-extensions"/> 
        describes OSPFv3 Extensions for distributing
        the BFR identifier (BFR-id) configured on a BFR.

        This document specifies OSPFv2 and OSPFv3 extensions for distributing 
        the BitPositions configured a BFR
        in a BIER-TE domain.
        The BitPositions distributed may be used 
        by a BFR as a Point of Local Repair (PLR) for 
        Fast-ReRoute (FRR).</t>

<!--
    <section title="Terminology">
      <t>
      <list style="hanging" hangIndent="6">
       <t hangText="BIER:">Bit Index Explicit Replication.</t>
       <t hangText="BIER-TE:">BIER Traffic Engineering.</t>
       <t hangText="BFR:">Bit-Forwarding Router.</t>
       <t hangText="BFR-id:">BFR Identifier. 
          It is a number in the range [1,65535].</t>
-->
<!--
       <t hangText="BFR-NBR:">BFR Neighbor.</t>
       <t hangText="BFR-prefix:">An IP address (either IPv4 or IPv6) of a BFR.</t>
       <t hangText="BIRT:">Bit Index Routing Table. 
          It is a table that maps from the BFR-id (in a particular sub-domain)
          of a BFER to the BFR-prefix of that BFER, and to the BFR-NBR 
          on the path to that BFER.</t>
       <t hangText="BIFT:">Bit Index Forwarding Table.</t>
-->
<!--
      </list></t>
    </section>
-->
 <!-- Terminology -->

    </section> <!-- Introduction -->


   <section title="Extensions to OSPFv2">
     <t>This section describes protocol extensions to OSPFv2
        for distributing 
        the BitPositions configured on a BFR in 
        a BIER-TE domain.</t>



<!--
           <figure anchor="bier-sub-tlv" 
           title="BIER Sub-TLV">
  <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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | sub-domain-id |     MT-ID     |              BFR-id           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    BAR        |    IPA        |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Sub-TLVs (variable)                      |
   +-                                                             -+
   |                                                               |]]></artwork>
</figure>
</t>
     <t>
      <list style="hanging" hangIndent="6">
         <t hangText="Type:">9.</t>
         <t hangText="Length:">Variable, dependent on sub-TLVs.</t>
         <t hangText="sub-domain-id:">Unique value identifying the BIER 
            sub-domain within the BIER domain.</t>
         <t hangText="MT-ID:">Multi-Topology ID identifying the topology 
            that is associated with the BIER sub-domain.</t>
         <t hangText="BFR-id:">A 2-octet field encoding the BFR-id. 
            If the BFR is not locally configured with a valid BFR-id,
            the value of this field is set to 0, which is defined as
            illegal in <xref target="RFC8279"/>.</t>
         <t hangText="BAR:">Single-octet BIER Algorithm used to calculate 
            underlay paths to reach other BFRs. Values are allocated
            from the "BIER Algorithm" registry defined in 
            <xref target="RFC8401"/>.</t>
         <t hangText="IPA:">Single-octet IGP Algorithm used to either modify,
            enhance, or replace the calculation of underlay paths to reach 
            other BFRs as defined by the BAR value.  Values are defined
            in the "IGP Algorithm Types" registry.</t>
      </list>
     </t>

     <t>Under BIER Sub-TLV, a sub-TLV, called BIER MPLS Encapsulation Sub-TLV,
        is defined to advertise MPLS-specific information used for BIER.
        It has the following format.
           <figure anchor="bier-mpls-encap-sub-tlv" 
           title="BIER MPLS Encapsulation Sub-TLV">
  <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    |                     Label                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |BS Len |                     Reserved                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
     </t>

     <t>
      <list style="hanging" hangIndent="6">
         <t hangText="Type:">10.</t>
         <t hangText="Length:">8 octets.</t>
         <t hangText="Max SI:">A 1-octet field encoding the maximum Set 
            Identifier (SI) used in the encapsulation for this
            BIER sub-domain for this BitString length.</t>
         <t hangText="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.</t>
         <t hangText="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 
            [RFC8296]. BitString length = 2^(5+k), where k is BS Len.
            For example, BS Len = 1, means BitString Length is 64 bits.
            BS Len = 2, means BitString Length is 128 bits.</t>
         <t hangText="Reserved:">SHOULD be set to 0 on transmission and MUST 
            be ignored on reception.</t>
      </list>

      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 format of the OSPFv2 Extended Prefix Opaque LSA is as follows:
           <figure anchor="ospfv2-prefix-olsa" 
           title="OSPFv2 Extended Prefix Opaque LSA">
  <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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |               LS age          |     Options   |    LS Type    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Opaque Type(7)|                  Opaque ID                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                          Advertising Router                   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                          LS sequence number                   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          LS checksum          |            Length             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +-                               TLVs                          -+
  |                                ...                            |]]></artwork>
</figure>
     </t>

     <t>The OSPFv2 Extended Prefix TLV has the following format: 
           <figure anchor="ospfv2-prefix-tlv" 
           title="OSPFv2 Extended Prefix TLV">
  <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 (1)           |      Length (Variable)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Route Type  | Prefix Length |       AF      |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Address Prefix (variable)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Sub-TLVs (variable)                     |
   +-                               TLVs                          -+
   |                                ...                            |]]></artwork>
</figure>
     </t>

     <t>
      <list style="hanging" hangIndent="6">
         <t hangText="Type:">1.</t>
         <t hangText="Length:">Variable.</t>
         <t hangText="Route Type:">The type of the OSPFv2 route. 
            0 - Unspecified, 1 - Intra-Area, 3 - Inter-Area, 
            5 - Autonomous System (AS) External, 
            7 - Not-So-Stubby Area (NSSA) External.</t>
         <t hangText="Prefix Length:">Length of prefix in bits.</t>
         <t hangText="AF:">Address family for the prefix. Currently, 
            the only supported value is 0 for IPv4 unicast.</t>
         <t hangText="Flags:">This one-octet field contains flags 
            applicable to the prefix. Supported Flags include: 
            0x80 - A-Flag (Attach Flag): An Area Border Router (ABR)
            generating an OSPFv2 Extended Prefix TLV for an inter-area
            prefix that is locally connected or attached in another
            connected area SHOULD set this flag.
            0x40 - N-Flag (Node Flag): Set when the prefix identifies the
            advertising router, i.e., the prefix is a host prefix
            advertising a globally reachable address typically associated
            with a loopback address. The advertising router MAY choose to
            not set this flag even when the above conditions are met. If
            the flag is set and the prefix length is not a host prefix,
            then the flag MUST be ignored. The flag is preserved when the
            OSPFv2 Extended Prefix Opaque LSA is propagated between areas.</t>
         <t hangText="Prefix Length:">Length of prefix in bits.</t>
         <t hangText="Address Prefix:">For the address family IPv4 unicast, 
            the prefix itself is encoded as a 32-bit value. The default 
            route is represented by a prefix of length 0.</t>
      </list>
    </t>


     <t>The format of the OSPFv2 Extended Link Opaque LSA is as follows:
           <figure anchor="ospfv2-link-olsa" 
           title="OSPFv2 Extended Link Opaque LSA">
  <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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |               LS age          |    Options    |    LS Type    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Opaque Type(8)|                   Opaque ID                   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                          Advertising Router                   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                          LS sequence number                   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          LS checksum          |            Length             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +-                               TLVs                          -+
  |                                ...                            |]]></artwork>
</figure>
     </t>
-->

    <section anchor="linkBP" title="Link BitPosition">
     <t>This section defines a Sub-TLV for distributing a link
        BitPosition (BP). </t>

     <t><xref target="RFC7684"/> defines the OSPFv2 Extended Link TLV
        to advertise the information about a link.
Only one OSPFv2 Extended Link TLV SHALL be advertised in each OSPFv2
Extended Link Opaque LSA.
 
        The OSPFv2 Extended Link TLV has the following format: 

           <figure anchor="ospfv2-link-tlv" 
           title="OSPFv2 Extended Link TLV">
  <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 (1)           |      Length (Variable)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Link Type   |                    Reserved                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Link ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Link Data                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Sub-TLVs (variable)                     |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
 
      <list style="hanging" hangIndent="6">
         <t hangText="Type:">1.</t>
         <t hangText="Length:">Variable, dependent on Sub-TLVs.</t>
         <t hangText="Link Type, Link ID and Link Data:">
            They are defined in Section A.4.2 of 
            <xref target="RFC2328"/>.</t>
<!--
         <t hangText="Link Type:"> 
            1 - Point-to-Point connection to another router,
            2 - Transit Network (or say LAN or broadcast link),
            3 - Stub Network,
            4 - Virtual Link.</t>
         <t hangText="Link ID:"> 
            Identifies the object that this router 
            link connects to. Value depends on the link's Type.
            For Link Type 1, it is Neighboring router's Router ID, 
            2, IP address of Designated Router
            3, IP network/subnet number
            4, Neighboring router's Router ID.</t>
         <t hangText="Link Data:">Value again depends on Link Type. 
            For Link Type 3, it is network's IP address mask. 
            For unnumbered point-to-point connections, it is
                the interface's MIB-II ifIndex. 
            For the other link types (1, 2, 4), 
                it is the router interface's IP address.</t>
-->
         <t hangText="Reserved:">MUST be set to 0 on transmission and MUST 
            be ignored on reception.</t>
      </list> 
     </t>

      <t>
         Under the OSPFv2 Extended Link TLV for a link,
         a Sub-TLV, called Link-BP Sub-TLV, is
         defined for distributing a link BitPosition. 
         A Link-BP Sub-TLV is included in the Link TLV for a link of 
         Link Type P2P (Point-to-Point) or Broadcast 
         (or say LAN or Transit Network).

         The Link-BP Sub-TLV has the following format:

           <figure anchor="link-bp-sub-tlv" 
           title="Link-BP Sub-TLV">
  <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 (TBD1)          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | sub-domain-id |     MT-ID     |      BAR      |    IPA        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         BitPosition           |         DrEndBitPosition      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
</t>
     <t>
      <list style="hanging" hangIndent="6">
         <t hangText="Type:">TBD1 is to be assigned by IANA.</t>
         <t hangText="Length:">Variable.</t> 

         <t hangText="sub-domain-id, MT-ID, BAR and IPA:">They are defined in  
            Section 2.1 of <xref target="RFC8444"/>.</t>

<!--
         <t hangText="sub-domain-id:">Unique value identifying a BIER-TE 
            sub-domain.</t>
         <t hangText="MT-ID:">Multi-Topology ID identifying the topology 
            that is associated with the BIER-TE sub-domain.</t>
         <t hangText="BAR:">Single-octet BIER Algorithm used to calculate 
            underlay paths to reach other BFRs. Values are allocated
            from the "BIER Algorithm" registry defined in 
            <xref target="RFC8401"/>.</t>
         <t hangText="IPA:">Single-octet IGP Algorithm used to either modify,
            enhance, or replace the calculation of underlay paths to reach 
            other BFRs as defined by the BAR value.  Values are defined
            in the "IGP Algorithm Types" registry.</t>
-->
         <t hangText="BitPosition:">A 2-octet field encoding the BitPosition
            locally configured on the link/interface when the Link Type of 
            the link in the OSPFv2 Extended Link TLV containing this Sub-TLV
            is 1 (i.e., Point-to-Point connection to another router) or 
            2 (i.e., connection to Transit Network or say LAN).
            </t>
         <t hangText="DrEndBitPosition:">A 2-octet field encoding the BitPosition
            of the connection on the designated router (DR) end. This field
            exists when the Link Type in the OSPFv2 Extended Link TLV 
            containing this Sub-TLV is 2 (i.e., Transit Network or LAN). 
            For the other value of the Link Type, this field MUST NOT exist. The 
            DrEndBitPosition may be configured on 
            the link/interface to a transit network 
            (i.e., broadcast link or say LAN) as described in 
            <xref target="I-D.chen-bier-te-lan"/>.</t>
      </list>
     </t>
    </section>


    <section anchor="rtBPs" title="Routed and Localdecap BitPositions">
     <t>A TLV, called Node BPs TLV, is defined within 
        the body of the OSPF Router Information (RI) Opaque 
        Link State Advertisement (LSA) <xref target="RFC7770"/>. 
        The TLV contains Sub-TLVs. Two types of Sub-TLVs are defined. 
        One is for a Routed BitPosition and 
        the other for a Localdecap BitPosition.</t>  

     <t>The Node BPs TLV has the following format:
           <figure anchor="node-bps-tlv" 
           title="Node BPs TLV">
  <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 (TBD2)          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | sub-domain-id |     MT-ID     |      BAR      |    IPA        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Sub-TLVs                           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
</t>
     <t>
      <list style="hanging" hangIndent="6">
         <t hangText="Type:">TBD2 is to be assigned by IANA.</t>
         <t hangText="Length:">Variable.</t>
         <t hangText="sub-domain-id, MT-ID, BAR and IPA:">They are defined in  
            Section 2.1 of <xref target="RFC8444"/>.</t>
         <t hangText="Sub-TLVs:">They are Routed-BP Sub-TLVs for Routed BPs
            and/or Localdecap-BP Sub-TLV for Localdecap BP.</t>
      </list>
     </t>

     <t>The Routed-BP Sub-TLV has the following format:
           <figure anchor="rt-bp-sub-tlv" 
           title="Routed-BP Sub-TLV">
  <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 (1)            |           Length(4)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         BitPosition           |             BFR-id            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
</t>
     <t>
      <list style="hanging" hangIndent="6">
         <t hangText="Type:">1 is the type for routed BP.</t>
         <t hangText="Length:">It is 4.</t>
         <t hangText="BitPosition:">A 2-octet field encoding the BitPosition
            configured on a BFR for a forward routed adjacency to a remote BFR.
            </t>
         <t hangText="BFR-id:">A 2-octet field encoding the BFR-id of 
            the remote BFR.</t>
      </list>
     </t>

     <t>The Localdecap-BP Sub-TLV has the following format:
           <figure anchor="ld-bp-sub-tlv" 
           title="Localdecap-BP Sub-TLV">
  <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 (2)            |           Length(2)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         BitPosition           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
</t>
     <t>
      <list style="hanging" hangIndent="6">
         <t hangText="Type:">2 is the type for localdecap BP.</t>
         <t hangText="Length:">It is 2.</t>
         <t hangText="BitPosition:">A 2-octet field encoding the 
            localdecap BitPosition configured on a BFR.</t>
      </list>
     </t>

    </section>
   </section> <!--  Extensions to OSPFv2 -->



   <section title="Extensions to OSPFv3">
     <t>This section describes protocol extensions to OSPFv3
        for distributing the BitPositions configured on a BFR in 
        a BIER-TE domain.</t>

     <section anchor="linkBPv3" title="Link BitPosition">
  
      <t><xref target="RFC8362"/> defines OSPFv3 Extended Router LSA,
         which may include multiple Router-Link TLVs.
<!--
           <figure anchor="e-router-lsa" 
           title="Extended Router-LSA">
  <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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              LS Age         |1|0|1|             0x21          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        Link State ID                          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Advertising Router                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      LS Sequence Number                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        LS Checksum          |             Length              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  0  |N|x|V|E|B|                  Options                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  .                                                               .
  .                              TLVs                             .
  .                                                               .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
-->
         A Router-Link TLV defines a single router link.
<!--
           <figure anchor="router-link-tlv-v3" 
           title="Router-Link TV">
  <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 (1 - Router-Link)    |         Length (Variable)       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Link Type  |       0       |              Metric             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        Interface ID                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    Neighbor Interface ID                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Neighbor Router ID                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  .                                                               .
  .                          Sub-TLVs                             .
  .                                                               .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
-->
         A Router-Link TLV 
         may include a Link-BP Sub-TLV below  
         for distributing a link BP.

           <figure anchor="link-bp-sub-tlv-v3" 
           title="Link-BP Sub-TLV in Router-Link TLV">
  <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 (TBD3)          |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | sub-domain-id |     MT-ID     |      BAR      |    IPA        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         BitPosition           |         DrEndBitPosition      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
      <list style="hanging" hangIndent="6">
         <t hangText="Type:">TBD3 is to be assigned by IANA.</t>
         <t hangText="Length:"> Variable.</t>
<!--
            For a Point to Point (P2P) link, 
            it is 6 since there is no DrEndBitPosition.
            For a broadcast link, it is 8 since there is a DrEndBitPosition.</t>
-->
         <t hangText="sub-domain-id, MT-ID, BAR and IPA:">They are defined in 
            Section 2.1 of <xref target="I-D.ietf-bier-ospfv3-extensions"/>.</t>
<!--
         <t hangText="sub-domain-id:">Unique value identifying a BIER-TE 
            sub-domain.</t>
         <t hangText="MT-ID:">Multi-Topology ID identifying the topology 
            that is associated with the BIER-TE sub-domain.</t>
         <t hangText="BAR:">Single-octet BIER Algorithm used to calculate 
            underlay paths to reach other BFRs. Values are allocated
            from the "BIER Algorithm" registry defined in 
            <xref target="RFC8401"/>.</t>
         <t hangText="IPA:">Single-octet IGP Algorithm used to either modify,
            enhance, or replace the calculation of underlay paths to reach 
            other BFRs as defined by the BAR value.  Values are defined
            in the "IGP Algorithm Types" registry.</t>
-->
         <t hangText="BitPosition:">A 2-octet field encoding the BitPosition
            locally configured on the link/interface when the Link Type of 
            the link in the Router-Link TLV containing this Sub-TLV
            is 1 (i.e., Point-to-Point connection to another router) or 
            2 (i.e., connection to Transit Network or say LAN).
            </t>
         <t hangText="DrEndBitPosition:">A 2-octet field encoding the BitPosition
            of the connection on the designated router (DR) end. This field
            exists when the Link Type in the Router-Link TLV 
            containing this Sub-TLV is 2 (i.e., Transit Network or LAN). 
            For the other value of the Link Type, this field MUST NOT exist. The 
            DrEndBitPosition may be configured on 
            the link/interface to a transit network 
            (i.e., broadcast link or say LAN) as described in 
            <xref target="I-D.chen-bier-te-lan"/>.</t>
      </list>
     </t>
    </section>


    <section anchor="rtBPsv3" title="Routed and Localdecap BitPositions">
     <t>The Node BPs TLV, Routed BP Sub-TLV and Localdecap BP Sub-TLV
        defined in <xref target="rtBPs"/> 
        are reused in OSPVv3 for distributing the routed BitPositions  
        and the localdecap BitPosition configured on a BFR. 
        </t>
<!--
     <t>A TLV, called Node BPs TLV, is defined within 
        the body of the OSPF Router Information (RI) Opaque 
        Link State Advertisement (LSA) <xref target="RFC7770"/>. 
        The TLV contains Sub-TLVs. Two types of Sub-TLVs are defined. 
        One is for a Routed BitPosition and 
        the other for a Localdecap BitPosition.</t>  


     <t>The Node BPs TLV has the following format:
           <figure anchor="node-bps-tlv-v3" 
           title="Node BPs TLV">
  <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 (TBD2)          |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | sub-domain-id |     MT-ID     |      BAR      |    IPA        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Sub-TLVs                           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
</t>
     <t>
      <list style="hanging" hangIndent="6">
         <t hangText="Type:">TBD2 is to be assigned by IANA.</t>
         <t hangText="Length:">Variable.</t>
         <t hangText="sub-domain-id, MT-ID, BAR and IPA:">They are defined in 
            Section 2.1 of <xref target="I-D.ietf-bier-ospfv3-extensions"/>.</t>
         <t hangText="Sub-TLVs:">They are Routed-BP Sub-TLVs for Routed BPs
            and/or Localdecap-BP Sub-TLV for Localdecap BP.</t>
      </list>
     </t>

     <t>The Routed-BP Sub-TLV has the following format:
           <figure anchor="rt-bp-sub-tlv" 
           title="Routed-BP Sub-TLV">
  <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 (TBDa)          |           Length(4)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         BitPosition           |             BFR-id            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
</t>
     <t>
      <list style="hanging" hangIndent="6">
         <t hangText="Type:">TBDa is to be assigned by IANA.</t>
         <t hangText="Length:">It is 4.</t>
         <t hangText="BitPosition:">A 2-octet field encoding the BitPosition
            configured on a BFR for a forward routed adjacency to a remote BFR.
            </t>
         <t hangText="BFR-id:">A 2-octet field encoding the BFR-id of 
            the remote BFR.</t>
      </list>
     </t>

     <t>The Localdecap-BP Sub-TLV has the following format:
           <figure anchor="ld-bp-sub-tlv" 
           title="Localdecap-BP Sub-TLV">
  <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 (TBDb)          |           Length(2)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         BitPosition           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
</t>
     <t>
      <list style="hanging" hangIndent="2">
         <t hangText="Type:">TBDb is to be assigned by IANA.</t>
         <t hangText="Length:">It is 6.</t>
         <t hangText="BitPosition:">A 2-octet field encoding the 
            localdecap BitPosition configured on a BFR.</t>
      </list>
     </t>
-->
    </section>
    </section> <!--  Extensions to OSPFv3 -->




    <section anchor="Security" title="Security Considerations">
      <t>Protocol extensions defined in this document do not 
      affect the OSPF security other than those as discussed 
      in the Security Considerations section of 
      <xref target="RFC7684"/> and <xref target="RFC8362"/>.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">

      <section title="OSPFv2">
      <t>Under "OSPFv2 Extended Link TLV Sub-TLVs" registry as defined
         in <xref target="RFC7684"/>, IANA is
         requested to assign a new registry value for 
         Link-BP Sub-TLV as follows:

<figure>
  <artwork>  +==============+===================+=====================+
  |  Value       |  Description      |    reference        |
  +==============+===================+=====================+
  |  TBD1 (25)   |  Link-BP          |    This document    |
  +--------------+-------------------+---------------------+
  </artwork>
</figure>
</t>

    <t>Under "OSPF Router Information (RI) TLVs" registry as defined
        in <xref target="RFC7770"/>, IANA is
         requested to assign a new registry value for 
         Node BPs TLV as follows:

<figure>
  <artwork>  +==============+===================+=====================+
  |  Value       |  Description      |    reference        |
  +==============+===================+=====================+
  |  TBD2 (21)   |  Node BPs         |    This document    |
  +--------------+-------------------+---------------------+
  </artwork>
</figure>

      IANA is requested to create a new subregistry called the 
      "OSPF Node BPs Sub-TLVs" under the 
      "Open Shortest Path First (OSPF) Parameters" registry. 
      The initial values are as follows:
<figure>
  <artwork>  +===========+===================+========================+
  |  Value    |  Description      |    reference           |
  +===========+===================+========================+
  |    0      |  Reserved         |    This document       |
  +-----------+-------------------+------------------------+
  |    1      |  Routed BP        |    This document       |
  +-----------+-------------------+------------------------+
  |    2      |  Localdecap BP    |    This document       |
  +-----------+-------------------+------------------------+
  | 3 - 65535 |  To be allocated in First Come First Served|
  +-----------+-------------------+------------------------+
  </artwork>
</figure>
</t>
    </section>

    <section title="OSPFv3">
      <t>Under "OSPFv3 Extended-LSA Sub-TLVs" registry as defined
         in <xref target="RFC8362"/>, IANA is
         requested to assign a new registry value for 
         Link-BP Sub-TLV as follows:

<figure>
  <artwork>
  +==============+===================+=====================+
  |  Value       |  Description      |    reference        |
  +==============+===================+=====================+
  |  TBD3 (30)   |  Link-BP          |    This document    |
  +--------------+-------------------+---------------------+
  </artwork>
</figure>
</t>
    </section>
<!-- OSPFv3 -->
    </section>

  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
      <?rfc include="reference.RFC.8174"?>
      <!-- <?rfc include="reference.RFC.8279"?> -->
      <?rfc include="reference.RFC.7684"?>
      <?rfc include="reference.RFC.8362"?>
      <?rfc include="reference.RFC.7770"?>
      <?rfc include="reference.RFC.2328"?>
      <?rfc include="reference.RFC.9262"?>
    </references>

    <references title="Informative References">
      <!-- <?rfc include="reference.RFC.8296"?> -->
      <?rfc include="reference.RFC.8444"?>
      <?rfc include="reference.RFC.8401"?>
      <?rfc include="reference.I-D.ietf-bier-ospfv3-extensions"?>
      <?rfc include="reference.I-D.chen-bier-te-lan"?>
    </references>


    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t>The authors would like to thank Acee Lindem, Les Ginsberg,
         Tony Przygienda, Jeffrey Zhang and 
         Toerless Eckert for their comments on this work.</t>
    </section>
  </back>

</rfc>
