Internet-Draft PFM-SD extension for EVPN multi-homing October 2023
Mishra, et al. Expires 20 April 2024 [Page]
PIM Working Group
Intended Status:
Standards Track
M. Mishra
I. Wijnands
R. Tucker
H. Bidgoli
Z. Zhang
Juniper Networks

PFM-SD extension for EVPN multi-homing


Ethernet Virtual Private Network (EVPN) solution is becoming pervasive in data center (DC) applications for Network Virtualization Overlay (NVO) and DC interconnect (DCI) services and in service provider (SP) applications for next-generation virtual private LAN services.

EVPN defines sets of procedures to achieve multihoming between peers. When the multicast source is protected by EVPN multihoming for redundancy and multicast receivers are present behind PIM network, there are cases where traffic blackholes.

PIM Flooding Mechanism (PFM) and Source Discovery (SD) define new flood mechanisms in PIM domain to carry information about source and group. This draft defines the necessary extension to PFM-SD procedures to have seamless integration with EVPN supported multihoming.

Requirements Language

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 20 April 2024.

Table of Contents

1. Introduction

[RFC7432] describes procedures for BGP MPLS-based Ethernet VPNs (EVPN). It defines the function, procedure, and associated BGP routes used to support multihoming in EVPN. It defines the concept of Ethernet Segment (ES) which is a virtual construct to drive BGP procedures to be able to determine if two provider edge are multihomed.

                   +--------------+                 +-------------+
                   |              |                 |             |
                   |     PE1      |                 |    PE2      |
                   |              |                 |             |
                   +---------+----+                 +-----+-------+
                              \                          /
                               \                        /
                                \                      /
                                 \                    /
                                  \                  /
                                 |  \              /  |
                                      \          /
                                       \        /
                                     |             |
                                     |      CE     |

The above figure shows a sample multihoming case. where two independent PE (Provider Edge) are connected to CE (customer edge) devices via MC-LAG. Any packets that are originating from CE or host attached to CE can be hashed to either of the PE. and PE would have no knowledge about who can get any packets.

[RFC8364] defines a generic flooding mechanism for distributing information throughout a PIM domain.

Many deployments do use EVPN multihoming to achieve redundancy of reachability in the network. When EVPN multihoming is deployed with PIM [RFC7761] network, there is challenge with respect to RPF selection by PIM domain. This draft defines a necessary extension to [RFC8364] to achieve optimal multicast forwarding in PIM domain.

2. Requirements Language

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Terminology


4. Problem Statement

                         Multicast Receiver
                                   | PIM (1 .1.1.1,
                           |       P2      |
                           |               |
    PIM join (, |
                                   |    Unicast Rechability
                           +--------------+  Prefix
                           |       P1     |  NH : PE1, PE2 (ECMP)
                           |              |
                                  /  \
                                 /    \
                                /      \ PIM (,
                               /        \
                              /          \
                             /            \
                            -              -
                  +-------------+        +-------------+
                  |     PE1     |        |    PE2      |
                  |             |        |             |
IRB   +-------------+        +-------------+IRB
                          \                     /
                           \                   /
                            \                 /
                             \               /
                              \             /
                               \           /
                                -         -
                          |          CE        |
                          |                    |

Above figure shows sample topology where

In the above topology, the source prefix is announced in IGP from both of the PE. When P1 does process PIM joins towards source, it needs to do a source prefix lookup to pick RPF towards the source. Since there is ECMP path, it gets two next hop as PE1 and PE2. Based on local decision P1 can send PIM join to either of the next hop. Consider in this case it picks PE2 as RPF to send PIM join. At this point of time end to end PIM tree has been created where the tree is built rooted at PE2. At present there is no data traffic being sourced.

As the next step Source starts sending multicast traffic. Once traffic reaches CE, it is going to hash the flow to either of the ports. and consider it picks PE1 as the next hop to send traffic to.

Previous two steps (PIM join and multicast data flow) can happen in any order

At the end we are in a situation where multicast traffic is being received by PE1 and PIM join landed on PE2 causing traffic blackholing.

At present deployment uses EVPN BUM tunnel to bridge multicast traffic between peers. Which results in traffic from PE1 being bridged to PE2 via P1. and it leads same traffic going over the link twice (once as bridge copy and once as routed copy).

5. Solution Requirement

6. Solution overview

[[RFC8364] defines a generic flooding mechanism for distributing information throughout the PIM domain. Multicast source discovery was one of the types of information being flooded in the PIM domain. [RFC8364] was mainly designed to flood source information for PIM-SM sources. However, this draft provides an extension to flood PIM-SM and PIM-SSM source information if the source is being hosted in a multihomed port.

6.1. Flooding multihome source

Multihome source flood will use a generic flood mechanism defined by [RFC8364]. Forwarding rules are identical to [RFC8364]

Details of TLV extension and packet format are to be added in the next revision.

6.2. Optimization multihome source flooding


7. Security Considerations

8. IANA Considerations

9. References

9.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, , <>.
Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Wijnands, IJ., Venaas, S., Brig, M., and A. Jonasson, "PIM Flooding Mechanism (PFM) and Source Discovery (SD)", RFC 8364, DOI 10.17487/RFC8364, , <>.

9.2. Informative References

Appendix A. Acknowledgments

Authors' Addresses

Mankamana Mishra
IJsbrand Wijnands
Ryan R Tucker
Hooman Bidgoli
Zhaohui Zhang
Juniper Networks