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 network. defines 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 an All-Active multi-homing. This DF election mechanism allows selecting a DF at the granularity of (ES, VLAN) or (ES, VLAN bundle) for Broadcast, Unknown Unicast, or Multicast (BUM) traffic. Though and improves the default DF election procedure , still it does not fit well for some of service provider residential application, where whole multicast traffic is delivered on single VLAN.

Consider the above topology, which shows residential deployment scenario, where multiple receivers are behind all active multihoming segment. 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 the PE-2 proves a limitation in the current DF election mechanism. In 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 and ). In the above deployment we have to consider one more factor, Network bandwidth is shared between multicast and unicast flow. At any given point of time if AC1 already has unicast traffic flow which is taking good amount of network bandwidth. we would have very limited bandwidth available for multicast flows. Even though PE-3 to CE2 (AC2) has not been used much, still we would end up having limitation about how much multicast can flow though AC1. In this document, we propose an extension to HRW base drafts to allow DF election at the granularity of (ESI, VLAN, Mcast flow) which would allow multicast flows to be distributed among redundancy group PE's 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.

and defines extended community, which would be used for PE's in redundancy group to come to an agreement about which DF election procedures is supported. A PE can notify other participating PE's 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). current proposal extends the existing extended community defined in and . 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. Type 0: Default DF Election algorithm, or modulus-based algorithms in . Type 1: HRW algorithm defined in and Type 4: HRW base per multicast flow DF election (explained in this document) Type 5 - 254: Unassigned Type 255: Reserved for Experimental Use. The and 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, then these capabilities need to be interpreted in context of this new DF type-4. For example consider a scenario where all PEs in the same redundancy group (same ES) can support both AC-DF and DF type-4 and thus they 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 PE's for the ES, it check if all of other PE's have advertised their capability about Per multicast flow DF election procedure. If all of them have advertised capability, 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 indicates its capability to perform Per multicast flow DF election. OR There is at least one PE signals 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 and , so this draft does not repeat description of HRW algorithm itself. EVPN PE does the discovery of redundancy group based on . If redundancy group consists of N EVPN PE nodes. Then after the discovery all PEs build an unordered list of IP address of all the nodes in redundancy group. Procedure defined in this draft does not require PE's to be ordered list.Address [i] denotes the IP address of i'th EVPN PE in redundancy group where (0 < i <= N ).

The DF is the PE who has maximum affinity for (S, G, V, ESI) where S - Multicast Source G - Multicast Group V - Vlan ID for Ethernet Tag V. ESI - Ethernet Segment Identifier In case of tie choose the PE whose IP address is numerically least. The affinity of PE(i) to (S,G,VLAN ID, ESI) is calculated by function, affinity (S,G,V, ESI, Address(i)), where (0 < i <= N), PE(i) is the PE at ordinal i, address(i) is the IP address of PE at ordinal i affinity (S,G,V, ESI, Address(i)) = (1103515245. ((1103515245.Address(i) + 12345) XOR D(S,G,V,ESI))+12345) (mod 2^31) D(S,G,V, ESI) = CRC_32(S,G,V, ESI). Here D(S,G,V,ESI) is the 32-bit digest (CRC_32) of the Source IP, Group IP, Vlan ID for Ethernet Tag V. Source and Group IP address length does not matter as only the lower order 31 bits are modulo significant.

In case of IGMP membership request where source is not known. The DF is the PE which has maximum affinity for (G,V, ESI) where G - Multicast Group V - Vlan ID for Ethernet Tag V. ESI - Ethernet Segment Identifier In case of tie choose the PE whose IP address is numerically least. The affinity of PE(i) to (G,V, ESI) is calculated by function, affinity (G,V, ESI, Address(i)), where (0 < i <= N), PE(i) is the PE at ordinal i, address(i) is the IP address of PE at ordinal i affinity (G, V, ESI, Address(i)) = (1103515245. ((1103515245.Address(i) + 12345) XOR D(G,V,ESI))+12345) (mod 2^31) D(G,V, ESI) = CRC_32(G,V, ESI). Here D(G,V,ESI) is the 32-bit digest (CRC_32) of the Group IP, Vlan ID for Ethernet Tag V. Source and Group IP address length does not matter as only the lower order 31 bits are modulo significant.

Even if all of the PE's indicate their availability to participate in per multicast flow DF election procedure, there is need to have default DF election algorithm. Since Per multicast flow DF election is applicable for only those multicast flows for which PE has received membership request. For other BUM traffic, forwarding plane need default DF election procedure. And we use HRW based DF election procedure as default one in these cases which is defined in and .

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. PE's 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 procedure defined in . Each of the PE's 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 need to have default DF election among PE's in redundancy group for BUM traffic. In initial phase we use DF election procedure. When receiver starts sending membership request 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 PE's in redundancy group. Lets consider it is hashed to PE-2. defines procedure to sync IGMP join state among redundancy group of PE's. 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 PE's 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.

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 Detection of new PE through ES route. AC going up / down This document does not provide any new mechanism to handle DF re-election procedure. it does uses existing mechanism defined in . When ever either of trigger occur, DF re-election would be done. and all of the flows would be redistributed among existing PE's in redundancy group for ES.

More details to be added in next version.

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

There are no new IANA considerations in this document.