<?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="info" docName="draft-ietf-bier-mldp-signaling-over-bier-02"
     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="Jayant Kotalwar" initials="J." surname="Kotalwar">
      <organization>Nokia</organization>

      <address>
        <postal>
          <street/>

          <city>Montain View</city>

          <region/>

          <code/>

          <country>US</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>jayant.kotalwar@nokia.com</email>

        <uri/>
      </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="7" month="March" year="2023"/>

    <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. 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 figure 1, 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. This procedure is
      explained in <xref target="RFC7060"/> (Using LDP Multipoint Extension on
      Targeted LDP Sessions).</t>

      <t>This document provides details and defines some needed
      procedures.</t>

      <t>.</t>

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

        <t>In Figure 1, 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 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="draft-ietf-bess-mvpn-evpn-aggregation-label"/></t>

            <t>The Interface ID TLV, as per <xref target="RFC6389"/> should
            includes a new BIER sub-domain sub- tlv (type TBD)</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.</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 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]]></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]]></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 ILM table is done and the label is swapped with
        tLDP upstream assigned label. The BFIR will note all the BFERs that
        are interested in specific P2MP/MP2MP LSP (as per section 3.2). BFIR
        will put the corresponding BIER header with bit index set for all the
        IBBRs interested in this stream. BFIR will set the BIERHeader.Proto =
        MPLS and will forward the BIER packet into 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 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 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 a new Interface_ID Type for
      BIER.</t>

      <t><list style="symbols">
          <t>BIER Interface TLV (Value TBD)</t>
        </list></t>
    </section>

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

      <t>NA</t>
    </section>

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

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

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

      <reference anchor="draft-ietf-bess-mvpn-evpn-aggregation-label">
        <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 -->
