<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-ietf-bier-mldp-signaling-over-bier-04"
     ipr="trust200902">
  <front>
    <title abbrev="M-LDP Signaling Through BIER Core">M-LDP Signaling Through
    BIER Core</title>

    <author fullname="Hooman Bidgoli" initials="H" role="editor"
            surname="Bidgoli">
      <organization>Nokia</organization>

      <address>
        <postal>
          <street/>

          <city>Ottawa</city>

          <region/>

          <code/>

          <country>Canada</country>
        </postal>

        <phone/>

        <email>hooman.bidgoli@nokia.com</email>
      </address>
    </author>

    <author fullname="IJsbrand Wijnands" initials="I." surname="Wijnands">
      <organization>Cisco System</organization>

      <address>
        <postal>
          <street/>

          <city>Diegem</city>

          <region/>

          <code/>

          <country>Belgium</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>ice@cisco.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Mankamana Mishra" initials="M." surname="Mishra">
      <organization>Cisco System</organization>

      <address>
        <postal>
          <street/>

          <city>Milpitas</city>

          <region/>

          <code/>

          <country>USA</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>mankamis@cisco.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Zhaohui Zhang" initials="Z." surname="Zhang">
      <organization>Juniper Networks</organization>

      <address>
        <postal>
          <street/>

          <city>Boston</city>

          <region/>

          <code/>

          <country>USA</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>zzhang@juniper.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Eddie Leyton" initials="E." surname="Leyton">
      <organization>Verizon</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

        <email>Edward.leyton@verizonwireless.com</email>

        <uri/>
      </address>
    </author>

    <date day="5" month="February" year="2025"/>

    <abstract>
      <t>Consider an end-to-end Multipoint LDP (mLDP) network, where it is
      desirable to deploy BIER in a segment of this network. It might be
      desirable to deploy BIER with minimal disruption to the mLDP network or
      a redesign of the network.</t>

      <t>This document describes a procedure needed for mLDP tunnels to be
      signaled over and stitched through a BIER core, allowing LDP routers to
      run traditional mLDP services through a BIER core.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <!-- 1 -->

      <t>Some operators that are using mLDP P2MP LSPs for their multicast
      transport would like to deploy BIER technology in some segments of their
      network. As an example, if a operator is simplifying their core network
      with IGP underlay and BGP overlay and migrating from LDP to Segment
      Routing, they might prefer BIER in this segment of network for Multicast
      technology as BIER uses IGP underlay. The operator might still want to
      legacy multicast protocols like mLDP on the access of the network and
      offer end to end multicast services. This draft explains a method to
      signal mLDP services through a BIER domain, with minimal disruption and
      operational impact to the mLDP domain.</t>
    </section>

    <section title="Conventions used in this document">
      <!-- 2 -->

      <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"/>.</t>

      <section title="Definitions">
        <!-- 2.1 -->

        <t>Some of the terminology specified in <xref target="RFC8279"/>is
        replicated here and extended by necessary definitions:</t>

        <t>BIER:</t>

        <t>Bit Index Explicit Replication, The overall architecture of
        forwarding multicast using a Bit Position.</t>

        <t>BFR:</t>

        <t>Bit Forwarding Router, A router that participates in Bit Index
        Multipoint Forwarding. A BFR is identified by a unique BFR prefix in a
        BIER domain.</t>

        <t>BFIR:</t>

        <t>Bit-Forwarding Ingress Router, The ingress border router that
        inserts the Bit Map into the packet. Each BFIR must have a valid
        BFR-id assigned. BFIR is a term used for data plane packet
        forwarding.</t>

        <t>BFER:</t>

        <t>Bit-Forwarding Egress Router, A router that participates in Bit
        Index Forwarding as leaf. Each BFER must have a valid BFR-id assigned.
        BFER is a term used for data plane packet forwarding.</t>

        <t>BBR:</t>

        <t>BIER Boundary router. The router between the LDP domain and BIER
        domain.</t>

        <t>IBBR:</t>

        <t>Ingress BIER Boundary Router. The ingress router from a signaling
        point of view. It maintains mLDP adjacency toward the LDP domain and
        determines if the Multipoint LDP FEC needs to be signaled across the
        BIER domain via Targeted LDP.</t>

        <t>EBBR:</t>

        <t>Egress BIER Boundary Router. The egress router in a BIER domain
        from signaling point of view. It terminates the targeted LDP signaling
        through the BIER domain. It also keeps track of all IBBRs that are
        part of this P2MP tree</t>

        <t>BIFT:</t>

        <t>Bit Index Forwarding Table.</t>

        <t>BIER sub-domain:</t>

        <t>A further distinction within a BIER domain identified by its unique
        sub-domain identifier. A BIER sub-domain can support multiple
        BitString Lengths.</t>

        <t>BFR-id:</t>

        <t>An optional, unique identifier for a BFR within a BIER sub-domain,
        all BFERs and BFIRs need to be assigned a BFR-id.</t>

        <t>ILM:</t>

        <t>MPLS Incoming Label Map.</t>
      </section>
    </section>

    <section title="mLDP Signaling Through BIER domain">
      <!-- 3 -->

      <figure anchor="Control-Plane" title="BIER boundary router">
        <artwork align="center"><![CDATA[
                    BBR                   BBR
     |---LDP Domain--|-----BIER domain-----|---LDP domain--| 
S--( A )-----------( B ) ---- ( C ) ---- ( D )-----------( E )--h


                   EBBR                  IBBR
Sig  <----MLDP------|<----targeted LDP----|<---MLDP------
(new)

                  BFIR                  BFER
     ------------->|--------BIER-------->|------------->  Datapatah
                                                           (new)]]></artwork>
      </figure>

      <t>As per above figure, point-to-multipoint and multipoint-to-multipoint
      LSPs established via mLDP <xref target="RFC6388"/> can be signaled
      through a bier domain via Targeted LDP sessions. The procedure of using
      LDP Multipoint Extensions on Targeted LDP session is explained in <xref
      target="RFC7060"/>.</t>

      <t>This document provides additional details and defines some needed
      procedures to use LDP Multipoint Extensions on Targeted LDP as per <xref
      target="RFC7060"/> to connect two or more mLDP domains over a BIER
      domain.</t>

      <section title="Ingress BBR procedure">
        <!-- 3.1 -->

        <t>In above Figure, the Ingress BBR (IBBR) is connected to the mLDP
        domain on downstream and a BIER domain on the upstream. To connect the
        LDP domains via the BIER domain, IBBR needs to establish a targeted
        LDP session with EBBR closest to the root of the P2MP or MP2MP LSP. To
        do so IBBR will follow procedures in <xref target="RFC7060"/> in
        particular section 6 "Targeted mLDP with Multicast Tunneling".</t>

        <t>The Target LDP session can be established manually via
        configuration or via automated mechanism.</t>

        <section title="Automatic tLDP session Creation">
          <!-- 3.1.1 -->

          <t>tLDP sessions can be signaled automatically from every IBBR to
          the appropriate EBBR. When mLDP FEC arrives at the IBBR from LDP
          domain. IBBR can automatically start a tLDP session to the EBBR
          closest to the root node. Both IBBR and EBBR should be in
          auto-discovery mode and react to the arriving tLDP signaling packets
          (i.e. targeted hellos, keep-alives etc...) to establish the session
          automatically.</t>

          <t>The root node address in the mLDP FEC can be used to find the
          EBBR. To identify the EBBR, the same procedures as <xref
          target="RFC7060"/> section 2.1 can be used or the procedures as
          explained in the <xref target="draft-ietf-bier-pim-signaling"/>
          appendix A.</t>
        </section>

        <section title="ECMP Method on IBBR">
          <!-- 3.1.2 -->

          <t>If the IBBR finds multiple equal cost EBBRs on the path to the
          root, it can use a vendor specific algorithm to choose between the
          EBBRs. These algorithms are beyond the scope of this draft. As an
          example the IBBR can use the lowest EBBR IP address to establish its
          mLDP signaling to.</t>
        </section>
      </section>

      <section title="Egress BBR procedure ">
        <!-- 3.2 -->

        <t>The Egress BBR (EBBR) is connected to the upstream mLDP domain. The
        EBBR should accept the tLDP session generated form the IBBR. It should
        assign a unique "upstream assigned label" for each arriving FEC
        generated by the IBBRs.</t>

        <t>The EBBR should follow the <xref target="RFC7060"/> procedures with
        the following modifications:</t>

        <t><list style="symbols">
            <t>The label assigned by the EBBR cannot be Implicit Null. This is
            to ensure that the identity of each p2mp and/or mp2mp tunnel in
            the BIER domain is uniquely distinguished.</t>

            <t>The label can be assigned from a domain-wide Common Block (DCB)
            <xref target="RFC9573"/></t>

            <t>The Interface ID TLV, as per <xref target="RFC6389"/> should
            includes a new BIER sub-tlv as tunnel identifier.</t>
          </list></t>

        <t>The EBBR will also generate a new label and FEC toward the root in
        the LDP domain. The EBBR Should stitch this generated label with the
        "upstream assigned label" to complete the P2MP or MP2MP LSP.</t>

        <t>With the same token the EBBR should track all the arriving FECs and
        the IBBRs that are generating these FECs. The EBBR will use this
        information to build the BIER header for each set of common FEC
        arriving from the IBBRs. The EBBR will use the BFR-ID of the IBBRs to
        build the BIER header.</t>

        <section title="IBBR procedure for arriving upstream assigned label">
          <t>Upon receiving the "upstream assigned label", the IBBR should
          create its own stitching instruction between the "upstream assigned
          label" and the downstream signaled label.</t>
        </section>

        <section title="BIER Interface ID SUB-TLVs">
          <t>As per <xref target="RFC6389"/> when LDP is used for upstream
          label assignment,the Interface ID TLV is used for signaling the
          Tunnel Identifier and it carries sub-TLVs. This document defines two
          new Interface ID sub-TLVs for BIER.</t>

          <t>Below is the Interface ID BIER sub-TLV for IPv4 BIER prefix:</t>

          <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 (TBD1)                |               15              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      IBBR Prefix IPv4                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    
      |  sub-domain-id|      BFR-id                   |    
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
            </figure></t>

          <t>Below is the Interface ID BIER sub-TLV for IPv6 BIER prefix:</t>

          <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 (TBD2)                |               23              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      IBBR Prefix IPv6                         |
      ~                         ........                              ~ 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    
      |  sub-domain-id|      BFR-id                   |    
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
            </figure></t>
        </section>
      </section>
    </section>

    <section title="Datapath Forwarding">
      <!-- 4 -->

      <section title="Datapath traffic flow">
        <!-- 4.1 -->

        <t>On the BFIR when the MPLS label for P2MP/MP2MP LSP arrives from
        upstream, a lookup in the ILM table is done and the label is swapped
        with the tLDP upstream assigned label. The BFIR will note all the
        BFERs that are interested in specific P2MP/MP2MP LSP (as per section
        3.2). The BFIR will put the corresponding BIER header with the bit
        index set for all the IBBRs interested in this stream. The BFIR builds
        this bit index from the BFR-ID of the intrested IBBRs. The BFIR will
        set the BIERHeader.Proto = MPLS and will forward the BIER packet into
        the BIER domain.</t>

        <t>In the BIER domain, normal BIER forwarding procedure will be done,
        as per <xref target="RFC8279"/></t>

        <t>The BFERs will receive the BIER packet and will look at the
        protocol field of BIER header, indicating MPLS protocol. The BFER will
        remove the BIER header and will do a lookup in the ILM table for the
        upstream assigned label and perform its corresponding action.</t>

        <t>It should be noted that these procedures are also valid if BFIR is
        the ILER and/or BFER is the ELER as per <xref target="RFC7060"/></t>
      </section>
    </section>

    <section title="Recursive FEC">
      <!-- 5 -->

      <t>The procedures above are also valid for mLDP recursive FEC. The root
      used to determine the EBBR is the outer root of the FEC. The entire
      recursive FEC needs to be preserved when it is forwarded via tLDP and
      the label request.</t>
    </section>

    <section title="IANA Consideration">
      <!-- 6 -->

      <t>IANA maintains a registry of Interface ID Types for use in GMPLS in
      the registry "Generalized Multi-Protocol Label Switching (GMPLS)
      Signaling Parameters" and sub-registry "Interface_ID Types"</t>

      <t>This document defines and requests two new Interface_ID Type for BIER
      from the Interface_ID Types space,</t>

      <t><list style="symbols">
          <t>BIER IPv4 prefix TLV (Value TBD)</t>

          <t>BIER IPv6 prefix TLV (Value TBD)</t>
        </list></t>
    </section>

    <section title="Security Considerations">
      <!-- 8 -->

      <t>While in the BIER domain the security considerations of <xref
      target="RFC8279"/> are relevant to this document.</t>

      <t>The implementation should also take into account the security
      recommendations of <xref target="RFC6389"/>.</t>

      <t/>
    </section>

    <section title="Acknowledgments">
      <!-- 9 -->

      <t>Authors would like to acknowledge Jingrong Xie and Nabeel Cocker for
      his comments and help on this draft.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <!-- 10.1 -->

      <reference anchor="RFC9573">
        <front>
          <title>Z. Zhang, E. Rosen, W. Lin, Z. Li, I. Wijnands, "MVPN/EVPN
          Tunnel Aggregation with Common Labels"</title>

          <author>
            <organization/>
          </author>

          <date day="27" month="April" year="2018"/>
        </front>
      </reference>

      <reference anchor="RFC2119">
        <front>
          <title>S. Bradner, "Key words for use in RFCs to Indicate
          Requirement Levels"</title>

          <author>
            <organization/>
          </author>

          <date month="March" year="1997"/>
        </front>
      </reference>

      <reference anchor="RFC6389">
        <front>
          <title>R Aggarwal, JL. Le Roux, "MPLS Upstream Label Assignment for
          LDP"</title>

          <author>
            <organization/>
          </author>

          <date month="November" year="2011"/>
        </front>
      </reference>

      <reference anchor="RFC6388">
        <front>
          <title>IJ. Wijnands, I. Minei, K. Kompella, B.Thomas "Label
          Distribution Protocol Extensions for Point-to-Multipoint and
          Multipoint-to-Multipoint LSP"</title>

          <author>
            <organization/>
          </author>

          <date/>
        </front>
      </reference>

      <reference anchor="draft-ietf-bier-pim-signaling">
        <front>
          <title>H, Bidgoli, F. Xu, J. Kotalwar, I. Wijnands, M. Mishra, Z.
          Zhang</title>

          <author>
            <organization/>
          </author>

          <date day="29" month="July" year="2020"/>
        </front>
      </reference>

      <reference anchor="RFC8279">
        <front>
          <title>I. Wijnands, E. Rosen, A. ADolganow, T. Prygienda, S.
          Aldrin</title>

          <author>
            <organization/>
          </author>

          <date month="November" year="2017"/>
        </front>
      </reference>

      <reference anchor="RFC7060">
        <front>
          <title>M. Napierala, E. Rosen, I. Wijnands</title>

          <author>
            <organization/>
          </author>

          <date month="November" year="2013"/>
        </front>
      </reference>
    </references>

    <references title="Informative References">
      <!-- 10.2 -->

      <reference anchor="RFC8556">
        <front>
          <title>Rosen, E., Ed., Sivakumar, M., Wijnands, IJ., Aldrin,
          S.,Dolganow, A., and T. Przygienda, "Multicast VPN Using Index
          Explicit Replication (BIER)</title>

          <author>
            <organization/>
          </author>

          <date month="April" year="2018"/>
        </front>
      </reference>

      <reference anchor="RFC8401">
        <front>
          <title>Ginsberg, L., Przygienda, T., Aldrin, S., and Z. Zhang, "BIER
          Support via ISIS"</title>

          <author>
            <organization/>
          </author>

          <date month="June" year="2018"/>
        </front>
      </reference>

      <reference anchor="RFC8444">
        <front>
          <title>Psenak, P., Kumar, N., Wijnands, IJ., Dolganow, A.,
          Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF Extensions for Bit
          Index Explicit Replication"</title>

          <author>
            <organization/>
          </author>

          <date month="June" year="2018"/>
        </front>
      </reference>
    </references>
  </back>
</rfc>
<!-- generated from file C:\Users\hbidgoli\Downloads\draft-ietf-bier-pim-signaling-08.nroff with nroff2xml 0.1.0 by Tomek Mrugalski -->
