<?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-pim-signaling-12"
     ipr="trust200902">
  <front>
    <title abbrev="PIM Signaling Through BIER Core">PIM 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="Fengman Xu" initials="F." surname="Xu">
      <organization>Verizon</organization>

      <address>
        <postal>
          <street/>

          <city>Richardson</city>

          <region/>

          <code/>

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

        <phone/>

        <email>fengman.xu@verizon.com</email>

        <uri/>
      </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>

    <date day="25" month="July" year="2021"/>

    <abstract>
      <t>Consider large networks deploying traditional PIM multicast service.
      Typically, each portion of these large networks have their own mandates
      and requirements. It might be desirable to deploy BIER technology in
      some part of these networks to replace traditional PIM services. In such
      cases downstream PIM states need to be signaled over the BIER Domain
      toward the source.</t>

      <t>This draft specifies the procedure to signal PIM join/prune messages
      through a BIER Domain, as such enabling the provisioning of traditional
      PIM services through a BIER Domain. These procedures are valid for
      forwarding PIM join/prune messages to the Source (SSM) or Rendezvous
      Point (ASM).</t>
    </abstract>
  </front>

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

      <t>It might be desirable to simplify/upgrade some part of an existing
      network to BIER technology, removing any legacy multicast protocols like
      PIM. This simplification should be done with minimum interruption or
      disruption to the other parts of the network from singling, services and
      software upgrade point of view. To do so this draft is specifies
      procedures for signaling multicast join and prune messages over the BIER
      domain, this draft is not trying to create FULL PIM adjacency over a
      BIER domain between two PIM nodes. The PIM adjacency is terminated at
      BIER edge routers and only join/prune signaling messages are transported
      over the BIER network. It just so happened that this draft chose
      signaling messages to be in par with PIM join/prune messages. These
      signaling messages are forwarded upstream toward the BIER edge router on
      path to the Source or Rendezvous point. These signaling messages are
      encapsulated in a BIER header.</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", "NOT RECOMMENDED", "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in BCP 14
      <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,
      they appear in all capitals, as shown here.</t>

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

        <t>An understanding of the BIER architecture <xref target="RFC8279"/>
        and the related terminology is expected. The following are some of the
        new definitions used in this draft.</t>

        <t>BBR:</t>

        <t>BIER Boundary router. A router between the PIM domain and BIER
        domain. Maintains PIM adjacency for all routers attached to it on the
        PIM domain and terminates the PIM adjacency toward the BIER
        domain.</t>

        <t>IBBR:</t>

        <t>Ingress BIER Boundary Router. An ingress router from signaling
        point of view. It maintains PIM adjacency toward the PIM domain and
        signals join/prune messages across the BIER domain to EBBR as
        needed.</t>

        <t>EBBR:</t>

        <t>Egress BIER Boundary Router. An egress router in BIER domain from
        signaling point of view. It maintains PIM adjacency to all upstream
        PIM routers. It terminates the BIER signaling packets and creates
        necessary PIM join/prune messages into PIM Domain.</t>
      </section>
    </section>

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

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

                  EBBR                  IBBR 
Sig  <-----PIM-----|<--BIER Tunneling----|<----PIM------ 
(new)
                  BFIR                  BFER
     ------------->|--------BIER-------->|-------------> Datapath
                                                      (no change)]]></artwork>
      </figure>

      <t>Figure 1 illustrates the operation of the BIER Boundary router (BBR).
      BBRs are connected to PIM routers in the PIM domain and BIER routers in
      the BIER domain. PIM routers in PIM domain continue to send PIM state
      messages to the BBR. The BBR will create PIM adjacency between all the
      PIM routers attached to it on the PIM domain. Each BBR determines if a
      BIER Signaling Join or Prune message needs to be transmitted through the
      BIER domain. This draft has chosen these BIER signaling messages to be
      PIM join/prune message, as such an implementation could chose to tunnel
      actual PIM join/prune messages through BIER network. This tunneling is
      only done for signaling purposes and not for creating a PIM adjacency
      between the two disjoint PIM domains through the BIER domain.</t>

      <t>The terminology ingress BBR (IBBR) and egress BBR (EBBR) is relative
      only from a signaling point of view.</t>

      <t>The egress BBR will determine if the arriving BIER packet is a
      signaling packet and if so it will generate a PIM join/prune packet
      toward its attached PIM domain.</t>

      <t>The new procedures in this draft are only applicable to signaling and
      there are no changes from datapath point of view.</t>

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

        <t>The IBBR maintains a PIM adjacency <xref target="RFC7761"/> with
        any PIM router attached to it on the PIM domain.</t>

        <t>When a PIM Join or Prune message is received, the IBBR determines
        whether the Source or RP is reachable through the BIER domain. The
        EBBR is the BFR through which the Source or RP is reachable. In PIM
        terms <xref target="RFC7761"/>, the EBBR is the RPF Neighbor, and the
        RPF Interface is the BIER "tunnel" used to reach it. The mechanisms
        used to find the EBBR are outside the scope of this document and there
        can be many mechanism depending on if the source or RP are in same
        area or autonomous system (AS) or in different area or AS -- some
        examples are provided in Appendix A.</t>

        <t>If the lookup for source or rendezvous point results into multiple
        EBBRs, different IBBRs could choose different EBBRs for the same flow.
        As long as a unique IBBR chooses a unique EBBR for the same flow. On
        downstream these EBBRs will send traffic to their corresponding
        IBBRs.</t>

        <t>After discovering the EBBR and its BFR-id, the IBBR MUST use the
        BIER Information Vector (Section 3.1.1) which is a PIM Join Attribute
        type <xref target="RFC5384"/>. The EBBR uses this attribute to obtain
        the necessary BIER information to build its multicast state. The
        signaling packet, in this case a PIM Join/Prune message, is
        encapsulated in the BIER Header and forwarded through the BIER domain
        to the EBBR. The source address of the PIM packets MUST be set to IBBR
        local BFR-prefix. The destination address MUST be set to
        ALL-PIM-ROUTERS <xref target="RFC7761"/>.</t>

        <t>The IBBR will track all the PIM interfaces on the attached PIM
        domain which are interested in a certain (S,G). It creates multicast
        states for arriving join messages from PIM domain, with incoming
        interface as BIER "tunnel" interface and outgoing interface as the PIM
        domain interface(s) on which PIM Join(s) were received on.</t>

        <section title="New Pim Join Attribute, BIER Information Vector">
          <!-- 3.1.3 -->

          <t>The new PIM Join Attribute " BIER Information Vector" is defined
          as follow based on <xref target="RFC5384"/></t>

          <figure anchor="PIM-Join" title="PIM Join Attribute">
            <artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E|Attr_Type  |     Length  |  Addr Family    | BIER info
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...]]></artwork>
          </figure>

          <t>F bit: Transitive Attribute, as specified in <xref
          target="RFC5384"/>. MUST be set to zero as this attribute is always
          non-transitive. If EBBR receives this attribute type with the F bit
          set it must discard the Attribute.</t>

          <t>E bit: End of Attributes, as specified in <xref
          target="RFC5384"/></t>

          <t>Attr_Type: TBD assign by IANA.</t>

          <t>Length: Length of the value field, as specified in <xref
          target="RFC5384"/>. MUST be set to the length of the BIER Info field
          + 1. For IPv4 the length is 8, and 20 for IPv6. Incorrect length
          value compare to the Addr Family must be discarded.</t>

          <t>Addr Family: PIM address family as specified in <xref
          target="RFC7761"/>. Unrecognized Address Family must be
          discarded.</t>

          <figure anchor="PIM-Join-detail" title="PIM Join Attribute detail">
            <artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                 IBBR Prefix IPv4 or IPv6                      ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-domain-id |        BFR-id                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
          </figure>

          <t>BIER Info: IBBR's BFR-prefix (IPv4 or IPv6), sub-domain-id,
          BFR-id</t>

          <section title="BIER packet construction at the IBBR">
            <!-- 3.1.3.1 -->

            <t>The BIER header will be encoded with the BFR-id of the
            IBBR(with appropriate bit set in the BitString) and the PIM
            signaling packet is then encapsulated in the packet.</t>

            <figure anchor="bier-header" title="BIER header">
              <artwork align="center"><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|              BIFT-id                  | TC  |S|     TTL       | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|Nibble |  Ver  |  BSL  |              Entropy                  | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|OAM|Rsv|    DSCP   |   Proto   |            BFIR-id            | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                BitString  (first 32 bits)                     ~ 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
~                                                               ~ 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
~                BitString  (last 32 bits)                      | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
            </figure>

            <t>BIERHeader.Proto = PIM Addrress Family</t>

            <t>BIERHeader.BitString= Bit corresponding to the BFR-id of the
            EBBR</t>

            <t>BIERHeader.BFIR-id = BFR-Id of the BBR originating the
            encapsulated signaling packet, i.e. the IBBR.</t>

            <t>Rest of the values in the BIER header are determined based on
            the network (MPLS/non-MPLS), capabilities (BSL), and network
            configuration.</t>
          </section>
        </section>
      </section>

      <section title="Signaling PIM through the BIER domain procedure">
        <!-- 3.2 -->

        <t>Throughout the BIER domain the BIER forwarding procedure is
        according to <xref target="RFC8279"/>. No BIER router will examine the
        BIER the signaling packet. As such there is no multicast state built
        in the BIER domain.</t>

        <t>The packet will be forwarded through the BIER domain until it
        reaches the EBBR indicated by the BIERHeader.Bitstring. Only this
        targeted EBBR router will remove the BIER header and examine the PIM
        IPv4 or IPv6 signaling packet further as per EBBR Procedure
        section.</t>
      </section>

      <section title="EBBR procedure">
        <!-- 3.3 -->

        <t>EBBR removes the BIER Header and determine this is a signaling
        packet. The Received signaling packet, PIM join/prune message, is
        processed as if it were received from neighbors on a virtual
        interface, (i.e. as if the pim adjacency was present, regardless of
        the fact that there is no adjacency).</t>

        <t>The EBBR will build a forwarding table for the arriving (S,G) using
        the obtained BFIR-id and the Sub-Domain information from BIER Header
        and/or the PIM join Attributes added to the signaling packet. In short
        it tracks all IBBRs interested in this (S,G). For a specific Source
        and Group, EBBR SHOULD track all the interested IBBRs via signaling
        messages arriving from the BIER Domain. BFER builds its (s,g)
        forwarding state with incoming interface (IIF) as the Reverse Path
        Forwarding (RPF) interface (in attached PIM domain) towards the source
        or rendezvous point. The outgoing interfaces include a virtual
        interface that represent BIER forwarding to tracked IBBRs.</t>

        <t>The EBBR maintains a PIM adjacency <xref target="RFC7761"/> with
        any PIM router attached to it on the PIM domain. At this point the
        end-to-end multicast traffic flow setup is complete.</t>
      </section>
    </section>

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

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

        <t>When multicast data traffic arrives on the BFIR (EBBR) it forwards
        the traffic, through the BIER domain, to all interested IBBRs
        following the procedures specified in <xref target="RFC8279"/>. The
        BFER(s) (IBBR(s)) also follow the procedures in <xref
        target="RFC8279"/> and forward the multicast packet through its
        outgoing interface(s).</t>
      </section>
    </section>

    <section title="PIM-SM behavior">
      <!-- 5 -->

      <t>The procedures described in this document can be used with Any-Source
      Mutlicast (ASM) as long as a static Rendezvous Point (RP) or embedded RP
      for IPv6 is used<xref target="RFC3956"/>.</t>

      <t>It should be noted that this draft only signals PIM Joins and Prunes
      through the BIER domain and not any other PIM message types including
      PIM Hellos or Asserts. As such functionality related to these other type
      of massages will not be possible through a BIER domain with this draft
      and future drafts might cover these scenarios. As an example DR
      selection should be done in the PIM domain or if the PIM routers
      attached to IBBRs are performing DR selection there needs to be a
      dedicated PIM interface between these routers. The register messages are
      unicas encapsulatedt from the source to RP as such they are forwarded
      without these procedures.</t>

      <t>In case of PIM ASM Static RP or embedded RP for IPv6 the procedure
      for leaves joining RP is the same as above. It should be noted that for
      ASM, the EBBRs are determined with respect to the RP instead of the
      source.</t>
    </section>

    <section title="Applicability to MVPN">
      <!-- 6 -->

      <t>With just minor changes, the above procedures apply to MVPN as well,
      with BFIR/BFER/EBBR/IBBR being VPN PEs. All the PIM related procedures,
      and the determination of EBBR happens in the context of a VRF, following
      procedures for PIM-MVPN.</t>

      <t>When a PIM packet arrives from PIM domain attached to the VRF (IBBR),
      and it is determined that the source is reachable via the VRF through
      the BIER domain, a PIM signaling message is sent via BIER to the EBBR.
      In this case usually the PE terminating the PIM-MVPN is the EBBR. A
      label is imposed before the BIER header is imposed, and the "proto"
      field in the BIER header is set to 1 (for "MPLS packet with
      downstream-assigned label at top of stack"). The label is advertised by
      the EBBR/BFIR to associate incoming packets to its correct VRF. In many
      scenarios a label is already bound to the VRF loopback address on the
      EBBR/BFIR and it can be used.</t>

      <t>When a multicast data packet is sent via BIER by an EBBR/BFIR, a
      label is imposed before the BIER packet is imposed, and the "proto"
      field in the BIER header is set to 1 (for "MPLS packet with
      downstream-assigned label at top of stack"). The label is assigned to
      the VPN consistently on all VRFs <xref
      target="draft-zzhang-bess-mvpn-evpn-aggregation-label-01"/>.</t>

      <t>If the more complicated label allocation scheme is needed for the
      data packets as specified in <xref
      target="draft-zzhang-bess-mvpn-evpn-aggregation-label-01"/>, then
      additional PMSI signaling is needed as specified in <xref
      target="RFC6513"/>.</t>

      <t>To support per-area subdomain in this case, the ABRs would need to
      become VPN PEs and maintain per-VPN state so it is unlikely
      practical.</t>
    </section>

    <section title="IANA Considerations">
      <!-- 7 -->

      <t>IANA is requested to assign a value (TBD) to the BIER Information
      Vector PIM Join Attribute from the PIM Join Attribute Types
      registry.</t>
    </section>

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

      <t>The procedures of this document do not, in themselves, provide
      privacy, integrity, or authentication for the control plane or the data
      plane. For a discussion of the security considerations regarding the use
      of BIER, please see <xref target="RFC8279"/> and <xref
      target="RFC8296"/>. The security consideration for <xref
      target="RFC7761"/> aslso apply.</t>
    </section>

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

      <t>The authors would like to thank Eric Rosen, Stig Venaas for thier
      reviews and comments.</t>
    </section>
  </middle>

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

      <reference anchor="RFC8279">
        <front>
          <title>Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T. and S.
          Aldrin, "Multicast using Bit Index Explicit Replication"</title>

          <author>
            <organization/>
          </author>

          <date month="October" year="2016"/>
        </front>
      </reference>

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

          <author>
            <organization/>
          </author>

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

      <reference anchor="RFC8174">
        <front>
          <title>B. Leiba, "ambiguity of Uppercase vs Lowercase in RFC 2119
          Key Words"</title>

          <author>
            <organization/>
          </author>

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

      <reference anchor="RFC5384">
        <front>
          <title>A. Boers, I. Wijnands, E. Rosen, "PIM Join Attribute
          Format"</title>

          <author>
            <organization/>
          </author>

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

      <reference anchor="RFC7761">
        <front>
          <title>B.Fenner, M.Handley, H. Holbrook, I. Kouvelas, R. Parekh,
          Z.Zhang "PIM Sparse Mode"</title>

          <author>
            <organization/>
          </author>

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

      <reference anchor="RFC8296">
        <front>
          <title>IJ. Wijnands, E. Rosen, A. Dolganow, J. Yantsura, S. Aldrin,
          I. Meilik, "Encapsulation for BIER"</title>

          <author>
            <organization/>
          </author>

          <date month="January" year="2018"/>
        </front>
      </reference>
    </references>

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

      <reference anchor="RFC6513">
        <front>
          <title>E. Rosen, R. Aggarwal, "Multicast in MPLS/BGP IP
          VPNs"</title>

          <author>
            <organization/>
          </author>

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

      <reference anchor="RFC3956">
        <front>
          <title>P.Savola, B. Haberman "Embedding the Rendezvous Point (RP)
          Address in an IPv6 Multicast Address"</title>

          <author>
            <organization/>
          </author>

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

      <reference anchor="draft-zzhang-bess-mvpn-evpn-aggregation-label-01">
        <front>
          <title>Z. Zhang, E. Rosen, W. Lin, Z. Li, I.Wijnands, "MVPN/EVPN
          Tunnel Aggregation with Common labels"</title>

          <author>
            <organization/>
          </author>

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

    <section title="Determining the EBBR">
      <!-- Appendix A -->

      <t>This appendix provides some examples of routing procedures that can
      be used to determine the EBBR at the IBBR.</t>

      <section title="Link-State Protocols">
        <!-- Appendix A.1 -->

        <t>On IBBR SPF procedures can be used to find the EBBR closest to the
        source.</t>

        <t>Assuming the BIER domain consists of all BIER forwarding routers,
        SPF calculation can identify the router advertising the prefix for the
        source. A post process can find the EBBR by walking from the
        advertising router back to the IBBR in the reverse direction of
        shortest path tree branch until the first BFR is encountered.</t>
      </section>

      <section title="Indirect next-hop">
        <!-- Appendix A.2 -->

        <t>Alternatively, the route to the source could have an indirect
        next-hop that identifies the EBBR. These methods are explained in the
        following sections.</t>

        <section title="Static Route">
          <!-- Appendix A.2.1 -->

          <t>A static route to the source can be configured on the IBBR with
          the next-hop set as the EBBR's BFR-prefix.</t>
        </section>

        <section title="Interior Border Gateway Protocol (iBGP)">
          <!-- Appendix A2.2 -->

          <t>Consider the following topology:</t>

          <figure anchor="static-route" title="Static Route">
            <artwork align="center"><![CDATA[
                      EBBR                  IBBR
        |--PIM Domain--|-----BIER domain-----|--PIM domain--| 
   S--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--h]]></artwork>
          </figure>

          <t>Suppose BGP is enable between EBBR (B) and IBBR (D) and the PIM
          Domain routes are redistributed to the BIER domain via BGP,
          performing next-hop-self for these routes. This would include the
          Multicast Source IP address (S). In such case BGP should use the
          same next-hop as the EBBR BIER prefix. This will ensure that all PIM
          domain routes, including the Multicast Source IP address (S) are
          resolve via EBBR's BIER prefix address. When the host (h) triggers a
          PIM join message to IBBR (D), IBBR tries to resolve (S). It resolves
          (S) via BGP installed route and realizes its next-hop is EBBR
          (B).</t>
        </section>
      </section>

      <section title="Inter-area support">
        <!-- Appendix A3 -->

        <t>If each area has its own BIER sub-domain, the above procedure for
        post-SPF could identify one of the ABRs and the EBBR. If a sub-domain
        spans multiple areas, then additional procedures as described in A.2
        is needed.</t>

        <section title="Inter-area Route summarization">
          <!-- Appendix A3.1 -->

          <t>In a multi-area topology, a BIER sub-domain can span a single
          area. Suppose this single area is constructed entirely of BIER
          capable routers and the ABRs are the BIER Boundary Routers attaching
          the BIER sub-domain in this area to PIM domains in adjacent areas.
          These BBRs can summarize the PIM domain routes via summary routes,
          as an example for OSPF, a type 3 summary LSAs can be used to
          advertise summary routes from a PIM domain area to the BIER area. In
          such scenarios the IBBR can be configured to look up the Source via
          IGP database and use the summary routes and its Advertising Router
          field to resolve the EBBR. The IBBR needs to ensure that the IGP
          summary route is generated by a BFR. This can be achieved by
          ensuring that BIER Sub-TLV exists for this route. If multiple BBRs
          (ABRs) have generated the same summary route the lowest Advertising
          Router IP can be selected or a vendor specific hashing algorithm can
          select the summary route from one of the BBRs.</t>
        </section>
      </section>
    </section>
  </back>
</rfc>
<!-- generated from file C:\Users\hbidgoli\Downloads\draft-ietf-bier-pim-signaling-08.nroff with nroff2xml 0.1.0 by Tomek Mrugalski -->
