Internet-Draft BIER-egress-protection February 2024
Zhang, et al. Expires 9 August 2024 [Page]
BIER Working Group
Intended Status:
Standards Track
Z. Zhang
Juniper Networks
I. Wijnands
Z. Zhang
M. Mishra
Cisco Systems
H. Chen

BIER Flow Overlay with Anycast Egress Protection


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.

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 9 August 2024.

Table of Contents

1. Introduction

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.

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 [RFC8679]. When BIER is used in the provider network for multicast, [I-D.zzhang-bier-anycast] specifies BIER with anycast as the building block of egress protection for multicast.

This document discusses considerations and specifies procedures for multicast flow overlay when BIER anycast is used for egress protection, in the context of MVPN [RFC6513] [RFC6514] and EVPN [RFC7432]. Future revisions may cover other flow overlay protocols like PIM/MLD/mLDP.

1.1. PE/CE Procedures for MVPN Multi-homing

In the following diagram for MVPN [RFC6513] [RFC6514] service:

                     PE1 |BFER1|_________+---+
  PE0                    +-----+        /|CE1|
 +----+                  +-----+_______/ +---+
 |BFIR|              PE2 |BFER2|_________+---+
 +----+                  +-----+        /|CE2|
                         +-----+_______/ +---+
                     PE3 |BFER3|_________+---+
                         +-----+         |CE3|

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.

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'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't be delivered to CE1, and if it arrives on PE3 it won't be delivered to CE3.

For PE1/PE2 to deliver the received multicast traffic to CE1, they both need to receive PIM [RFC7761] join or mLDP [RFC6388] label mapping if the PE-CE protocol is mLDP from the CE. With the MoFRR [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:

  • 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.

  • The PE'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.

1.2. EVPN Multi-homing

The MVPN approach described above does not apply to EVPN, which does not use anycast.

A more detailed desription may be included in a future revision to explain why different approaches are taken for MVPN and EVPN.

However, when tunnel segmentation is used, the anycast based approach does apply to EVPN as well, as described in the following section.

1.3. MVPN/EVPN Tunnel Segmentation

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 [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.

The tunnel segmentation procedures also apply to EVPN and are specified in [I-D.ietf-bess-evpn-bum-procedure-updates].

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 [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 [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.

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).

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.

While EVPN PEs don't use anycast multi-homing, the anycast procedures on the segmentation points described here do apply to EVPN tunnel segmentation as well.

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).

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.

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.

1.4. Relationship with Warm Root Standby

With Warm Root Standby procedures in [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.

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 "this" segmentation point), who will accept traffic from all the anycast upstream.

2. Specification

Detailed normative procedures will be added in future revisions.

3. Security Considerations

This document does not introduce any new security concerns besides what has been discussed in [RFC8279], [RFC6513], [RFC8556], [I-D.ietf-bier-tether] and [I-D.zzhang-bier-anycast].

4. References

4.1. Normative References

Zhang, Z. J., Lin, W., Rabadan, J., Patel, K., and A. Sajassi, "Updates on EVPN BUM Procedures", Work in Progress, Internet-Draft, draft-ietf-bess-evpn-bum-procedure-updates-14, , <>.
Zhang, Z. J., Warnke, N., Wijnands, I., and D. O. Awduche, "Tethering A BIER Router To A BIER incapable Router", Work in Progress, Internet-Draft, draft-ietf-bier-tether-04, , <>.
Zhang, Z. J., Wijnands, I., Zhang, Z., Mishra, M. P., and H. Chen, "BIER with Anycast", Work in Progress, Internet-Draft, draft-zzhang-bier-anycast-02, , <>.
Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, , <>.
Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, , <>.
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, , <>.
Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs)", RFC 7524, DOI 10.17487/RFC7524, , <>.
Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, , <>.
Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S., and A. Dolganow, "Multicast VPN Using Bit Index Explicit Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, , <>.

4.2. Informative References

Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, DOI 10.17487/RFC6388, , <>.
Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B. Decraene, "Multicast-Only Fast Reroute", RFC 7431, DOI 10.17487/RFC7431, , <>.
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, , <>.
Shen, Y., Jeganathan, M., Decraene, B., Gredler, H., Michel, C., and H. Chen, "MPLS Egress Protection Framework", RFC 8679, DOI 10.17487/RFC8679, , <>.
Morin, T., Ed., Kebler, R., Ed., and G. Mirsky, Ed., "Multicast VPN Fast Upstream Failover", RFC 9026, DOI 10.17487/RFC9026, , <>.

Authors' Addresses

Zhaohui (Jeffrey) Zhang
Juniper Networks
IJsbrand Wijnands
Zheng Zhang
Mankamana Mishra
Cisco Systems
Huaimo Chen