<?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-01"
     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="12" month="November" year="2021"/>

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

      <t>This document describes the 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 segment 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 RFC 2119 [RFC2119].</t>

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

        <t>Some of the terminology specified in [I-D.draft-ietf-bier-
        architecture-05] 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 term used for dataplain 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 term used for dataplain 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 signaling
        point of view. It maintains mLDP adjacency toward the LDP domain and
        determines if the mLDP 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 BIER domain from
        signaling point of view. It terminates the targeted ldp signaling
        through 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>
      </section>
    </section>

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

      <figure anchor="Control-Plane" title="BIER boundry 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 [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 documents provides details and defines some needed
      procedures.</t>

      <t>.</t>

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

        <t>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 the 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 session can be signaled automatically from every IBBR to the
          appropriate EBBR. When mLDP FEC arrives to 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 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 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 smallest 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 IBBR. It should
        assign a unique "upstream assigned label" for each arriving FEC
        generated by IBBRs.</t>

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

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

            <t>The label can be assigned from a domain-wide Common Block (DCB)
            <xref target="draft-zzhang-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 on
        the LDP domain. The EBBR Should stitch this generate label with the
        "upstream assigned label" to complete the P2MP or MP2MP LSP.</t>

        <t>With same token the EBBR should track all the arriving FECs and the
        IBBRs that are generating these FECs. 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", IBBR should create
          its own stitching instruction between the "upstream assigned label"
          and the down stream signaled label.</t>
        </section>
      </section>
    </section>

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

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

        <t>On 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
        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, will look at the protocol
        of BIER header (MPLS). 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 above procedures also will work with a mLDP recursive FEC. The
      root used to determine the EBBR is the outer root of the FEC. The entire
      recursive FEC needs to be preserve when it is forwarded via tLDP and the
      label request.</t>
    </section>

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

      <t>adf<list style="numbers">
          <t>A new BIER sub-domain sub- tlv for the interface ID TLV to be
          assigned by IANA</t>
        </list></t>
    </section>

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

      <t>TBD</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-zzhang-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="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="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 -->
