BIER Flow Overlay with Anycast Egress Protection

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