BESS Workgroup J. Rabadan, Ed. Internet-Draft O. Dornon Intended status: Standards Track Nokia Expires: 9 January 2025 8 July 2024 Ethernet VPN (EVPN) Multicast Leave Synch Route Update draft-rd-bess-evpn-mcast-leave-update-00 Abstract 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 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. 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 https://datatracker.ietf.org/drafts/current/. 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 January 2025. Rabadan & Dornon Expires 9 January 2025 [Page 1] Internet-Draft EVPN Multicast Leave Synch Update July 2024 Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. IGMP/MLD Leave Group Synchronization Issues . . . . . . . . . 3 5. IGMP/MLD Leave Group Synchronization Solutions . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction The Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN) specification [RFC9251] 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. Rabadan & Dornon Expires 9 January 2025 [Page 2] Internet-Draft EVPN Multicast Leave Synch Update July 2024 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. 2. Conventions used in this document 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Terminology 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 4. IGMP/MLD Leave Group Synchronization Issues The IGMP/MLD Leave Group Synchronization procedures are described in [RFC9251] 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: 1. 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 2. The Maximum Response Time is started. Rabadan & Dornon Expires 9 January 2025 [Page 3] Internet-Draft EVPN Multicast Leave Synch Update July 2024 3. A number of Group Specific Query (x,G) messages (given by LMQC) is locally sent at a fixed interval given by the LMQI. [RFC9251] indicates that this step is done as per section 3 of [RFC2236]. However, if the state was created by IGMPv3 or MLDv2, the leave procedures in [RFC3376] and [RFC3810] respectively, are followed. 4. 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: 1. The route is installed and the received Maximum Response Time started for (x,G). * On both, the local and remote multihomed PEs: 1. 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. 2. 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. 3. 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 [RFC9251] has the following issues: 1. 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. Rabadan & Dornon Expires 9 January 2025 [Page 4] Internet-Draft EVPN Multicast Leave Synch Update July 2024 2. 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 [RFC2236], "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 [RFC3376], 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 [RFC9251] 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 [RFC3810], 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. 3. 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 [RFC9251]. 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. Rabadan & Dornon Expires 9 January 2025 [Page 5] Internet-Draft EVPN Multicast Leave Synch Update July 2024 The above issues are described as per a literal interpretation of [RFC9251] 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 [RFC9251] if necessary. 5. IGMP/MLD Leave Group Synchronization Solutions Some potential solutions to the issues described in Section 4 follow: 1. In order to guarantee interoperability with the use of the Maximum Response Time, a potential update to [RFC9251] section 6.2 is to clarify that the advertised Maximum Response Time is the Last Member Query Interval (for IGMPv2 and IGMPv3) as in [RFC2236] and [RFC3376], and the Last Listener Query Interval (for MLDv2) as in [RFC3810], 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. 2. 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 [I-D.ietf-bess-evpn-fast-df-recovery]). 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. 6. Security Considerations Will be added. 7. IANA Considerations None. 8. Acknowledgments Rabadan & Dornon Expires 9 January 2025 [Page 6] Internet-Draft EVPN Multicast Leave Synch Update July 2024 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9251] Sajassi, A., Thoria, S., Mishra, M., Patel, K., Drake, J., and W. Lin, "Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN)", RFC 9251, DOI 10.17487/RFC9251, June 2022, . 9.2. Informative References [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, DOI 10.17487/RFC2236, November 1997, . [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, . [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, . [I-D.ietf-bess-evpn-fast-df-recovery] Brissette, P., Sajassi, A., Burdet, L. A., Drake, J., and J. Rabadan, "Fast Recovery for EVPN Designated Forwarder Election", Work in Progress, Internet-Draft, draft-ietf- bess-evpn-fast-df-recovery-08, 10 July 2023, . Authors' Addresses Rabadan & Dornon Expires 9 January 2025 [Page 7] Internet-Draft EVPN Multicast Leave Synch Update July 2024 J. Rabadan (editor) Nokia 520 Almanor Avenue Sunnyvale, CA 94085 United States of America Email: jorge.rabadan@nokia.com O. Dornon Nokia Antwerp Belgium Email: olivier.dornon@nokia.com Rabadan & Dornon Expires 9 January 2025 [Page 8]