Per multicast flow Designated Forwarder Election for EVPN

EVPN based All-Active multi-homing is becoming the basic building block for providing redundancy in next generation data center deployments as well as service provider access/aggregation networks. defines the role of a designated forwarder as the node in the redundancy group that is responsible to forward Broadcast, Unknown unicast, Multicast (BUM) traffic on that Ethernet Segment (CE device or network) in All-Active multi-homing. The default DF election mechanism allows selecting a DF at the granularity of (ES, VLAN) or (ES, VLAN bundle) for BUM traffic. While improve on the default DF election procedure, some service provider residential applications require a finer granularity, where whole multicast flows are delivered on a single VLAN.

Consider the above topology, which shows a typical residential deployment scenario, where multiple receivers are behind an all-active multihoming segments. All of the multicast traffic is provisioned on EVI-1. Assume PE-2 get elected as DF. According to , PE-2 will be responsible for forwarding multicast traffic to that Ethernet segment. Forcing sole data plane forwarding responsibility on PE-2 is a limitation in the current DF election mechanism. The topology at Figure 1 would always have only one of the PE to be elected as DF irrespective of which current DF election mechanism is in use defined in or . The problem may also manifest itself in a different way. For example, AC1 happens to use 80% of its available bandwidth to forward unicast data. And now there is need to serve multicast receivers where it would require more than 20% of AC1 bandwidth. In this case, AC1 becomes oversubscribed and multicast traffic drop would be observed even though there is already another link (AC2) present in network which can be used more efficiently load balance the multicast traffic. In this document, we propose an extension to the HRW base draft to allow DF election at the granularity of (ESI, VLAN, Mcast flow) which would allow multicast flows to be better distributed among redundancy group PEs to share the load.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . With respect to EVPN, this document follows the terminology that has been defined in and for multicast terminology.

defines an extended community, which would be used for PEs in redundancy group to reach a consensus as to which DF election procedure is desired. A PE can notify other participating PEs in redundancy group about its willingness to support Per multicast flow base DF election capability by signaling a DF election extended community along with Ethernet-Segment Route (Type-4). The current proposal extends the existing extended community defined in . This draft defines new a DF type. DF type (1 octet) - Encodes the DF Election algorithm values (between 0 and 255) that the advertising PE desires to use for the ES. This document requests two new types in the DF type field: Type 4: HRW base per (S,G) multicast flow DF election (explained in this document) Type 5: HRW base per (*,G) multicast flow DF election (explained in this document) The describes encoding of capabilities associated to the DF election algorithm using Bitmap field. When these capabilities bits are set along with the DF type-4 and type-5, they need to be interpreted in context of this new DF type-4 and type-5. For example, consider a scenario where all PEs in the same redundancy group (same ES) can support both AC-DF, DF type-4 and DF type-5 and receive such indications from the other PEs in the ES. In this scenario, if a VLAN is not active in a PE, then the DF election procedure on all PEs in the ES should factor that in and exclude that PE in the DF election per multicast flow. A PE SHOULD attach the DF election Extended Community to ES route and Extended Community MUST be sent if the ES is locally configured for DF type Per Multicast flow DF election. Only one DF Election Extended community can be sent along with an ES route. When a PE receives the ES Routes from all the other PEs for the ES, it checks if all of other PEs have advertised their desire to proceed by Per multicast flow DF election. If all peering PEs have done so, it performs DF election based on Per multicast flow procedure. But if: There is at least one PE which advertised route-4 ( AD per ES Route) which does not indicate its capability to perform Per multicast flow DF election. OR There is at least one PE signaling single active in the AD per ES route it MUST be considered as an indication to support of only Default DF election and DF election procedure in MUST be used.

This document is an extension of , so this draft does not repeat the description of HRW algorithm itself. EVPN PE does the discovery of redundancy groups based on . If redundancy group consists of N peering EVPN PE nodes, after the discovery all PEs build an unordered list of IP address of all the nodes in the redundancy group. The procedure defined in this draft does not require the list of PEs to be ordered. Address [i] denotes the IP address of the [i]th EVPN PE in redundancy group where (0 < i <= N ).

The DF is the PE who has maximum weight for (S, G, V, Es) where S - Multicast Source G - Multicast Group V - VLAN ID. Es - Ethernet Segment Identifier Address[i] is address of the ith PE. The PEs IP address length does not matter as only the lower-order 31 bits are modulo significant. Weight The weight of PE(i) to (S,G,VLAN ID, Es) is calculated by function, weight (S,G,V, Es, Address(i)), where (0 < i <= N), PE(i) is the PE at ordinal i. Weight (S,G,V, Es, Address(i)) = (1103515245. ((1103515245.Address(i) + 12345) XOR D(S,G,V,ESI))+12345) (mod 2^31) In case of tie, the PE whose IP address is numerically least is chosen. Digest D(S,G,V, Es) = CRC_32(S,G,V, Es) Here D(S,G,V,Es) is the 31-bit digest (CRC_32 and discarding the MSB) of the Source IP, Group IP, Vlan ID and Es. The CRC MUST proceed as if the architecture is in network byte order (big-endian).

The DF is the PE who has maximum weight for (G, V, Es) where G - Multicast Group V - VLAN ID. Es - Ethernet Segment Identifier Address[i] is address of the ith PE. The PEs IP address length does not matter as only the lower-order 31 bits are modulo significant. Weight The weight of PE(i) to (G,VLAN ID, Es) is calculated by function, weight (G,V, Es, Address(i)), where (0 < i <= N), PE(i) is the PE at ordinal i. Weight (G,V, Es, Address(i)) = (1103515245. ((1103515245.Address(i) + 12345) XOR D(G,V,ESI))+12345) (mod 2^31) In case of tie, the PE whose IP address is numerically least is chosen. Digest D(G,V, Es) = CRC_32(G,V, Es) Here D(G,V,Es) is the 31-bit digest (CRC_32 and discarding the MSB) of the Group IP, Vlan ID and Es. The CRC MUST proceed as if the architecture is in network byte order (big-endian).

Per multicast DF election procedure would be applicable only when host behind Attachment Circuit (of the Es) start sending IGMP membership requests. Membership requests are synced using procedure defined in , and each of the PE in redundancy group can use per flow DF election and create DF state per multicast flow. The HRW DF election "Type 1" procedure defined in MUST be used for the Es DF election and SHOULD be performed on Es even before learning multicast membership request state. This default election procedure MUST be used at port level but will be overwritten by Per flow DF election as and when new membership request state are learnt.

Figure-2 shows multihomed network. Where EVPN PE-1, PE-2, PE-3 are multihomed to CE-1. Multiple multicast receivers are behind all active multihoming segment. PEs connected to the same Ethernet segment can automatically discover each other through exchange of the Ethernet Segment Route. This draft does not change any of this procedure, it still uses the procedure defined in . Each of the PEs in redundancy group advertise Ethernet segment route with extended community indicating their ability to participate in per multicast flow DF election procedure. Since Per multicast flow would not be applicable unless PE learns about membership request from receiver, there is a need to have the default DF election among PEs in redundancy group for BUM traffic. Until multicast membership state are learnt, we use the the DF election procedure in , namely HRW per (v,Es) as defined in . When a receiver starts sending membership requests for (s1,g1), where s1 is multicast source address and g1 is multicast group address, CE-1 could hash membership request (IGMP join) to any of the PEs in redundancy group. Let's consider it is hashed to PE-2. defines a procedure to sync IGMP join state among redundancy group of PEs. Now each of the PE would have information about membership request (s1,g1) and each of them run DF election procedure to elect DF among participating PEs in redundancy group. Consider PE-2 gets elected as DF for multicast flow (s1,g1). PE-1 forwarding state would be nDF for flow (s1,g1) and DF for rest other BUM traffic. PE-2 forwarding state would be DF for flow (s1,g1) and nDF for rest other BUM traffic. PE-3 forwarding state would be nDF for flow (s1,g1) and rest other BUM traffic. As and when new multicast membership request comes, same procedure as above would continue. If has DF type 4, For membership request (S,G) it MUST use to elect DF among participating PEs. And membership request (*,G) MUST use to elect DF among participating PEs.

There are multiple triggers which can cause DF re-election. Some of the triggers could be Local ES going down due to physical failure or configuration change triggers DF re-election at peering PE. Detection of new PE through ES route. AC going up / down ESI change Remote PE removed / Down Local configuration change of DF election Type and peering PE consensus on new DF Type This document does not provide any new mechanism to handle DF re-election procedure. It uses the existing mechanism defined in . Whenever either of the triggers occur, a DF re-election would be done. and all of the flows would be redistributed among existing PEs in redundancy group for ES.

The same Security Considerations described in are valid for this document.

Allocation of DF type in DF extended community for EVPN.

Authors would like to acknowledge helpful comments and contributions of Luc Andre Burdet.