<?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-xie-bier-mvpn-mpls-p2mp-02"
     ipr="trust200902">
  <front>
    <title abbrev="MVPN Using MPLS P2MP and BIER">Multicast VPN Using MPLS
    P2MP and BIER</title>

    <author fullname="Jingrong Xie" initials="J." surname="Xie">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <code/>

          <country/>
        </postal>

        <email>xiejingrong@huawei.com</email>
      </address>
    </author>

    <author fullname="Mike McBride" initials="M." surname="McBride">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <code/>

          <country/>
        </postal>

        <email>mmcbride7@gmail.com</email>
      </address>
    </author>

    <author fullname="Mach Chen" initials="M." surname="Chen">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <code/>

          <country/>
        </postal>

        <email>mach.chen@huawei.com</email>
      </address>
    </author>

    <author fullname="Liang Geng" initials="L." surname="Geng">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing 100053</city>

          <code/>

          <country></country>
        </postal>

        <email>gengliang@chinamobile.com</email>
      </address>
    </author>

    <date day="2" month="July" year="2018"/>

    <abstract>
      <t>MVPN is a widely deployed multicast service with mLDP or RSVP-TE P2MP
      as the P-tunnel. Bit Index Explicit Replication (BIER) is an
      architecture that provides optimal multicast forwarding without
      requiring intermediate routers to maintain any per-flow state by using a
      multicast-specific BIER header. This document introduces a seamless
      transition mechanism from legacy MVPN using mLDP/RSVP-TE P2MP to MVPN
      using BIER by combining P2MP and BIER to form a P2MP based BIER as the
      P-tunnel. This will leverage the widely supported P2MP capability in
      both data-plane and control-plane, and will help introducing BIER in
      existing multicast networks to shift multicast delivery from MVPN using
      mLDP/RSVP-TE P2MP by two means: It is easier and more efficient for
      legacy routers to support BIER forwarding on the basis of widely
      supported P2MP forwarding, and it is more seamless for existing
      multicast networks to deploy BIER when some routers do not support BIER
      forwarding.</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"/>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t><xref target="RFC6513"/> and <xref target="RFC6514"/> specify the
      protocols and procedures that a Service Provider (SP) can use to provide
      Multicast Virtual Private Network (MVPN) service to its customers.
      Multicast tunnels are created through an SP's backbone network; these
      are known as "P-tunnels". The P-tunnels are used for carrying multicast
      traffic across the backbone. The MVPN specifications allow the use of
      several different kinds of P-tunnel technology, such as mLDP P2MP and
      RSVP-TE P2MP. It is common for such a P-tunnel having a
      multicast-specific path.</t>

      <t>Bit Index Explicit Replication (BIER) <xref target="RFC8279"/> is an
      architecture that provides optimal multicast forwarding through a
      "multicast domain", without requiring intermediate routers to maintain
      any per-flow state, by using a multicast-specific BIER header (per <xref
      target="RFC8296"/>).</t>

      <t><xref target="I-D.ietf-bier-mvpn"/> delivers a solution of MVPN using
      SPF based BIER defined in [RFC8279]. It can not, however, support a
      multicast-specific path well, something common in legacy MVPN
      deployment.</t>

      <t>[RFC8279] provides a solution to support mid nodes without
      BIER-capability. It cannot, however, support deployment on a network
      that has edge nodes without BIER-capability, which may be common in some
      SP-networks, especially when most of the nodes in a network or part of a
      network are edge or service nodes.</t>

      <t>This document introduces a seamless transition mechanism from legacy
      MVPN to MVPN using P2MP based BIER, by applying a BIER encapsulation in
      data-plane to eliminate per-flow states, while preserving existing
      features such as multicast-specific PATH.</t>

      <t>It also introduces a seamless deployment solution on networks with
      Non-BIER-capability Edge nodes and/or Mid nodes, by exploring the
      P2MP/tree based BIER forwarding procedure in detail. Such a P2MP/tree
      based BIER is mentioned but not explored in detail in RFC8279.</t>

      <t/>
    </section>

    <section title="Terminology">
      <t>Readers of this document are assumed to be familiar with the
      terminology and concepts of the documents listed as Normative
      References. For convenience, some of the more frequently used terms and
      new terms list below. <list style="symbols">
          <t>LSP: Label Switch Path</t>

          <t>LSR: Label Switching Router</t>

          <t>P2MP: Point to Multi-point</t>

          <t>P-tunnel: A multicast tunnel through the network of one or more
          SPs. P-tunnels are used to transport MVPN multicast data.</t>

          <t>PMSI: Provider Multicast Service Interface</t>

          <t>x-PMSI A-D route: a route that is either an I-PMSI A-D route or
          an S-PMSI A-D route.</t>

          <t>PTA: PMSI Tunnel attribute. A type of BGP attribute known as the
          PMSI Tunnel attribute.</t>

          <t>P2MP based BIER: BIER using P2MP LSP as topology</t>

          <t>P-CAPABILITY: A capability to Process BitString in BIER Header of
          a packet.</t>

          <t>D-CAPABILITY: A capability to Disposit BIER Header of a packet,
          including or excluding the BIER Label.</t>

          <t>BSL: Bit String Length, that is 64, 128, 256, etc (per
          [RFC8279]).</t>
        </list></t>
    </section>

    <section title="Applicability Statement">
      <t/>

      <t>The BIER architecture document [RFC8279] describes how each node
      forwards BIER packets hop by hop to neighboring nodes without generating
      duplicate packets. This forwarding is for the case where a form of
      underlay called "many to many " and built by IGP is used. Obviously, the
      case of underlay of "one to many" or P2MP is a simpler scenario, and the
      forwarding procedure naturally applies. However, as is well-known, such
      a forwarding procedure requires the support of hardware. The usage of
      the same forwarding method for both complex scenarios and simple
      scenarios will inevitably require complex hardware forwarding.</t>

      <t>This document describes how BIER forwarding can be customized and
      simplified with an underlay of "one to many" or P2MP (see chapter 5).
      This customization and simplification eliminates some of the unnecessary
      data plane processing and so is easier to implement with existing
      hardware. Based on this customization of the forwarding method for
      P2MP-based BIER, a variety of Partial Deployment methods are given for
      the different capabilities of the hardware to support BIER forwarding.
      Compared with RFC8279, when there is no BIER forwarding capability on
      edge nodes, Partial Deployment can be carried out ; For the case where
      the intermediate node has no BIER forwarding capability, P2MP forwarding
      can be used without the need for unicast replication.</t>

      <t>This document also describes a MVPN Transition solution that
      eliminates the per-flow state by introducing BIER MPLS encapsulation and
      forwarding in data-plane, while preserving the original control-plane
      protocol and its features, especially when some sort of path customizing
      being used. The said path customization include RSVP-TE P2MP using an
      explicit path, and MLDP P2MP where static route was used. These features
      can continue to retain, making the transition process seamless.</t>

      <t/>
    </section>

    <section title="MVPN using P2MP based BIER">
      <t/>

      <section title="Overview">
        <t>According to [RFC8279], the P2MP based BIER is a BIER which using a
        form of tree as the underlay. The P2MP LSP is not only a LSP, but also
        a topology as the BIER underlay. The P2MP based BIER is P-tunnel,
        which is used for bearing multicast flows. Every flow can be seen as
        binding to an independent tunnel, which is constructed by the
        BitString in the BIER header of every packet of the flow. Multicast
        flows are transported in SPMSI-only mode, on P2MP based BIER tunnels,
        and never directly on P2MP LSP tunnel.</t>

        <t>Section 4.2 describes the overall principle of transitioning a
        Legacy MVPN using P2MP to a MVPN using BIER. It also descirbes the
        detail use of new types of PTA in BGP MVPN routes to indicate PEs to
        initialize the building of P2MP based BIER forwarding.</t>

        <t>Section 4.3 describes the Underlay protocols to build P2MP based
        BIER forwarding briefly.</t>

        <t/>
      </section>

      <section title="MVPN Transition from P2MP to P2MP based BIER">
        <t>This section describes a MVPN transitioning solution that
        eliminates the per-flow state by introducing BIER MPLS encapsulation
        and forwarding procedure in data-plane, while preserving the
        originally deployed control-plane protocol and its features,
        especially when some sort of path customizing being used.</t>

        <t>When transitioning a MVPN using mLDP P2MP P-tunnel, then continue
        using mLDP to build a P2MP based BIER forwarding, preserving the
        original mLDP features. For example, mLDP uses static route to specify
        a path other than the path of IGP.</t>

        <t>When transitioning a MVPN using RSVP-TE P2MP P-tunnel, then
        continue using RSVP-TE to build a P2MP based BIER forwarding,
        preserving the original RSVP-TE features. For example, RSVP-TE use
        explicit path to specify a path other than the path of IGP.</t>

        <t/>

        <section title="Use of the PTA in x-PMSI A-D Routes">
          <t>As defined in [RFC6514], the PMSI Tunnel attribute (PTA) carried
          by an x-PMSI A-D route identifies the P-tunnel that is used to
          instantiate a particular PMSI. If a PMSI is to be instantiated by
          P2MP LSP based BIER, the PTA is constructed by a BFIR, which is also
          a Ingress LSR. This document defines the following Tunnel Types:</t>

          <t>+ TBD - RSVP-TE built P2MP BIER</t>

          <t>+ TBD - mLDP built P2MP BIER</t>

          <t>Allocation is expected from IANA for two new tunnel type
          codepoints from the "P-Multicast Service Interface Tunnel (PMSI
          Tunnel) Tunnel Types" registry. These codepoints will be used to
          indicate that the PMSIs is instantiated by MLDP or RSVP-TE extension
          with support of BIER.</t>

          <t/>

          <t>When the Tunnel Type is set to RSVP-TE built P2MP BIER, the
          Tunnel Identifier include two parts, as follows:</t>

          <figure align="left" anchor="PTA-RSVP-P2MP-BIER"
                  title="PTA of RSVP-TE built P2MP BIER">
            <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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |BS Len |     Max SI    |            Must Be Zero               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       P2MP ID                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  MUST be zero                 |      Tunnel Range Base        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Extended Tunnel ID                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ]]></artwork>
          </figure>

          <t/>

          <t>BS Len: A 4 bits field. The values allowed in this field are
          specified in section 2 of [RFC8296].</t>

          <t>Max SI: A 1 octet field. Maximum Set Identifier (section 1 of
          [RFC8279]) used in the encapsulation for this BIER sub-domain.</t>

          <t>&lt;Extended Tunnel ID, Reserved, Tunnel Range Base, P2MP ID&gt;:
          A ID as carried in the RSVP-TE P2MP LSP SESSION Object defined in
          <xref target="RFC4875"/>.</t>

          <t>The "Tunnel Range" is the set of P2MP LSPs beginning with the
          Tunnel Range base and ending with ((Tunnel Range base)+(Tunnel
          Number)- 1). A unique Tunnel Range is allocated for the BSL and a
          Sub-domain-ID implicited by the P2MP.</t>

          <t>The size of the Tunnel Range is determined by the number of Set
          Identifiers (SI) (section 1 of [RFC8279]) that are used in the
          topology of the P2MP-LSP. Each SI maps to a single Tunnel in the
          Tunnel Range. The first Tunnel is for SI=0, the second Tunnel is for
          SI=1, etc.</t>

          <t/>

          <t>When the Tunnel Type is set to mLDP built P2MP BIER, the Tunnel
          Identifier include two parts, as follows:</t>

          <t><figure align="left" anchor="PTA-MLDP-P2MP-BIER"
              title="PTA of MLDP built P2MP BIER">
              <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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |BS Len |     Max SI    |            Must Be Zero               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |P2MP Type(0x06)|        Address Family         | Address Length|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                       Root Node Address                       ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Opaque Length(0x0007)      | OV Type(0x01) |OV Len(High 8b)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | (Low 8b)(0x04)|  Tunnel Range Base(High 24b)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   (Low 8b)    |
      +-+-+-+-+-+-+-+-+
      ]]></artwork>
            </figure>BS Len: A 4 bits field. The values allowed in this field
          are specified in section 2 of [RFC8296].</t>

          <t>Max SI: A 1 octet field. Maximum Set Identifier (section 1 of
          [RFC8279]) used in the encapsulation for this BIER sub-domain.</t>

          <t>&lt;Type=0x06, AF, AL, RootNodeAddr, Opqeue Length=0x0007, OV
          Type=0x01, OV Len=0x04, Tunnel Range Base&gt;: A P2MP Forwarding
          Equivalence Class (FEC) Element, with a Generic LSP Identifier TLV
          as the opaque value element, defined in <xref
          target="RFC6388"/>.</t>

          <t>The "Tunnel Range" is the set of P2MP LSPs beginning with the
          Tunnel Range base and ending with ((Tunnel Range base)+(Tunnel
          Number)- 1). A unique Tunnel Range is allocated for the BSL and a
          Sub-domain-ID implicited by the P2MP.</t>

          <t>The size of the Tunnel Range is determined by the number of Set
          Identifiers (SI) (section 1 of [RFC8279]) that are used in the
          topology of the P2MP-LSP. Each SI maps to a single Tunnel in the
          Tunnel Range. The first Tunnel is for SI=0, the second Tunnel is for
          SI=1, etc.</t>

          <t/>

          <t>When the Tunnel Type is any of the above, The "MPLS label" field
          contain an upstream-assigned non-zero MPLS label. It is assigned by
          the router (a BFIR) that constructs the PTA. Absence of an MPLS
          Label is indicated by setting the MPLS Label field to zero.</t>

          <t/>

          <t>When the Tunnel Type is any of the above, two of the flags, LIR
          and LIR-pF, in the PTA "Flags" field are meaningful. Details about
          the use of these flags can be found in [RFC6513], <xref
          target="I-D.ietf-bess-mvpn-expl-track"/> and <xref
          target="I-D.ietf-bier-mvpn"/>].</t>

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

      <section title="Building P2MP based BIER forwarding state">
        <t>When P2MP based BIER are used, then it is not nessary to use IGP or
        BGP to build the BIER routing table and forwarding table. Instead, the
        BIER layer information is carried by MLDP or RSVP-TE, when they
        build the P2MP tree.</t>

        <t>The detail procedure for building P2MP based BIER forwarding state
        using mLDP or RSVP-TE is outside the scope of this document.</t>

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

    <section title="P2MP based BIER Forwarding Procedures">
      <t/>

      <section title="Overview">
        <t/>

        <t>This document specifies one OPTIONAL Forwarding Procedure of BIER
        encapsulation packet, on the condition that the BIER underlay topology
        is P2MP LSP, as describes in the above sections. It is in fact a
        customized forwarding procedure, and a detail exploration of BIER
        forwarding along a multicast-specific tree. Comparing to the common
        Forwarding Procedure described in [RFC8279], there is some
        considerable simplification:</t>

        <t><list style="numbers">
            <t>Not need to Edit the BitString when forwarding packet to
            Neighbor, for the underlay P2MP topology is already loop-free and
            duplicate-free. This can further lead to a method to by-pass the
            BIER encapsulation packet when a node does not support the
            BitString process.</t>

            <t>Not need to do a disposition function by parsing the BitString,
            for a P2MP can identify a disposition function by a node's Label
            when the P2MP is built. This can further reduce the complex
            BitString processing for legacy hardware on edge, and lead to a
            method to deploy on exist network when an edge node does not
            support BitString process.</t>
          </list></t>

        <t>The main principle of the optional forwarding procedure of the P2MP
        based BIER is, on the basis of P2MP forwarding procedure according to
        the BIER-MPLS label, to use the BitString to prune/filter the
        undesired P2MP downstream. This is an smooth enhancement to the
        widely deployed P2MP forwarding, and easier to deploy on existing routers
        comparing to the many-to-many BIER forwarding.</t>

        <t>The enhancement to the P2MP forwarding is to add a Forwarding
        BitMask to existing NHLFE defined in <xref target="RFC3031"/>, for
        checking with the BitString in a packet, to determin whether the
        packet is to be forwarded or pruned. If the checking result by AND'ing
        a packet's BitString with the F-BM of the NHLFE (i.e.,
        Packet-&gt;BitString &amp;= F-BM) is non-zero, then forward the packet
        to the next-hop indicated by the NHLFE entry, and the Label is
        switched to the proper one in the NHLFE. If the result is zero, then
        do not forward the packet to the next-hop indicated by the NHLFE
        entry.</t>

        <t/>
      </section>

      <section title="P2MP based BIER forwarding">
        <t>For a P2MP tree, every node has a role of Root, Branch, Leaf, or
        Bud, as specified in [RFC4611].</t>

        <t>EXAMPLE 1: Take the following figure as an example.</t>

        <t><figure align="left" anchor="P2MP-BIER-TOPO1"
            title="P2MP-based BIER Topology without BUD nodes">
            <artwork><![CDATA[      
      ( A ) ------------ ( B ) ------------ ( C ) ------------ ( D )
      (Root)                \                  \           1 (0:0001)
                             \                  \
                             ( E )              ( F )
                           3 (0:0100)         2 (0:0010)
          ]]></artwork>
          </figure></t>

        <t>Forwarding Table on A:</t>

        <t><list style="symbols">
            <t>NHLFE(TreeID, OutInterface&lt;toB&gt;, OutLabel&lt;alloc by
            B&gt;, F-BM&lt;0111&gt;)</t>
          </list></t>

        <t>Forwarding Table on C:</t>

        <t><list style="symbols">
            <t>ILM(inLabel&lt;alloc by C&gt;, action&lt;TreeID&gt;,
            Flag=Branch|CheckBS, BSL)</t>

            <t>NHLFE(TreeID, OutInterface&lt;toD&gt;, OutLabel&lt;alloc by
            D&gt;, F-BM&lt;0001&gt;)</t>

            <t>NHLFE(TreeID, OutInterface&lt;toF&gt;, OutLabel&lt;alloc by
            F&gt;, F-BM&lt;0010&gt;)</t>
          </list></t>

        <t>For Node C, the ability to receive a MPLS-encapsulation BIER
        packet, match ILM and get a TreeID, replicate to NHLFE Entries of the
        TreeID according to the result of AND'ing the BitString of packet and
        the F-BM of a NHLFE Entry, is called a P-CAPABILITY, which means to
        Process BitString in each packet.</t>

        <t>Forwarding Table on B is the same to C.</t>

        <t/>

        <t>Forwarding Table on D:</t>

        <t><list style="symbols">
            <t>ILM(inLabel&lt;alloc by D&gt;, action&lt;TreeID&gt;,
            Flag=Leaf|CheckBS, BSL)</t>

            <t>LEAF(TreeID, F-BM&lt;0001&gt;, flag=PopBIERincluding)</t>
          </list></t>

        <t>When Node D receive a MPLS-encapsulation BIER packet, it get the
        Label and match ILM, then do a replication according to the LEAF and
        check whether to proceed by AND'ing the BitString in the replicated
        packet and the F-BM in the LEAF entry. When the AND'ing result is
        non-zero then do a POP to the packet to disposit the whole BIER header
        Including the BIER Label, which has a length of (12+BSL/8) octets.</t>

        <t>Node D need to have a P-CAPABILITY, for it need to Process
        BitString in each packet to determin whether to replicate to a special
        LEAF, and then disposit the whole BIER hearder Including the BIER
        Label and forward the IP multicast packet further. Node D also need to
        do the disposition as well, which is called a D-CAPABILITY.
        D-CAPABILITY means to disposit the BIER header including or excluding
        the BIER Label in the begining. Here PopBIERincluding means pop the
        BIER header including the BIER Label, while PopBIERexcluding means pop
        the BIER header excluding the BIER Label.</t>

        <t>Forwarding Tables on E and F are same to D.</t>

        <t/>

        <t>Comparing to the forwarding procedure defined in [RFC8279], there
        are two benefits of using the customized P2MP based BIER
        forwarding:</t>

        <t><list style="numbers">
            <t>Not need to walk every physical neighbor, but only need to walk
            downstream neighbors on a P2MP tree.</t>

            <t>Not need to edit the BitString in every packet, but only need
            to swap the BIER Label.</t>
          </list></t>

        <t>EXAMPLE 2: Another example with P2MP BUD Nodes.</t>

        <t><figure align="left" anchor="P2MP-BIER-TOPO2"
            title="P2MP-based BIER Topology with BUD nodes">
            <artwork><![CDATA[
      ( A ) ------------ ( B ) ------------ ( C ) ------------ ( D )
      (Root)                \                              1 (0:0001)
                             \                   
                             ( E ) ------------ ( F )
                           3 (0:0100)         2 (0:0010)
          ]]></artwork>
          </figure></t>

        <t>Forwarding Table on B (Branch Node):</t>

        <t><list style="symbols">
            <t>ILM(inLabel&lt;alloc by B&gt;, action&lt;TreeID&gt;,
            Flag=Branch|CheckBS, BSL)</t>

            <t>NHLFE(TreeID, OutInterface&lt;toE&gt;, OutLabel&lt;alloc by
            E&gt;, F-BM&lt;0110&gt;)</t>

            <t>NHLFE(TreeID, OutInterface&lt;toC&gt;, OutLabel&lt;alloc by
            C&gt;, F-BM&lt;0001&gt;)</t>
          </list></t>

        <t>Node B, which is a Branch Node, only need to use its
        P-CAPABILITY.</t>

        <t/>

        <t>Forwarding Table on E (BUD Node):</t>

        <t><list style="symbols">
            <t>ILM(inLabel&lt;alloc by E&gt;, action&lt;TreeID&gt;,
            Flag=Bud|CheckBS, BSL)</t>

            <t>NHLFE(TreeID, OutInterface&lt;toF&gt;, OutLabel&lt;alloc by
            F&gt;, F-BM&lt;0010&gt;)</t>

            <t>LEAF(TreeID, F-BM&lt;0100&gt;, flag=PopBIERincluding)</t>
          </list>When Node E receive a MPLS-encapsulation BIER packet, it get
        the Label and match ILM, then do a replication according to the NHLFEs
        and check whether to proceed by AND'ing the BitString in the
        replicated packet and the F-BM in the NHLFE/LEAF entry. When the
        AND'ing result is non-zero for the second LEAF then do a POP to the
        packet to disposit the whole BIER header, which has a length of
        (12+BSL/8) octets.</t>

        <t>Node E, which is a BUD Node, has both the two capacities:
        P-CAPABILITY and D-CAPABILITY. P-CAPABILITY is need to be used for
        every NHLFE/LEAF, and D-CAPABILITY is need for the NHLFE that has a
        PopBIERincluding flag.</t>

        <t/>
      </section>

      <section title="When Mid, Leaf or Bud nodes do not support P-CAPABILITY">
        <t>The procedures of Section 5.2 presuppose that, within a given BIER
        domain, all the nodes adjacent to a given BFR in a given routing
        underlay are also BFRs. However, it is possible to use BIER even when
        this is not the case. In this section, we describe procedures that can
        be used if the routing underlay is a P2MP tree with BIER information
        in the domain.</t>

        <t>For a P2MP tree, every node has a role of Root, Branch, Leaf, or
        Bud. The role is determined when the tree is built. The method is
        suitable for conditions when Mid, Leaf or Bud nodes do not support
        P-CAPABILITY.</t>

        <t/>

        <t>EXAMPLE 1: Take Figure 4 as an example.</t>

        <t>If D, F, E support BIER, and C don't support BIER, then we can
        configure on C to indicate it to use P2MP for BIER packets forwarding.
        Then C build a P2MP forwarding entry, while still pass the BIER
        information in control-plane. For example, D send a P2MP FEC Mapping
        message to C with a BitMask 0001, F send a P2MP FEC Mapping message to
        C with a BitMask 0010, and C send a P2MP FEC Mapping message to B with
        a BitMask, but C build a P2MP forward entry like this:</t>

        <t><list style="symbols">
            <t>ILM(inLabel&lt;alloc by C&gt;, action&lt;TreeID&gt;,
            Flag=Branch)</t>

            <t>NHLFE(TreeID, OutInterface&lt;toD&gt;, OutLabel&lt;alloc by
            D&gt;)</t>

            <t>NHLFE(TreeID, OutInterface&lt;toF&gt;, OutLabel&lt;alloc by
            F&gt;)</t>
          </list>If D don't support BIER P-CAPABILITY, but it support BIER
        D-CAPABILITY, then the above method is still valid.</t>

        <t/>

        <t>Forwarding Table on D when D don't have a P-CAPABILITY:</t>

        <t><list style="symbols">
            <t>ILM(inLabel&lt;alloc by D&gt;, action&lt;TreeID&gt;, Flag=Leaf,
            BSL)</t>

            <t>NHLFE(TreeID, flag=PopBIERincluding)</t>
          </list>When Node D receive a MPLS-encapsulation BIER packet, it get
        the Label and match ILM, then do a replication according to the NHLFE
        but don't do the check by AND'ing the BitString in the replicated
        packet and the F-BM in the NHLFE entry. And then do a POP to the
        packet to disposit the whole BIER header, which has a length of
        (12+BSL/8) octets.</t>

        <t/>

        <t>Another alternative form of Forwarding Table on D can also be the
        following when D don't have a P-CAPABILITY:</t>

        <t><list style="symbols">
            <t>ILM(inLabel&lt;alloc by D&gt;, action&lt;PopBIERincluding&gt;,
            Flag=Leaf, BSL)</t>
          </list></t>

        <t>When Node D receive a MPLS-encapsulation BIER packet, it get the
        Label and match ILM, then do a POP action according to the ILM to pop
        the whole (12+BSL/8) octets from the Label position.</t>

        <t/>

        <t>EXAMPLE 2: Take BUD Node E in Figure 5 as another example.</t>

        <t>Forwarding Table on Bud Node E when E don't have a
        P-CAPABILITY:</t>

        <t>Forwarding Table on E when E don't have a P-CAPABILITY:</t>

        <t><list style="symbols">
            <t>ILM(inLabel&lt;alloc by E&gt;, action&lt;TreeID&gt;, Flag=Bud,
            BSL)</t>

            <t>NHLFE(TreeID, OutInterface&lt;toF&gt;, OutLabel&lt;alloc by
            F&gt;)</t>

            <t>LEAF(TreeID, flag=PopBIERincluding)</t>
          </list></t>

        <t>One can see that, this method can support widely Non-BIER Nodes in
        a network, no matter the node has a Mid, Leaf or Bud role, and would
        never result in any ingress-replication through unicast tunnel, which
        may cause a overload on a link.</t>

        <t>One can also see that, [RFC8279] only support Non BIER-capability
        nodes being the Mid nodes, and never allow a BFER nodes to be Non
        BIER-capability.</t>

        <t/>
      </section>

      <section title="When Leaf or Bud nodes do not support D-CAPABILITY">
        <t/>

        <t>A more tolerant variant of the above, when Leaf or Bud nodes do not
        support D-CAPABILITY, would be the following:</t>

        <t/>

        <t>EXAMPLE 1: Take Figure 4 as an example.</t>

        <t>If D even don't support BIER P-CAPABILITY or D-CAPABILITY, then POP
        the whole BIER Header except the first four octets Label field of a
        packet before it come to D. This requires C to build a forwarding
        table like this:</t>

        <t>Forwarding Table on C (Branch Node):</t>

        <t><list style="symbols">
            <t>ILM(inLabel&lt;alloc by E&gt;, action&lt;TreeID&gt;,
            Flag=Branch|CheckBS, BSL)</t>

            <t>NHLFE(TreeID, OutInterface&lt;toD&gt;, OutLabel&lt;alloc by
            D&gt;, F-BM&lt;0001&gt;, Flag=PopBIERexcluding)</t>

            <t>NHLFE(TreeID, OutInterface&lt;toF&gt;, OutLabel&lt;alloc by
            F&gt;, F-BM&lt;0010&gt;)</t>
          </list></t>

        <t>The Flag PopBIERexcluding means POP the BIER Header excluding the
        first 4 octets BIER Label in a packet, that is a Length of
        (8+BSL/8)</t>

        <t>If D don't support BIER P-CAPABILITY or D-CAPABILITY, and C don't
        support BIER P-CAPABILITY, then it requires B to build a forwarding
        table, to ensure the BIER Header except the first four octets Label
        field of a packet is popped before replicated to C, and requires C to
        build a forwarding table of a pure P2MP branch, and requires F to
        build a forwarding table of a pure P2MP Leaf. Their forwarding tables
        are like below:</t>

        <t>Forwarding Table on B (Branch Node):</t>

        <t><list style="symbols">
            <t>ILM(inLabel&lt;alloc by B&gt;, action&lt;TreeID&gt;,
            Flag=Branch|CheckBS, BSL)</t>

            <t>NHLFE(TreeID, OutInterface&lt;toC&gt;, OutLabel&lt;alloc by
            C&gt;, F-MB&lt;0011&gt;, Flag=PopBIERexcluding)</t>

            <t>NHLFE(TreeID, OutInterface&lt;toE&gt;, OutLabel&lt;alloc by
            E&gt;, F-BM&lt;0100&gt;)</t>
          </list>Forwarding Table on C (Branch Node):</t>

        <t><list style="symbols">
            <t>ILM(inLabel&lt;alloc by C&gt;, action&lt;TreeID&gt;,
            Flag=Branch)</t>

            <t>NHLFE(TreeID, OutInterface&lt;toF&gt;, OutLabel&lt;alloc by
            F&gt;)</t>

            <t>NHLFE(TreeID, OutInterface&lt;toF&gt;, OutLabel&lt;alloc by
            F&gt;)</t>
          </list>Forwarding Table on D (Branch Node):</t>

        <t><list style="symbols">
            <t>ILM(inLabel&lt;alloc by D&gt;, action&lt;PopLabel&gt;,
            Flag=Leaf)</t>
          </list></t>

        <t>Here PopLabel mean to pop the Label, which is in fact a P2MP LSP
        Label. It is a basic capability of any LSR.</t>

        <t>Forwarding Table on F (Branch Node):</t>

        <t><list style="symbols">
            <t>ILM(inLabel&lt;alloc by F&gt;, action&lt;PopLabel&gt;,
            Flag=Leaf)</t>
          </list></t>

        <t>Here PopLabel mean to pop the Label, which is in fact a P2MP LSP
        Label. It is a basic capability of any LSR, and the Forwarding table
        on F is in fact a P2MP one.</t>

        <t>Note that, alrough F support BIER, which means it can deal with a
        BIER packet, but it must downshift its forwarding table to a pure P2MP
        one, because the packet it received doesn't include a BIER Header but
        a P2MP Label packet due to the POP behaving of its upstream node.</t>

        <t/>

        <t>EXAMPLE 2: Take Figure 5 as another example.</t>

        <t>If E even don't support BIER P-CAPABILITY or D-CAPABILITY, then POP
        the whole BIER Header Except the first four octets Label field of a
        packet before it come to D. This requires B to build a forwarding
        table like this:</t>

        <t>Forwarding Table on B (Branch Node):</t>

        <t><list style="symbols">
            <t>ILM(inLabel&lt;alloc by B&gt;, action&lt;TreeID&gt;,
            Flag=Branch|CheckBS, BSL)</t>

            <t>NHLFE(TreeID, OutInterface&lt;toC&gt;, OutLabel&lt;alloc by
            C&gt;, F-MB&lt;0011&gt;)</t>

            <t>NHLFE(TreeID, OutInterface&lt;toE&gt;, OutLabel&lt;alloc by
            E&gt;, F-BM&lt;0100&gt;, Flag=PopBIERexcluding)</t>
          </list>Forwarding Table on E (Bud Node):</t>

        <t><list style="symbols">
            <t>ILM(inLabel&lt;alloc by E&gt;, action&lt;TreeID&gt;,
            Flag=Bud)</t>

            <t>NHLFE(TreeID, OutInterface&lt;toF&gt;, OutLabel&lt;alloc by
            F&gt;)</t>

            <t>LEAF(TreeID, flag=PopLabel)</t>
          </list>Forwarding Table on F (Branch Node):</t>

        <t><list style="symbols">
            <t>ILM(inLabel&lt;alloc by F&gt;, action&lt;PopLabel&gt;,
            Flag=Leaf)</t>
          </list>Note that, alrough F support BIER, which means it can deal
        with a BIER packet, but it must downshift its forwarding table to a
        pure P2MP Leaf, because the packet it received doesn't include a BIER
        Header but a P2MP Label packet due to the POP behaving of its upstream
        node.</t>

        <t/>

        <t>One can see that, when some Leaf or Bud nodes even don't have a
        D-CAPABILITY, we can do a POP action to dispositing the BIER header
        excluding the BIER Label in the begining before the packet arrive the
        node. This is similar to a Penultimate Hop Popping in a P2P LSP.</t>

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

    <section title="Provisioning Considerations">
      <t>P2MP based BIER use concepts of both P2MP and BIER. Some provisioning
      considerations list below:</t>

      <t>Sub-domain:</t>

      <t>In P2MP based BIER, every P2MP is a specific BIER underlay topology,
      and an implicit Sub-domain. RSVP-TE/MLDP build the BIER information of
      the implicit sub-domain when building the P2MP tree. MVPN get the
      implicit sub-domain by provisioning.</t>

      <t>BFR-prefix:</t>

      <t>In P2MP LSP based BIER, every BFR is also a LSR. So the BFR-prefix in
      the sub-domain is by default identified by LSR-id. Additionally, When
      BFR/LSR is also a MVPN PE, BFR-prefix is also the same as Originating
      Router&rsquo;s IP Address of x-PMSI A-D route or Leaf A-D route.</t>

      <t>BFR-id:</t>

      <t>When using protocols like RSVP-TE, which initializes P2MP LSP from a
      specific Ingress Node, BFR-id which is unique in P2MP LSP scope, can be
      auto-provisioned by Ingress Node, or conventionally configure on every
      Egress Nodes.</t>

      <t>BSL and BIER-MPLS Label Block Size:</t>

      <t>In P2MP LSP based BIER, Every P2MP LSP or implicit sub-domain
      requires a single BSL, and a specific BIER-MPLS Label block size for
      this BSL.</t>

      <t>VPN-Label:</t>

      <t>The P2MP based BIER 'P-tunnel' can be shared by multiple VPNs or a
      single VPN. When a P2MP based BIER being shared by multiple VPNs, an
      Upstream-assigned VPN-Label is required. It can be auto-provisioned or
      manual configured by the BFIR or Ingress LSR.</t>

      <t>In fact, [RFC6513] has defined the method of "Aggregating Multiple
      MVPNs on a Single P-Tunnel". But unfortunately it is not widely deployed
      because of the serious trade-off between state saving and bandwidth
      waste. The BIER encapsulation and forwarding method give it a chance to
      eliminate the trade-off while gaining a completely state saving.</t>

      <t>Even when such an aggregating is not used, it is still adequate to
      use BIER to save state by sharing one P2MP based BIER "P-tunnel" for
      multi flows in one specific VPN.</t>

      <t>For seamless transitioning from legacy MVPN deployment and existing
      network, it is recommended not to use such an aggregating, as well as to
      use such an aggregating.</t>

      <t/>
    </section>

    <section title="IANA Considerations ">
      <t>Allocation is expected from IANA for two new tunnel type codepoints
      for "RSVP-TE built P2MP based BIER" and "MLDP built P2MP based BIER"
      from the "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel
      Types" registry.</t>
    </section>

    <section title="Security Considerations">
      <t>This document does not introduce any new security considerations
      other than already discussed in [RFC8279].</t>
    </section>

    <section title="Acknowledgements">
      <t>The authors would like to thank Eric Rosen, Tony Przygienda, IJsbrand
      Wijnands and Toerless Eckert for their thoughtful comments and kind suggestions.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.6513'?>

      <?rfc include='reference.RFC.6514'?>

      <?rfc include='reference.RFC.4875'?>

      <?rfc include='reference.RFC.6388'?>

      <?rfc include='reference.RFC.6625'?>

      <?rfc include='reference.RFC.3031'?>

      <?rfc include='reference.RFC.8279'?>

      <?rfc include='reference.RFC.8296'?>

      <?rfc include='reference.I-D.ietf-bier-mvpn'?>

      <?rfc include='reference.I-D.ietf-bess-mvpn-expl-track'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.2119'?>
    </references>
  </back>
</rfc>
