<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8279 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8279.xml">
<!ENTITY RFC8296 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8296.xml">
<!ENTITY RFC7432 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml">
<!ENTITY RFC7024 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7024.xml">
<!ENTITY RFC6513 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6513.xml">
<!ENTITY RFC6514 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6514.xml">
<!ENTITY RFC8401 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8401.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-zzhang-bier-php-01" ipr="trust200902">
  <front>
    <title abbrev="bier-php">BIER Penultimate Hop Popping</title>

    <author fullname="Zhaohui Zhang" initials="Z." surname="Zhang">
      <organization>Juniper Networks</organization>
      <address>
        <email>zzhang@juniper.net</email>
      </address>
    </author>

    <date year="2018"/>

    <workgroup>BIER</workgroup>

    <abstract>
      <t>Bit Index Explicit Replication (BIER) can be used as provider
         tunnel for MVPN/GTM [RFC6514] [RFC7716] or EVPN BUM [RFC7432].
         It is possible that not
         all routers in the provider network support BIER and there are various
         methods to handle BIER incapable transit routers. However the MVPN/EVPN
         PEs are assumed to be BIER capable - they are BFIRs/BFERs. This document
         specifies a method to allow BIER incapable routers to act as MVPN/EVPN
         PEs with BIER as the transport, by having the upstream BFR (connected
         directly or indirectly via a tunnel) of a PE remove the BIER header and
         send the payload to the PE.
      </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 RFC2119.
      </t>
    </note>
  </front>

  <middle>
    <section title="Terminologies">
    <t>Familiarity with BIER/MVPN/EVPN protocols and procedures is assumed.
       Some terminologies are listed below for convenience.
    </t>
    <t>[To be added].
    </t>
    </section>
    <section title="Introduction">
    <t>The BIER architecture includes three layers: the "routing underlay",
       the "BIER layer", and the "multicast flow overlay". The multicast
       flow overlay is responsible for the BFERs to signal to BFIRs that
       they are interested in receiving certain multicast flows so that BFIRs
       can encode the correct bitstring for BIER forwarding by the BIER layer.
    </t>
    <t>MVPN and EVPN are two similar overlays where BGP Auto-Discovery routes
       for MVPN/EVPN are exchanged among all PEs to signal which PEs need to
       receive multicast traffic for all or certain flows. Typically the same
       provider tunnel type is used for traffic to reach all receiving PEs.
    </t>
    <t>Consider an MVPN/EVPN deployment where enough P/PE routers are
       BIER capable for BIER to become the preferred the choice of
       provider tunnel. However, some PEs cannot be upgraded to support BIER
       forwarding. While there are ways to allow an ingress PE to send traffic
       to some PEs with one type of tunnel and send traffic to some other PEs
       with a different type of tunnel, the procedure becomes complicated and
       forwarding is not optimized.
    </t>
    <t>One way to solve this problem is to use Penultimate Hop Popping (PHP)
       so that the upstream BFR can pop the BIER header and send the payload
       "natively" (note that the upstream BFR can be connected directly or
       indiretly via a tunnel to the PE). This is similar to MPLS PHP though
       it is the BIER header that is popped. In case of MPLS encapsulation,
       even the signaling is similar -
       a BIER incapable router signals as if it supported BIER, but to request
       PHP at the penultimate hop, it signals an Implicit Null label instead of
       a regular BIER label as the Label Range Base in its BIER MPLS
       Encapsulation sub-TLV.
    </t>
    <t>In order for the PE to be able to correctly forward the packets
       resulting from the PHP, certain conditions must be met, as specified
       in <xref target='spec'/>.
    </t>
    <t>While the above text uses MVPN/EVPN as example, BIER PHP is applicable
       to any scenario where the multicast flow overlay edge router does not
       support BIER.
    </t>
    <t>This works well if a BIER incapable PE only needs to receive multicast
       traffic. If it needs to send multicast traffic as well, then it must
       Ingress Replicate to a BIER capable helper PE, who will in turn relay
       the packet to other PEs. The helper PE is either a Virtual Hub as
       specified in [RFC7024] for MVPN and [I-D.keyupate-bess-evpn-virtual-hub]
       for EVPN, or an AR-Replicator as specified in
       [I-D.ietf-bess-evpn-optimized-ir] for EVPN.
    </t>
    </section>
    <section title = "Specifications" anchor="spec">
    <t>The procedures in this section can be applied only if, by means outside
       the scope of this document, it is known that one of the following
       conditions is met.
    <list style="symbols">
    <t>The payload after BIER header is IPv4 or IPv6 (i.e., the Proto field
       in the BIER header is 4 or 6).
                   <vspace/>
                   <vspace/>
                   <vspace/>
       Notice that in this case the Destination Address in the IPv4/IPv6
       header must be in the address space for the BIER layer.
    </t>
    <t>The payload after BIER header is MPLS packet with downstream-assigned
       label at top of stack (i.e., the Proto field in the BIER header is 1).
       For example, a label from a Domain-wide Common Block (DCB) is used
       as specified in [I-D.zzhang-bess-mvpn-evpn-aggregation-label].
    </t>
    </list>
    </t>
    <t>A BIER incapable router, if acting as a multicast flow overlay router,
       MUST signal its BIER information as specified in [RFC8401] or 
       [I-D.ietf-bier-ospf-bier-extensions] or
       [I-D.ietf-bier-idr-extensions], with a PHP sub-sub-TLV included in the
       BIER sub-TLV attached to the BIER incapable router's BIER prefix
       to request BIER PHP from other
       BFRs. The sub-sub-TLV's type is TBD, and the length is 0.
    </t>
    <t>With MPLS encapsulation, the BIER incapable multicast flow overlay router
       MAY omit the BIER MPLS Encapsulation sub-sub-TLV, or MUST set the Label
       Range Base in BIER MPLS Encapsulation sub-sub-TLV to
       Implicit Null Label [RFC3032].
    </t>
    <t>With MPLS encapsulation, if a BFER does not support certain BSL,
       it MAY still advertise a corresponding BIER MPLS Encapsulation
       sub-TLV but set the Label Range Base to Implicit Null Label.
    </t>
    <t>If a BFR follows section 6.9 of [RFC8279] to handle BIER incapable
       routers, it must treat a router as BIER incapable if the Label Range
       Base dvertised by the router is Implicit Null, or if the router
       advertises a PHP sub-sub-TLV, so that the router is not
       used as a transit BFR. 
    </t>
    <t>If the downstream neighbor for a BIER prefix is the one advertising the
       prefix with a PHP sub-sub-TLV or with an Implicit Null Label as the
       Label Range Base in its BIER MPLS Encapsulation sub-sub-TLV,
       then when the corresponding BIRT
       or BIFT entry is created/updated, the forwarding behavior MUST be that the
       BIER header is removed and the payload be sent to the downstream router
       without the BIER header, either directly or over a tunnel.
    </t>
    </section>

    <section title="Security Considerations">
    <t>This specification does not introduce additional security concerns
       beyond those already discussed in BIER architecture and OSPF/ISIS/BGP
       exentions for BIER signaling.
    </t>
    </section>

    <section title="IANA Considerations">
    <t>This document requests a new sub-sub-TLV type value from the
       "Sub-sub-TLVs for BIER Info Sub-TLV" registry in
       the "IS-IS TLV Codepoints" registry:
      <figure>
        <artwork>
     Type    Name
     ----    ----
     TBD     BIER PHP Request
        </artwork>
    </figure>
    </t>
    <t>This document also requests a new sub-TLV type value from the
       OSPFv2 Extended Prefix TLV Sub-TLV registry:
      <figure>
        <artwork>
     Type    Name
     ----    ----
     TBD     BIER PHP Request
        </artwork>
    </figure>
    </t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
    <t>The author wants to thank Eric Rosen and Antonie Przygienda for
       their review, comments and suggestions. The author also wants to thank
       Senthil Dhanaraj for his suggestion of requesting PHP if a BFER
       does not support certain BSL.
    </t>
    </section>
   </middle>

  <back>
    <references title="Normative References">
	  &RFC2119;
	  &RFC8279;
	  &RFC8296;
	  &RFC8401;
      <?rfc include='reference.I-D.ietf-bier-ospf-bier-extensions'?>
      <?rfc include='reference.I-D.ietf-bier-idr-extensions'?>
      <?rfc include='reference.I-D.keyupate-bess-evpn-virtual-hub'?>
      <?rfc include='reference.I-D.ietf-bess-evpn-optimized-ir'?>
      <?rfc include='reference.I-D.zzhang-bess-mvpn-evpn-aggregation-label'?>
    </references>
    <references title="Informative References">
      &RFC7432;
      &RFC7024;
      &RFC6513;
      &RFC6514;
    </references>

  </back>
</rfc>

