<?xml version="1.0" encoding="us-ascii"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.17 (Ruby 3.1.2) -->


<!DOCTYPE rfc  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

]>

<?rfc comments="yes"?>

<rfc ipr="trust200902" docName="draft-zzhang-bier-egress-protection-overlay-01" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="BIER-egress-protection">BIER Flow Overlay with Anycast Egress Protection</title>

    <author initials="Z." surname="Zhang" fullname="Zhaohui (Jeffrey) Zhang">
      <organization>Juniper Networks</organization>
      <address>
        <email>zzhang@juniper.net</email>
      </address>
    </author>
    <author initials="I." surname="Wijnands" fullname="IJsbrand Wijnands">
      <organization>Arrcus</organization>
      <address>
        <email>ice@braindump.be</email>
      </address>
    </author>
    <author initials="Z." surname="Zhang" fullname="Zheng Zhang">
      <organization>ZTE</organization>
      <address>
        <email>zhang.zhen@zte.com.cn</email>
      </address>
    </author>
    <author initials="M." surname="Mishra" fullname="Mankamana Mishra">
      <organization>Cisco Systems</organization>
      <address>
        <email>mankamis@cisco.com</email>
      </address>
    </author>
    <author initials="H." surname="Chen" fullname="Huaimo Chen">
      <organization>Futurewei</organization>
      <address>
        <email>Huaimo.chen@futurewei.com</email>
      </address>
    </author>

    <date year="2024" month="February" day="06"/>

    <area>Routing</area>
    <workgroup>BIER Working Group</workgroup>
    <keyword>BIER, egress protection</keyword>

    <abstract>


<t>This document discusses considerations and specifies procedures for multicast
flow overlay when BIER Anycast is used for egress protection in the context
of MVPN and EVPN. Future revisions will cover other flow overlay protocols like
PIM/MLD/mLDP.</t>



    </abstract>



  </front>

  <middle>


<section anchor="introduction"><name>Introduction</name>

<t>For services like L3VPN, service nodes (e.g., VPN CEs) may be multi-homed to
several Provider Edge nodes (PEs) so that if one PE fails traffic can be
quickly delivered by another PE. This applies even to in-flight traffic
before the ingress PE detects failure and switch over to use another egress PE.</t>

<t>Anycast addresses may be used for the multi-homing PEs so that traffic can be
naturally routed/re-routed to any of the available PEs <xref target="RFC8679"/>. When BIER
is used in the provider network for multicast, <xref target="I-D.zzhang-bier-anycast"/>
specifies BIER with anycast as the building block of egress protection for
multicast.</t>

<t>This document discusses considerations and specifies procedures for multicast
flow overlay when BIER anycast is used for egress protection, in the context
of MVPN <xref target="RFC6513"/> <xref target="RFC6514"/> and EVPN <xref target="RFC7432"/>. Future revisions may
cover other flow overlay protocols like PIM/MLD/mLDP.</t>


<section anchor="pece-procedures-for-mvpn-multi-homing"><name>PE/CE Procedures for MVPN Multi-homing</name>

<t>In the following diagram for MVPN <xref target="RFC6513"/> <xref target="RFC6514"/> service:</t>

<figure><artwork><![CDATA[
                         +-----+
                     PE1 |BFER1|_________+---+
  PE0                    +-----+        /|CE1|
 +----+                  +-----+_______/ +---+
 |BFIR|              PE2 |BFER2|_________+---+
 +----+                  +-----+        /|CE2|
                         +-----+_______/ +---+
                     PE3 |BFER3|_________+---+
                         +-----+         |CE3|
                                         +---+
]]></artwork></figure>

<t>CE1 and CE2 are multi-homed to PE1/PE2 (BFER1/BFER2)and PE2/PE3 (BFER2/BFER3)
respectively. CE3 is single-homed to PE3 (BFER3). Each multi-homing group
(PE1/PE2, and PE2/PE3) shares an anycast address that is advertised as
BFR-prefix.</t>

<t>Depending on the underlay routing metric, a multicast packet towards CE1 may
arrive either on PE1 or PE2 but not both (a much higner routing metric to one
of them will lead to consistent primary/secondary behavior) and if it arrives
on PE2 it won&#39;t be delivered to CE2. Similarly, a packet towards CE2 may
arrive either on PE2 or PE3 but not both, but if it arrives on PE2 it won&#39;t be
delivered to CE1, and if it arrives on PE3 it won&#39;t be delivered to CE3.</t>

<t>For PE1/PE2 to deliver the received multicast traffic to CE1, they both
need to receive PIM <xref target="RFC7761"/> join or mLDP <xref target="RFC6388"/> label mapping
if the PE-CE protocol is mLDP from the CE. With the MoFRR <xref target="RFC7431"/> feature
for PIM and mLDP, a multi-homed CE can send PIM join or mLDP label mapping to
both PEs in the multi-homing group, though additional steps are needed:</t>

<t><list style="symbols">
  <t>The CE accepts traffic from any PEs in the multi-homing group because only
one of the PEs will deliver the traffic. Compared to
regular MoFRR scenario, all upstream nodes to which join or label mapping
is sent will receive and deliver traffic so the downstream accepts traffic
from only one of the upstream nodes.</t>
  <t>The PE&#39;s flow overlay signaling protocol for BIER needs to use appropriate
BFR-prefix when signal the flow interest to the BFIRs. In the above example,
PE2 needs to use the anycast BFR-prefix for the PE1/PE2 for flows requested
by CE1, use the anycast BFR-prefix for the PE2/PE3 for flows requested
by CE2, and use the PE3 BFR-prefix for flows requested by CE3.</t>
</list></t>

</section>
<section anchor="evpn-multi-homing"><name>EVPN Multi-homing</name>

<t>The MVPN approach described above does not apply to EVPN, which does not use
anycast.</t>

<t>A more detailed desription may be included in a future revision to explain
why different approaches are taken for MVPN and EVPN.</t>

<t>However, when tunnel segmentation is used, the anycast based approach does
apply to EVPN as well, as described in the following section.</t>

</section>
<section anchor="mvpnevpn-tunnel-segmentation"><name>MVPN/EVPN Tunnel Segmentation</name>

<t>A large BIER sub-domain may have many BFERs - more than the length of BitString.
While multiple copies could be sent, where each copy is for a different set
of the BFERs so that the same bit in different copies corresponds to different
BFERs, smaller BIER sub-domains can be used along with MVPN tunnel segmentation
<xref target="RFC7524"/>. In the latter case, only one copy needs to be sent, and BIER
decapsulation and re-encapsulation happen at the border of sub-domains.</t>

<t>The tunnel segmentation procedures also apply to EVPN and are specified in
<xref target="I-D.ietf-bess-evpn-bum-procedure-updates"/>.</t>

<t>Common to both MVPN and EVPN, ingress PEs advertise I/S-PMSI routes
(the EVPN IMET route is considered as an I-PMSI route as described in
<xref target="I-D.ietf-bess-evpn-bum-procedure-updates"/>), which carry a PMSI Tunnel
Attribute (PTA) that specifies the type and instance of the tunnel that
instantiate the PMSI. When a border router (ASBR, ABR, or the generalized
Reginal Border Router term introduced in
<xref target="I-D.ietf-bess-evpn-bum-procedure-updates"/>) re-advertises the route
to the next region, the type and instance in the PTA are also
changed to identify the tunnel used in the next region.</t>

<t>The border router is referred to as Semgentation Point. It receives/re-advertises
MVPN/EVPN I/S-PMSI, receives and advertises Leaf A-D routes,
and set up appropriate forwarding state. For example, in case of BIER,
it is a BFER for the upstream region
(sub-domain) and BFIR for the downtream region (sub-domain). It switches
traffic based on the service label that comes after the BIER header
after decapsulating incoming BIER header, and encapsulate a new BIER header
for the downtream region (sub-domain).</t>

<t>For redundancy purposes, multiple segemntation points can be used between
a pair upstream and downtream regions, and they can share an anycast address.
In this document, they are referred to as anycast segmentation points.</t>

<t>While EVPN PEs don&#39;t use anycast multi-homing, the anycast procedures on the
segmentation points described here do apply to EVPN tunnel segmentation as well.</t>

<t>When an anycast segmentation point re-advertises a PMSI route to the downstream
region, it uses the anycast address in the Inter-Area P2MP Segmented Next-Hop
Extended Community in case of MVPN inter-area segemntation, or in the BGP Next
Hop in case of MVPN inter-AS segmentation or EVPN inter-region segmetnation.
As a result, when a downstream egress PE or segmentation point sends Leaf A-D
route in response, all segmentation points with the same anycast address
will receive the Leaf A-D routes in the downtream region (just like all
multi-homing MVPN PEs will receive MoFRR joins from their multi-homed CEs)
and send their own Leaf A-D
routes in the upstream region, also using the anycast address.
Only one will receive traffic, and any one
will send received traffic to the downstream region (sub-domain).</t>

<t>While this document is about BIER, the above procedure works when the
upstream and downstream region uses either BIER or Ingress Replication (IR),
including the case where one uses BIER and the other uses IR.</t>

<t>If the downstream region uses another tunnel type, e.g. mLDP, then a downstream
PE or segmentation point can join all the tunnels announced by the anycast
segmentation points and accept traffic on all of them, so that the anycast
segmentation points can easiy protect each other in the upstream BIER/IR
region.</t>

</section>
<section anchor="relationship-with-warm-root-standby"><name>Relationship with Warm Root Standby</name>

<t>With Warm Root Standby procedures in <xref target="RFC9026"/>, an egress PE chooses
a pair of primary/backup ingress PEs and sends C-multicast routes with
corresponding primary/backup indications. Only the primary ingress PE
will send traffic, and the egress PE only accepts traffic from its chosen
primary ingress PE. The protection is about the ingress PE.</t>

<t>With MVPN with BIER Anycast, the protection is about the egress PE or
segmentation point. One of all the anycast egress PE or segmentation
points will receive the traffic and all will send to their multi-homed
downstream (either the CE, or a PE or segmentation point that is the
downstream of &quot;this&quot; segmentation point), who will accept traffic from
all the anycast upstream.</t>

</section>
</section>
<section anchor="specification"><name>Specification</name>

<t>Detailed normative procedures will be added in future revisions.</t>

</section>
<section anchor="security-considerations"><name>Security Considerations</name>

<t>This document does not introduce any new security concerns besides what has
been discussed in <xref target="RFC8279"/>, <xref target="RFC6513"/>, <xref target="RFC8556"/>,
<xref target="I-D.ietf-bier-tether"/> and <xref target="I-D.zzhang-bier-anycast"/>.</t>

</section>


  </middle>

  <back>


    <references title='Normative References'>




<reference anchor='I-D.zzhang-bier-anycast' target='https://datatracker.ietf.org/doc/html/draft-zzhang-bier-anycast-02'>
   <front>
      <title>BIER with Anycast</title>
      <author fullname='Zhaohui (Jeffrey) Zhang' initials='Z. J.' surname='Zhang'>
         <organization>Juniper Networks</organization>
      </author>
      <author fullname='IJsbrand Wijnands' initials='I.' surname='Wijnands'>
         <organization>Arrcus</organization>
      </author>
      <author fullname='Zheng Zhang' initials='Z.' surname='Zhang'>
         <organization>ZTE</organization>
      </author>
      <author fullname='Mankamana Prasad Mishra' initials='M. P.' surname='Mishra'>
         <organization>Cisco Systems</organization>
      </author>
      <author fullname='Huaimo Chen' initials='H.' surname='Chen'>
         <organization>Futurewei</organization>
      </author>
      <date day='11' month='March' year='2023'/>
      <abstract>
	 <t>   BIER architecture currently does not support anycast, in that each
   BIER Forwarding Router (BFR) has its own unique BFR-prefix and BFR-
   ID.  BIER signaling protocols also check if there are duplicate BFR-
   IDs advertised.  This document discusses and specifies anycast
   support with BIER.  It updates RFC 8279, RFC 8401 and RFC 8444.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-zzhang-bier-anycast-02'/>
   
</reference>

<reference anchor='RFC6513' target='https://www.rfc-editor.org/info/rfc6513'>
  <front>
    <title>Multicast in MPLS/BGP IP VPNs</title>
    <author fullname='E. Rosen' initials='E.' role='editor' surname='Rosen'/>
    <author fullname='R. Aggarwal' initials='R.' role='editor' surname='Aggarwal'/>
    <date month='February' year='2012'/>
    <abstract>
      <t>In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='6513'/>
  <seriesInfo name='DOI' value='10.17487/RFC6513'/>
</reference>

<reference anchor='RFC6514' target='https://www.rfc-editor.org/info/rfc6514'>
  <front>
    <title>BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs</title>
    <author fullname='R. Aggarwal' initials='R.' surname='Aggarwal'/>
    <author fullname='E. Rosen' initials='E.' surname='Rosen'/>
    <author fullname='T. Morin' initials='T.' surname='Morin'/>
    <author fullname='Y. Rekhter' initials='Y.' surname='Rekhter'/>
    <date month='February' year='2012'/>
    <abstract>
      <t>This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in RFC 6513. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='6514'/>
  <seriesInfo name='DOI' value='10.17487/RFC6514'/>
</reference>

<reference anchor='RFC7432' target='https://www.rfc-editor.org/info/rfc7432'>
  <front>
    <title>BGP MPLS-Based Ethernet VPN</title>
    <author fullname='A. Sajassi' initials='A.' role='editor' surname='Sajassi'/>
    <author fullname='R. Aggarwal' initials='R.' surname='Aggarwal'/>
    <author fullname='N. Bitar' initials='N.' surname='Bitar'/>
    <author fullname='A. Isaac' initials='A.' surname='Isaac'/>
    <author fullname='J. Uttaro' initials='J.' surname='Uttaro'/>
    <author fullname='J. Drake' initials='J.' surname='Drake'/>
    <author fullname='W. Henderickx' initials='W.' surname='Henderickx'/>
    <date month='February' year='2015'/>
    <abstract>
      <t>This document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN). The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)".</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='7432'/>
  <seriesInfo name='DOI' value='10.17487/RFC7432'/>
</reference>

<reference anchor='RFC7524' target='https://www.rfc-editor.org/info/rfc7524'>
  <front>
    <title>Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs)</title>
    <author fullname='Y. Rekhter' initials='Y.' surname='Rekhter'/>
    <author fullname='E. Rosen' initials='E.' surname='Rosen'/>
    <author fullname='R. Aggarwal' initials='R.' surname='Aggarwal'/>
    <author fullname='T. Morin' initials='T.' surname='Morin'/>
    <author fullname='I. Grosclaude' initials='I.' surname='Grosclaude'/>
    <author fullname='N. Leymann' initials='N.' surname='Leymann'/>
    <author fullname='S. Saad' initials='S.' surname='Saad'/>
    <date month='May' year='2015'/>
    <abstract>
      <t>This document describes procedures for building inter-area point-to-multipoint (P2MP) segmented service label switched paths (LSPs) by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and Label Distribution Protocol (LDP). Within each IGP area, the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP multipoint LDP (mLDP). If ingress replication is used within an IGP area, then (multipoint-to-point) LDP LSPs or (point-to-point) RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP Multicast VPN, Virtual Private LAN Service (VPLS) multicast, or global table multicast over MPLS.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='7524'/>
  <seriesInfo name='DOI' value='10.17487/RFC7524'/>
</reference>


<reference anchor='I-D.ietf-bess-evpn-bum-procedure-updates' target='https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-bum-procedure-updates-14'>
   <front>
      <title>Updates on EVPN BUM Procedures</title>
      <author fullname='Zhaohui (Jeffrey) Zhang' initials='Z. J.' surname='Zhang'>
         <organization>Juniper Networks</organization>
      </author>
      <author fullname='Wen Lin' initials='W.' surname='Lin'>
         <organization>Juniper Networks</organization>
      </author>
      <author fullname='Jorge Rabadan' initials='J.' surname='Rabadan'>
         <organization>Nokia</organization>
      </author>
      <author fullname='Keyur Patel' initials='K.' surname='Patel'>
         <organization>Arrcus</organization>
      </author>
      <author fullname='Ali Sajassi' initials='A.' surname='Sajassi'>
         <organization>Cisco Systems</organization>
      </author>
      <date day='18' month='November' year='2021'/>
      <abstract>
	 <t>This document specifies updated procedures for handling broadcast,
   unknown unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN),
   including selective multicast, and provider tunnel segmentation.
   This document updates RFC 7432.
	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-bess-evpn-bum-procedure-updates-14'/>
   
</reference>

<reference anchor='RFC8279' target='https://www.rfc-editor.org/info/rfc8279'>
  <front>
    <title>Multicast Using Bit Index Explicit Replication (BIER)</title>
    <author fullname='IJ. Wijnands' initials='IJ.' role='editor' surname='Wijnands'/>
    <author fullname='E. Rosen' initials='E.' role='editor' surname='Rosen'/>
    <author fullname='A. Dolganow' initials='A.' surname='Dolganow'/>
    <author fullname='T. Przygienda' initials='T.' surname='Przygienda'/>
    <author fullname='S. Aldrin' initials='S.' surname='Aldrin'/>
    <date month='November' year='2017'/>
    <abstract>
      <t>This document specifies a new architecture for the forwarding of multicast data packets. It provides optimal forwarding of multicast packets through a "multicast domain". However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state. This architecture is known as "Bit Index Explicit Replication" (BIER). When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The procedures for forwarding a packet based on its BIER header are specified in this document. Elimination of the per-flow state and the explicit tree-building protocols results in a considerable simplification.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='8279'/>
  <seriesInfo name='DOI' value='10.17487/RFC8279'/>
</reference>

<reference anchor='RFC8556' target='https://www.rfc-editor.org/info/rfc8556'>
  <front>
    <title>Multicast VPN Using Bit Index Explicit Replication (BIER)</title>
    <author fullname='E. Rosen' initials='E.' role='editor' surname='Rosen'/>
    <author fullname='M. Sivakumar' initials='M.' surname='Sivakumar'/>
    <author fullname='T. Przygienda' initials='T.' surname='Przygienda'/>
    <author fullname='S. Aldrin' initials='S.' surname='Aldrin'/>
    <author fullname='A. Dolganow' initials='A.' surname='Dolganow'/>
    <date month='April' year='2019'/>
    <abstract>
      <t>The Multicast Virtual Private Network (MVPN) specifications require the use of multicast tunnels ("P-tunnels") that traverse a service provider's backbone network. The P-tunnels are used for carrying multicast traffic across the backbone. A variety of P-tunnel types are supported. Bit Index Explicit Replication (BIER) is a new architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. This document specifies the protocol and procedures that allow MVPN to use BIER as the method of carrying multicast traffic over a service provider's backbone network.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='8556'/>
  <seriesInfo name='DOI' value='10.17487/RFC8556'/>
</reference>


<reference anchor='I-D.ietf-bier-tether' target='https://datatracker.ietf.org/doc/html/draft-ietf-bier-tether-04'>
   <front>
      <title>Tethering A BIER Router To A BIER incapable Router</title>
      <author fullname='Zhaohui (Jeffrey) Zhang' initials='Z. J.' surname='Zhang'>
         <organization>Juniper Networks</organization>
      </author>
      <author fullname='Nils Warnke' initials='N.' surname='Warnke'>
         <organization>Deutsche Telekom</organization>
      </author>
      <author fullname='IJsbrand Wijnands' initials='I.' surname='Wijnands'>
         <organization>Arrcus</organization>
      </author>
      <author fullname='Daniel O. Awduche' initials='D. O.' surname='Awduche'>
         <organization>Verizon</organization>
      </author>
      <date day='5' month='July' year='2023'/>
      <abstract>
	 <t>   This document specifies optional procedures to optimize the handling
   of Bit Index Explicit Replication (BIER) incapable routers, by
   attaching (tethering) a BIER router to a BIER incapable router.


	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-bier-tether-04'/>
   
</reference>




    </references>

    <references title='Informative References'>



<reference anchor='RFC8679' target='https://www.rfc-editor.org/info/rfc8679'>
  <front>
    <title>MPLS Egress Protection Framework</title>
    <author fullname='Y. Shen' initials='Y.' surname='Shen'/>
    <author fullname='M. Jeganathan' initials='M.' surname='Jeganathan'/>
    <author fullname='B. Decraene' initials='B.' surname='Decraene'/>
    <author fullname='H. Gredler' initials='H.' surname='Gredler'/>
    <author fullname='C. Michel' initials='C.' surname='Michel'/>
    <author fullname='H. Chen' initials='H.' surname='Chen'/>
    <date month='December' year='2019'/>
    <abstract>
      <t>This document specifies a fast reroute framework for protecting IP/MPLS services and MPLS transport tunnels against egress node and egress link failures. For each type of egress failure, it defines the roles of Point of Local Repair (PLR), protector, and backup egress router and the procedures of establishing a bypass tunnel from a PLR to a protector. It describes the behaviors of these routers in handling an egress failure, including local repair on the PLR and context-based forwarding on the protector. The framework can be used to develop egress protection mechanisms to reduce traffic loss before global repair reacts to an egress failure and control-plane protocols converge on the topology changes due to the egress failure.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='8679'/>
  <seriesInfo name='DOI' value='10.17487/RFC8679'/>
</reference>

<reference anchor='RFC7761' target='https://www.rfc-editor.org/info/rfc7761'>
  <front>
    <title>Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)</title>
    <author fullname='B. Fenner' initials='B.' surname='Fenner'/>
    <author fullname='M. Handley' initials='M.' surname='Handley'/>
    <author fullname='H. Holbrook' initials='H.' surname='Holbrook'/>
    <author fullname='I. Kouvelas' initials='I.' surname='Kouvelas'/>
    <author fullname='R. Parekh' initials='R.' surname='Parekh'/>
    <author fullname='Z. Zhang' initials='Z.' surname='Zhang'/>
    <author fullname='L. Zheng' initials='L.' surname='Zheng'/>
    <date month='March' year='2016'/>
    <abstract>
      <t>This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source.</t>
      <t>This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM Multicast Border Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard.</t>
    </abstract>
  </front>
  <seriesInfo name='STD' value='83'/>
  <seriesInfo name='RFC' value='7761'/>
  <seriesInfo name='DOI' value='10.17487/RFC7761'/>
</reference>

<reference anchor='RFC6388' target='https://www.rfc-editor.org/info/rfc6388'>
  <front>
    <title>Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths</title>
    <author fullname='IJ. Wijnands' initials='IJ.' role='editor' surname='Wijnands'/>
    <author fullname='I. Minei' initials='I.' role='editor' surname='Minei'/>
    <author fullname='K. Kompella' initials='K.' surname='Kompella'/>
    <author fullname='B. Thomas' initials='B.' surname='Thomas'/>
    <date month='November' year='2011'/>
    <abstract>
      <t>This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths (LSPs) in MPLS networks. These extensions are also referred to as multipoint LDP. Multipoint LDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol. Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be various applications for multipoint LSPs, for example IP multicast or support for multicast in BGP/MPLS Layer 3 Virtual Private Networks (L3VPNs). Specification of how such applications can use an LDP signaled multipoint LSP is outside the scope of this document. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='6388'/>
  <seriesInfo name='DOI' value='10.17487/RFC6388'/>
</reference>

<reference anchor='RFC7431' target='https://www.rfc-editor.org/info/rfc7431'>
  <front>
    <title>Multicast-Only Fast Reroute</title>
    <author fullname='A. Karan' initials='A.' surname='Karan'/>
    <author fullname='C. Filsfils' initials='C.' surname='Filsfils'/>
    <author fullname='IJ. Wijnands' initials='IJ.' role='editor' surname='Wijnands'/>
    <author fullname='B. Decraene' initials='B.' surname='Decraene'/>
    <date month='August' year='2015'/>
    <abstract>
      <t>As IPTV deployments grow in number and size, service providers are looking for solutions that minimize the service disruption due to faults in the IP network carrying the packets for these services. This document describes a mechanism for minimizing packet loss in a network when node or link failures occur. Multicast-only Fast Reroute (MoFRR) works by making simple enhancements to multicast routing protocols such as Protocol Independent Multicast (PIM) and Multipoint LDP (mLDP).</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='7431'/>
  <seriesInfo name='DOI' value='10.17487/RFC7431'/>
</reference>

<reference anchor='RFC9026' target='https://www.rfc-editor.org/info/rfc9026'>
  <front>
    <title>Multicast VPN Fast Upstream Failover</title>
    <author fullname='T. Morin' initials='T.' role='editor' surname='Morin'/>
    <author fullname='R. Kebler' initials='R.' role='editor' surname='Kebler'/>
    <author fullname='G. Mirsky' initials='G.' role='editor' surname='Mirsky'/>
    <date month='April' year='2021'/>
    <abstract>
      <t>This document defines Multicast Virtual Private Network (VPN) extensions and procedures that allow fast failover for upstream failures by allowing downstream Provider Edges (PEs) to consider the status of Provider-Tunnels (P-tunnels) when selecting the Upstream PE for a VPN multicast flow. The fast failover is enabled by using "Bidirectional Forwarding Detection (BFD) for Multipoint Networks" (RFC 8562) and the new BGP Attribute, BFD Discriminator. Also, this document introduces a new BGP Community, Standby PE, extending BGP Multicast VPN (MVPN) routing so that a C-multicast route can be advertised toward a Standby Upstream PE.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='9026'/>
  <seriesInfo name='DOI' value='10.17487/RFC9026'/>
</reference>




    </references>



  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA71abXPbNhL+jl+Baz/Uvoh0Yuet/nJxHKVRJ241cuYy05ub
DkRCEmKKZAnSitL4v9+zC4AiKdnN3YfzTDoiCez7PrsLNIoikRSpyZfnsqkX
0cvdk42UTYwRojZ1ps/l68l4Jt9mxUb+equrTG3lxtQreZFvE2VrOV5W2lo5
rYpaJ7UpcqHm80rfuo2R5s9RufucFkmu1iCcVmpRR1++rFS+jOZGV/uLo8Kx
jB4/EYmq9bKotufS1qkQtlZ5+rvKihykttqK0pzLf9VFMpK2qOpKLyx+bdfu
R1Ks1zqv7b+FMGV1LuuqsfXp48c/Pj4VqtLqXM6KpoYBxGbpVf5YVDd4IX+q
iqYUNxv3eiSdkLKjkVBNvSqqcyFlhH9Smtyey99i+Rupxm+cxnguVo2RRz/r
xaLS2+POiqIC45+b3JS6kr/oegP2lr/otTLZuXSGevXJLYlzXYs+w0ksP5pP
OcxiOzwnP9t5hXf9b8ztoqqSpsfDJPoVVps8bdZlPNfiG1TSsNFAjd8+jHuS
09f4C1a++lLrGL6Ik3xA+iqWV8auKtWhfaXyG7VWuep+YgaXxiaFvN7aWq97
Cqx5i7GvElpBrAZ83sXyEoJ0uLxrlFkXu7fM4G1TN5XeaNMl7lbGCSmyCAuI
B60RIooiqea2rlQC13xYGSsR6w3FnUwhTmOttojE3JpUV4pCx0ryjC11YhZG
c1AlOgVhKxdFJddNVhvKMrGg/CtC/kEAF6MhCcGqsTrlTXvxCcVlvdLEudaf
a1Es5NU/p78w6zF+xF5biaw1lqXamCzDevCTBbZWssefSBdJkVmZmRstppOr
k6v3b07W799MY2eGtUnTDNHzvZzkdVWkjU+Ut5DP6uoWceY2y/dnkGAUXsq8
SPHlSMfLeCRJyMuxPYZXt3KunTmiVbGGpnUhrIY8KiPouSWLynG6bClMaZ8t
oLiCeRYSMCGnY7mAIy2yXy0WJpGJykFX/NGY5CbbylRnBiRBfb6FdZzm03Es
2ZeqLDPyEbjCngWsGi0ys1zVgZyYa9hfs60BHA4Wx6BKfrDMmqzMHgeEJis2
KJGC71p+OmyEKYN7VZrSSzD3lmidTbxasxBaQe9W7YGauYKXVQZFgWi1Tk8q
HblfJIPKtxKRQQTVLURV80wztT///Mfs7eXL5y9+vLsDwoTYEyHmfHSVwQu5
w65+AI9A5m+T6E3chXvl1Lu7E7sM4LDmAqOC8pbpzxuTUYWS86xIbkjU/UAH
S9GyjP9POai+JQdH9yUhzALrPn/25OzubvfwFA8hPf3bF0/PTskBe7mKkBDf
mKpykKp/np/7wngHW+nWVGKBH2Qo2JSlXJiKfEgi7TNpoxJh6uJhMZBxzxUh
oXW15B11wcbp2ZPbgxgynrQyiu+/R0ieXI4p57tOYiGvOnkgxMTZe1FkEJXi
JjVqWan1br0L7Nb0/9iZ3qPRuWD0v/fvUUR/j+5fNB0/kV9fvx3Pnnz9Pfw9
6myZjh8/QDc8nny9HD/5KnafHt27xfM4kR0uEGAy+zoU7NQJdnpQsL/g0hXs
9Os32eiQYIf+puMzJ9jZYYs9zKV9hmBnfyHYIRKPhICpOcyhmURjOKg55NET
Mt4Re/WETXhM6/HyhITnD6f84exYID5LAoBbnW3ReOA7ssAiGjPdpem3nR3H
cqxQF3qIvuT+88hzdknouaHCrRTlAABe9WuFL3z4lCJLa0PIpKx4/XaG9lov
zGfk5Btd6pwxtXDJ0uSpg43KNcNI0Loy6KjVDgZlqZIbjeJSbFSVWkkGIwhS
VQU1pTaMDyBIwV9UHGrzpkZdruUc4CGPiBiUXJlljpV9VmQPlGrhKtHaNSKZ
Vmwohm20fACQsjJrVW1PrMbLFL8AJyt1a4rqmA2Eim9gC5bJCpbmlN5sivyH
mqBnV+tBGM6O5bVZo+pV2ZbU3VPy9D4lT52SZz0lR/zUE0LuCyEGQjwZ7cvu
tp09JPtZ7BqrEJt46VewUyudaDykHReGxiBwxbItyy1y7aj6TVQwPDS+ePH8
CaDxUwF8p7KIChJA8+zlS3xBx6AzWKksCX+NayWm4whoHaoQxSNvXFRomun7
5ZiGFkQFPVwVb2ezwO7pGbFbaGpatCDQJlnIPkShDUmfRmBCXY7VlBxY1xOz
Jxl1jhyH1Nv4oryfb2STolmuKJ0MFXD0mYi80jIokJV0ivLwd/mBlZAqSXRZ
7zpLVpBaqge5wJmJouavyLMt4Iqa1CIYznfhXVd66kCSYl0qFwDYVullg8j1
9rOJzlVlCpgI25sSA4lG2XN9MVy7WRlkXzBQ32uS8YkSjHmHKCCrt3J4Da0r
2WmxyT2HgQ1AjK1AunU160sUextOxz/YfutigQ8qI1u14UNRwD0COcC2nXOJ
BQAEVWvw3CGc69EcGdcLEHk0G0gdSgLfc6A62lj6dkHNC8rvz2pdZnokXKXs
ceNVHms7vEIzHpKQnomfhRH/aMBPp6CGuYIT7psIuYLyACFfDAIxWj0gNNjo
thFeoJEa7/dM5Ag3GpJJqRLBQ0ll5lQ82DJpgSAilKNpaEs2GfP85oKq/QqR
hNeNxhi5prkIgxDmCk2hZCtTcsfuG0GTJ1njm0c1bB+Ji/5cZsrkYrPCmGYW
C7gwr1sxtUvLWt3ofNfftfOtEO+KDQ2LIxcSdZPnCHqrl9RWKjcju+591HPL
XHHZbI0B9URPcRpONjrLRvRjZysz7D2tmwKc4Um4E979wQly3RGErIVcXvpm
2DbzKC3WUJ1NhRKn6YxjK6lfsDJylkWtdxwznS8Bbci016a+RkHNl7H4uILV
HfogqFFFS8MzUJOlZHtKdzYMCGlSEwu2ZA8ypOpY2+ra12XPvZ0z8caqNWY0
VClIutvS8qqoE0Kl5jRqvwumg+l/DajS1VBl6ydXN1fRUd/SjYbs3gNeFH5U
enb6lEYln9OZqpHyoGX1aIdGrGWb2a0dKGh4vE0BzaUFrnJ40GuMyzrvvlwh
FhBO3gLzoqLxFxbqaBC7pDoUcZ05U2Uw5SCwwJBiOsylFFTCz9BG14toTiel
+rbMo3mzjlpiUVOmAEIL/dHMYnBy+cMVr5cVo84ZRadLlJOT62h6dT1xhwRW
HJFuLNLkavzBvaXoCDM095XUgE4624bp8N9JfhzwJEETtEUMMmGXLOKiRljP
icfR9MPFsYvA3fTOZXJbupoFB9QqT9rS491AW4T7VlPVcOgJHv54QwVfsi6V
PLq4fj0byQv6j0fnpc7p7Ml8ARrP9NJQiXntNs3cJvxbU7Hh06//xQgUb61b
nGIsj/CFK9efayr9fLpwWG2PQ7ATxxKFmUjo/MU1eXAfDLDYdm3TPdLpcPBx
3LeLodKCTPadKHx+rdfLNsCnaDFqZGEd+gh70lNJ7IAwBN2oXeoSYKf+e60W
8iJ648NyJPjQBi06uqhOA0CgRS07gy7k0LGk1jgUdNKMcIARkk7zhXFDEiNa
W3vbFsUpL452Ge3GC2oa2tXUAnWXy+5y1t8d90Hj0Dy5wuKnrnD26VoxjucE
TS2kWtS+8WNgXGEM0pVwbzvwBFVRP11b2VnosGyHWPA/PLrp0fo2Fdx4AS9j
PkRcbWXZVGUBr4x2VQXQptcttJHn++g91/VG61zQaGWqnYW5tRxwt050nkq4
q19x9O7NuLE75OkcLPlRRnH30IvMsLUPwSwn9HMlkkOR0DDlScudyrpt3d69
3yN0YNz5Uxxg0QFDrrPpEO4PFQjfW7B4hEr5A0oMwMJDpsPietipi4AahpW0
PX3C+YHHgAm1y9EFtsnp6dU09CpQ5BegQ/SuKMX4M0Zyat6o3DS5qbfdNOOi
w013RBdtvUBhOPWMXv80ZZLo1cp79l9c9zXH5vHuq49cXlHnyvVbF2QL6AP3
+eZPdUeW9rBd8sXEnlVpntxhj/DFL5eum6F+gmasQw7fhKGWG6OBcUVvuqJV
A3gLRtnPy08NyPBZLjiL3kh5FcK3R90NhTTu2XbsNtVgeLbHHk9d2uE7GA/0
boUaoOPItS+N5eF6P5Ji8WvoufpqOyx0uc63D7l2hmEx2mOLzmHFYOA8jFUu
l3uwwBA/hxL+Cnc36bXZK/m+1c8HSOI9gOrz5LTxx0AMqIifie+nZrrMTOKi
4WgyO0aR4fEm2Icj2/XbZBQm5U++2fr+iJ3fT2bQaLK4R3NeEi6OQnODLmAk
6QLNH5TUw6gX94Y7gS0fDFBU75oC4pEXTZ64CbLj44NYx/7ks4DWd4Uj6U/1
Rr3J4SFSJJBW1mzDVYqbUJzCw3AkG55MZqLtWDBrzbTr1e3KlC4nPyr0ZbMC
Q+o1/R8E8y0i5uD7LrKDlTuW+vHx6fO7O4rZDnYkq4KqYaht0DIcT85VctOU
/U7b55mVl9HuRM5nGEkodtOSO/wYkEp9bNlYcmK5yzde1GHUyaReotHqDuoR
gYNnV4asv4JaudgnHvORTfeGOeRX/+4z9rZlZGLrd2+tR+He8CCVLjQfiA1S
nutDCNWAOvdCumiReYC9QW+OW3zrWK7YR0vRScMjjwDuJJOrmbq/mIQTeYKX
DhHo8B2h1XcH9vAkVDiJBilFXhJD5UMuUPDLazcUJf5c4U04fsmLaq3oTqIb
4cziL+7wQFInTUUF/rJ3g7p30xrOgdr5hwGeuk8bKGB+THSFooRJyNDR5IbM
s1JWzNEntpe1qcs9GutfntIV9Kh3ZRqeXj57RnnZH7HojrnW5CF/nfrQHXQs
/gO0+Z4pFCUAAA==

-->

</rfc>

