<?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-00" 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>

    <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-00'>
   <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='8' month='February' 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-00'/>
   
</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'><organization/></author>
<author fullname='R. Aggarwal' initials='R.' role='editor' surname='Aggarwal'><organization/></author>
<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'><organization/></author>
<author fullname='E. Rosen' initials='E.' surname='Rosen'><organization/></author>
<author fullname='T. Morin' initials='T.' surname='Morin'><organization/></author>
<author fullname='Y. Rekhter' initials='Y.' surname='Rekhter'><organization/></author>
<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'><organization/></author>
<author fullname='R. Aggarwal' initials='R.' surname='Aggarwal'><organization/></author>
<author fullname='N. Bitar' initials='N.' surname='Bitar'><organization/></author>
<author fullname='A. Isaac' initials='A.' surname='Isaac'><organization/></author>
<author fullname='J. Uttaro' initials='J.' surname='Uttaro'><organization/></author>
<author fullname='J. Drake' initials='J.' surname='Drake'><organization/></author>
<author fullname='W. Henderickx' initials='W.' surname='Henderickx'><organization/></author>
<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 -- &quot;Requirements for Ethernet VPN (EVPN)&quot;.</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'><organization/></author>
<author fullname='E. Rosen' initials='E.' surname='Rosen'><organization/></author>
<author fullname='R. Aggarwal' initials='R.' surname='Aggarwal'><organization/></author>
<author fullname='T. Morin' initials='T.' surname='Morin'><organization/></author>
<author fullname='I. Grosclaude' initials='I.' surname='Grosclaude'><organization/></author>
<author fullname='N. Leymann' initials='N.' surname='Leymann'><organization/></author>
<author fullname='S. Saad' initials='S.' surname='Saad'><organization/></author>
<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'><organization/></author>
<author fullname='E. Rosen' initials='E.' role='editor' surname='Rosen'><organization/></author>
<author fullname='A. Dolganow' initials='A.' surname='Dolganow'><organization/></author>
<author fullname='T. Przygienda' initials='T.' surname='Przygienda'><organization/></author>
<author fullname='S. Aldrin' initials='S.' surname='Aldrin'><organization/></author>
<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 &quot;multicast domain&quot;.  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 &quot;Bit Index Explicit Replication&quot; (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'><organization/></author>
<author fullname='M. Sivakumar' initials='M.' surname='Sivakumar'><organization/></author>
<author fullname='T. Przygienda' initials='T.' surname='Przygienda'><organization/></author>
<author fullname='S. Aldrin' initials='S.' surname='Aldrin'><organization/></author>
<author fullname='A. Dolganow' initials='A.' surname='Dolganow'><organization/></author>
<date month='April' year='2019'/>
<abstract><t>The Multicast Virtual Private Network (MVPN) specifications require the use of multicast tunnels (&quot;P-tunnels&quot;) 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 &quot;multicast domain&quot;, 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-03'>
   <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='4' month='January' 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-03'/>
   
</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'><organization/></author>
<author fullname='M. Jeganathan' initials='M.' surname='Jeganathan'><organization/></author>
<author fullname='B. Decraene' initials='B.' surname='Decraene'><organization/></author>
<author fullname='H. Gredler' initials='H.' surname='Gredler'><organization/></author>
<author fullname='C. Michel' initials='C.' surname='Michel'><organization/></author>
<author fullname='H. Chen' initials='H.' surname='Chen'><organization/></author>
<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'><organization/></author>
<author fullname='M. Handley' initials='M.' surname='Handley'><organization/></author>
<author fullname='H. Holbrook' initials='H.' surname='Holbrook'><organization/></author>
<author fullname='I. Kouvelas' initials='I.' surname='Kouvelas'><organization/></author>
<author fullname='R. Parekh' initials='R.' surname='Parekh'><organization/></author>
<author fullname='Z. Zhang' initials='Z.' surname='Zhang'><organization/></author>
<author fullname='L. Zheng' initials='L.' surname='Zheng'><organization/></author>
<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'><organization/></author>
<author fullname='I. Minei' initials='I.' role='editor' surname='Minei'><organization/></author>
<author fullname='K. Kompella' initials='K.' surname='Kompella'><organization/></author>
<author fullname='B. Thomas' initials='B.' surname='Thomas'><organization/></author>
<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'><organization/></author>
<author fullname='C. Filsfils' initials='C.' surname='Filsfils'><organization/></author>
<author fullname='IJ. Wijnands' initials='IJ.' role='editor' surname='Wijnands'><organization/></author>
<author fullname='B. Decraene' initials='B.' surname='Decraene'><organization/></author>
<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'><organization/></author>
<author fullname='R. Kebler' initials='R.' role='editor' surname='Kebler'><organization/></author>
<author fullname='G. Mirsky' initials='G.' role='editor' surname='Mirsky'><organization/></author>
<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 &quot;Bidirectional Forwarding Detection (BFD) for Multipoint Networks&quot; (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
DkRCEmKKYAnSitL4v9+zC5AiKdnN3YfzTDoiCez7PrsLNIoikdjU5MtzWVeL
6OXuyUXKJcYIUZkq0+fy9WQ8k28zu5G/3uoyU1u5MdVKXuTbRLlKjpeldk5O
S1vppDI2F2o+L/Wt3xhp/hwVu8+pTXK1BuG0VIsq+vJlpfJlNDe63F8cWc8y
evxYJKrSS1tuz6WrUiFcpfL0d5XZHKS22onCnMt/VTYZSWfLqtQLh1/btf+R
2PVa55X7txCmKM9lVdauOn38+MfHp0KVWp3Lma0rGEBslkHlj7a8wQv5U2nr
Qtxs/OuR9ELKjkZC1dXKludCygj/pDS5O5e/xfI3Uo3feI3xbFe1kUc/68Wi
1NvjzgpbgvHPdW4KXcpfdLUBe8df9FqZ7Fx6Q7365JfEua5En+Eklh/Npxxm
cR2ek5/dvMS7/jfmdlGWSd3jYRL9CqtNntbrIp5r8Q0qadhooMZvH8Y9yelr
/AUrX32pdAxfxEk+IH0VyyvjVqXq0L5S+Y1aq1x1PzGDS+MSK6+3rtLrngJr
3mLcq4RWEKsBn3exvIQgHS7vamXWdveWGbytq7rUG226xP3KOCFFFs0C4kFr
hIiiSKq5q0qVwDUfVsZJxHpNcSdTiFM7px0iMXcm1aWi0HGSPOMKnZiF0RxU
iU5B2MmFLeW6zipDWSYWlH+2yT8I4GO0SUKwqp1OedNefEJxWa00ca7050rY
hbz65/QXZj3GjzhoK5G1xrFUG5NlWA9+0mJrKXv8ibRNbOZkZm60mE6uTq7e
vzlZv38zjb0Z1iZNM0TP93KSV6VN65AobyGf0+Ut4sxvlu/PIMGoeSlzm+LL
kY6X8UiSkJdjdwyvbuVce3NEK7uGppUVTkMelRH03JJF5ThdthSmtM9ZKK5g
noUETMjpWC7gSIfsV4uFSWSictAVf9Qmucm2MtWZAUlQn29hHa/5dBxL9qUq
iox8BK6wp4VVo0VmlquqISfmGvbXbGsAh4fFMaiSHxyzJiuzxwGhyYoNSqTg
u5afbjbClI17VZrSSzAPlmidTbxasxBaQe9W7YGauYKXVQZFgWiVTk9KHflf
JIPKtxKRQQTVLURV80wztT///Mfs7eXL5y9+vLsDwjSxJ5qYC9FVNF7IPXb1
A3gEMn+bRG/iLtwrr97dndhlAIc1FxjVKO+Y/rw2GVUoOc9sckOi7gc6WIqW
Zfx/ykH1LTk4ui8JYRZY9/mzJ2d3d7uHp3ho0jO8ffH07JQcsJerCAnxjakq
B6n65/l5KIx3sJVuTSUW+EGGgk1ZyoUpyYck0j6TNioRpj4eFgMZ91zRJLQu
l7yjsmycnj25PYgh40kro/j+e4TkyeWYcr7rJBbyqpMHQky8vRc2g6gUN6lR
y1Ktd+t9YLem/8fO9AGNzgWj/71/jyL6e3T/oun4ifz6+u149uTr783fo86W
6fjxA3Sbx5Ovl+MnX8Xu06N7twQeJ7LDBQJMZl+Hgp16wU4PCvYXXLqCnX79
JhsdEuzQ33R85gU7O2yxh7m0zxDs7C8EO0TikRAwNYc5NJNoDAc1hzx6QsY7
Yq+esAmPaT1enpDw/OGUP5wdC8RnQQBwq7MtGg98RxY4RGOmuzTDtrPjWI4V
6kIP0Zfcfx4Fzj4JAzdUuJWiHADAq36tCIUPn1JkaWUImZQTr9/O0F7rhfmM
nHyjC50zplqfLHWeetgofTOMBK1Kg45a7WBQFiq50SgudqPK1EkyGEGQKkuo
KbVhfABBCn5bcqjN6wp1uZJzgIc8ImJQcmWWOVb2WZE9UKqFr0Rr34hkWrGh
GLbR8gFAitKsVbk9cRovU/wCnKzUrbHlMRsIFd/AFiyTEyzNKb3Z2PyHiqBn
V+tBGM6O5bVZo+qV2ZbU3VPy9D4lT72SZz0lR/zUE0LuCyEGQjwZ7cvut509
JPtZ7BurJjbxMqxgp5Y60XhIOy5sGoOGK5ZtWW6Ra081bKKCEaDxxYvnTwCN
nyzwncoiKkgDmmcvX+ILOgadwUpFQfhrfCsxHUdA66YKUTzyxkWJppm+X45p
aEFU0MOVfTubNeyenhG7haamRQsCbZKF7EMU2pAMaQQm1OU4TcmBdT0xe5JR
58hxSL1NKMr7+UY2sfVyRelkqICjz0TkFY5BgaykU5SHv8sPrIRUSaKLatdZ
soLUUj3IBc5MFDV/Ns+2gCtqUm1juNCFd10ZqANJ7LpQPgCwrdTLGpEb7OcS
navSWJgI2+sCA4lG2fN9MVy7WRlkX2Ogvtck4xMlGPNuooCs3soRNHS+ZKd2
kwcOAxuAGFuBdOtq1pcoDjacjn9w/dbFAR9URrZqw4eigHsEcoBrO+cCCwAI
qtLguUM436N5Mr4XIPJoNpA6lASh50B1dLEM7YKaW8rvz2pdZHokfKXsceNV
AWs7vJpmvElCeiZ+Dkb8owY/nYIa5gpOuG8i5AvKA4RCMWiI0eoBocFGv43w
Ao3UeL9nIkf40ZBMSpUIHkpKM6fiwZZJLYKIUI6moS3ZZMzzmw+q9itEEkE3
GmPkmuYiDEKYKzSFkitNwR17aARNnmR1aB7VsH0kLvpzkSmTi80KY5pZLODC
vGrF1D4tK3Wj811/1863QryzGxoWRz4kqjrPEfROL6mtVH5G9t37qOeWueKy
2RoD6ome4jScbHSWjejHzlZm2Hs6PwV4w5NwJ7z7gxfkuiMIWQu5vAzNsKvn
UWrXUJ1NhRKn6YxjK6lfcDLylkWt9xwznS8Bbci016a6RkHNl7H4uILVPfog
qFFFC8MzUJ2lZHtKdzYMCGlSEwu2ZA8ypOpY2+kq1OXAvZ0z8capNWY0VClI
utvS8iqpE0Kl5jRqvwumg+l/DajS5VBlFyZXP1fRUd/Sj4bs3gNeFGFUenb6
lEalkNOZqpDyoOX0aIdGrGWb2a0dKGh4vE0BzYUDrnJ40GuMyzrvvlwhFhBO
wQJzW9L4Cwt1NIh9Uh2KuM6cqTKYchBYYEgx3cylFFQizNBGV4toTiel+rbI
o3m9jlpiUV2kAEIH/dHMYnDy+cMVr5cVo84ZRadLlJOT62h6dT3xhwROHJFu
LNLkavzBv6XoaGZo7iupAZ10tg3T4b+T/LjBkwRN0BYxyIR9soiLCmE9Jx5H
0w8Xxz4Cd9M7l8lt4WsWHFCpPGlLT3ADbRH+W0VVw6MneITjDdX4knUp5dHF
9evZSF7QfwI6L3VOZ0/mC9B4ppeGSsxrv2nmN+HfmooNn379L0ageGvd4hVj
eUQoXLn+XFHp59OFw2oHHIKdOJYozERC5y++yYP7YIDFtmub7pFOh0OI475d
DJUWZHLoROHza71etgE+RYtRIQurpo9wJz2VxA4Im6AbtUt9AuzUf6/VQl5E
b0JYjgQf2qBFRxfVaQAItKhlZ9CFHDqW1Bo3BZ00IxxghKTTfGH8kMSI1tbe
tkXxyoujXUb78YKahnY1tUDd5bK7nPX3x33QuGmefGEJU1dz9ulbMY7nBE0t
pFpUofFjYFxhDNKl8G878ARVUT99W9lZ6LFsh1jwPzy66dH6NhX8eAEvYz5E
XG1lUZeFhVdGu6oCaNPrFtrI8330nutqo3UuaLQy5c7C3FoOuDsvOk8l3NWv
OHr3ZtzYH/J0DpbCKKO4e+hFZrO1D8EsJ/TzJZJDkdAw5UnLn8r6bd3evd8j
dGDc+1McYNEBQ66z6RDuDxWI0FuweIRK+QNKDMAiQKbH4mrYqYsGNQwr6Xr6
NOcHAQMm1C5HF9gmp6dX06ZXgSK/AB2id7YQ488Yyal5o3JT56badtOMiw43
3RFdtPUCheE0MHr905RJolcr7tl/cd3XHJvHu68hcnlFlSvfb12QLaAP3Bea
P9UdWdrDdskXE3tWpXlyhz0iFL9c+m6G+gmasQ45fNMMtdwYDYwretMVrRrA
W2OU/bz8VIMMn+WCs+iNlFdN+Pao+6GQxj3Xjt2mHAzP7jjgqU87fAfjgd6t
UAN0HPn2pXY8XO9HUix+bXquvtoeC32u8+1Drr1hWIz22KJzWDEYOA9jlc/l
HiwwxM+hRLjC3U16bfZKvm8N8wGSeA+g+jw5bcIxEAMq4mcS+qmZLjKT+Gg4
msyOUWR4vGnsw5Ht+20yCpMKJ99s/XDEzu8nM2g0WdyjOS9pLo6a5gZdwEjS
BVo4KKmGUS/uDXcCWz4YoKjeNQXEI7d1nvgJsuPjg1jH/uSzgNZ31pMMp3qj
3uTwECkSSCtnts1Vip9QvMLDcCQbnkxmou1YMGvNtO/V3coUPic/KvRlM4sh
9Zr+D4L5FhFz8H0X2cHKH0v9+Pj0+d0dxWwHO5KVpWrY1DZo2RxPzlVyUxf9
TjvkmZOX0e5ELmQYSSh205I//BiQSkNsuVhyYvnLN17UYdTJpF6i0eoO6hGB
g2dXhqy/glq52Cce85FN94a5ya/+3WccbMvIxNbv3lqPmnvDg1S60HwgNkh5
rg9NqDaocy+kixaZB9jb6M1xi28dy9l9tBSdNDwKCOBPMrmaqfuLSXMiT/DS
IQIdviO0+u7AHp6ErJdokFLkJTFUvskFCn557YeiJJwrvGmOX3JbrhXdSXQj
nFn8xR0eSOqkLqnAX/ZuUPduWptzoHb+YYCn7tM1FDA/JrpEUcIkZOhockPm
WSkn5ugT28va1OcejfUvT+kKetS7Mm2eXj57RnnZH7HojrnS5KFwnfrQHXQs
/gPpqK3/FCUAAA==

-->

</rfc>

