Ethernet VPN (EVPN) Multicast Leave Synch Route Update

The Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN) specification describes the procedures to synchronize IGMP/MLD membership report and leave group states in all the PEs that are attached to the same Ethernet Segment. In particular, the Multicast Leave Synch route described in the same specification, synchronizes the leave procedures on all the members of the Ethernet Segment, for a multicast group and for an amount of time (the Maximum Response Time). The Maximum Response Time is defined as the duration of the (x,G) leave group synchronization procedure. The use of the Maximum Response Time may be different depending on whether the local state was created by IGMPv2, IGMPv3 or MLDv2. In addition, the Maximum Response Time advertised in the Multicast Leave Synch route needs to account for the time that it takes for the route to be propagated in the network, which might not be easy to predict. This document clarifies the use of the Maximum Response Time and updates the procedures for the Multicast Leave Synch route.

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

This section summarizes the terminology that is used throughout the rest of the document. DF and non-DF: Designated Forwarder and non-Designated Forwarder SMET: Selective Multicast Ethernet Tag route LMQC and LMQI: Last Member Query Count and Last Member Query Interval

The IGMP/MLD Leave Group Synchronization procedures are described in section 6.2. A summary of the procedures follows: On the local multihomed PE, i.e., the PE receiving a local IGMP/MLD leave message: The Maximum Response Time is computed as the product of the configured Last Member Query Count (LMQC) and the Last Member Query Interval (LMQI) plus a configured delta (D) corresponding to the time it takes for a BGP advertisement to propagate between the PEs attached to the multihomed ES. The Maximum Response Time is then represented by the formula: Maximum Response Time = (LMQC * LMQI) + D The Maximum Response Time is started. A number of Group Specific Query (x,G) messages (given by LMQC) is locally sent at a fixed interval given by the LMQI. indicates that this step is done as per section 3 of . However, if the state was created by IGMPv3 or MLDv2, the leave procedures in and respectively, are followed. The IGMP/MLD Leave Group Synchronization route for that (ES,BD) and (x,G) is advertised containing the Maximum Response Time, and withdrawn when the Maximum Response Time expires. On the remote multihomed PE, i.e., the PE receiving an IGMP Leave Group Synch route: The route is installed and the received Maximum Response Time started for (x,G). On both, the local and remote multihomed PEs: If the local PE receives an IGMP/MLD report for (x,G) before the expiration of the Maximum Response Time, the PE advertises an IGMP/MLD Membership Report Synch route for (x,G), creates the local state for (x,G) if not created already, and advertises the SMET route for (x,G) if it is the Ethernet Segment DF and the SMET route is not advertised yet. If the remote PE receives an IGMP/MLD Membership Report Synch route for (x,G) before the Maximum Response Time expires, the PE creates the state for (x,G) and advertises the SMET route for (x,G) if it owns the DF role in the Ethernet Segment. After the expiration of the Maximum Response Time, both, the local and the remote multihomed PEs clean up the state for (x,G) and withdraw the routes related to the state (SMET, IGMP/MLD Membership Report Synch and Leave Synch routes) if they advertised them previously. The above procedure described in has the following issues: Based on the text in section 6.2, the advertised IGMP/MLD Leave Group Synchronization route conveys the Maximum Response Time in units of 1/10 seconds, up to a maximum of 255. The text does not clarify if the Maximum Response Time value advertised in the NLRI is computed as the local (LMQC * LMQI), or the local Maximum Response Time in the Group-Specific Query messages for IGMPv2/IGMPv3 or MLDv2. This aspect has to be clarified without ambiguity. In addition, the local values of the Maximum Response Time for IGMPv2, IGMPv3 or MLDv2 can easily exceed 255 based on the relevant specifications, as follows: For IGMPv2, as per , "when a Querier receives a Leave Group message for a group that has group members on the reception interface, it sends [Last Member Query Count] Group-Specific Queries every [Last Member Query Interval] to the group being left. These Group-Specific Queries have their Max Response time set to [Last Member Query Interval]. If no Reports are received after the response time of the last query expires, the routers assume that the group has no local members, as above". As a result, if (LMQC * LMQI) is encoded in the Leave Group Synchronization route, the product of the configured IGMPv2 LMQI and LMQC must be less that 255 units of 1/10 second. Note that the LMQI can be in the range 0-255, hence, e.g.,: if the LMQC is 2, the LMQI can only have a maximum of 127 units of 1/10 second. For IGMPv3, as per , the LMQI value can be even larger than in case of IGMPv2. This is due to the LMQI being encoded in the Max Resp Code field of the Query message that can represent values in a floating-point format that allows exponential values. However, an implementation of IGMPv3 that uses must limit the configured LMQI so that the result of the product (LMQC * LMQI) is less than 255 units of 1/10 second. A similar issue exists in , where the LMQI (referred to as the Last Listener Query Interval in MLDv2) can support a very large value in the Maximum Response Code field of the Query message. In this case, the implementation must also limit the configured value of the LMQI so that the result of the product (LMQC * LMQI) is less than 255 units of 1/10 second. Another issue is about the delta time D. The delta (D) time corresponding to the time it takes for a BGP advertisement to propagate between the PEs attached to the multihomed ES, is accounted in the computed Maximum Response Time in . This value may vary and it is assumed to be set to the same value by configuration on all the PEs attached to the Ethernet Segment, but configuring a value that is closed to the BGP propagation time and making sure this value is the same across all PEs of the ES might be a challenge when different implementations work together in the same Ethernet Segment. The above issues are described as per a literal interpretation of made by this document, however, implementations may have used of the advertised Maximum Response Time in different ways in order to overcome the above two issues. The goal of this document is to bring awareness of the potential interoperability issues that the IGMP/MLD Leave Group Synchronization route may have and update if necessary.

Some potential solutions to the issues described in follow: In order to guarantee interoperability with the use of the Maximum Response Time, a potential update to section 6.2 is to clarify that the advertised Maximum Response Time is the Last Member Query Interval (for IGMPv2 and IGMPv3) as in and , and the Last Listener Query Interval (for MLDv2) as in , but always with a maximum value of 255 units of 1/10 second. The advertised Maximum Response Time does NOT include the LMQC and D time, which are accounted in the computation of the local Maximum Response Time. The LMQC and D (BGP propagation delta time) values MUST be set (by configuration) to the same values in all the PEs attached to the Ethernet Segment. In addition, the configuration of the D value may be skipped if the PE advertising the Multicast Leave Synch route includes information in the route about when the Leave procedure started for the (x,G) and all the PEs in the Ethernet Segment are time-synchronized. This timing information is encoded in the Service Carving Timestamp BGP extended community (section 2.1 of ). Upon receiving the Leave Synch route, a PE can compare the time with the local one and compute an accurate local Maximum Response Time that accounts for the BGP propagation time. This avoids the need to configure a D time that has to be equal in all PEs of the Ethernet Segment.

Will be added.

None.