BESS Workgroup                                           J. Rabadan, Ed.
Internet-Draft                                                 O. Dornon
Intended status: Standards Track                                   Nokia
Expires: 14 July 2025                                    10 January 2025


         Ethernet VPN (EVPN) Multicast Leave Synch Route Update
                draft-rd-bess-evpn-mcast-leave-update-01

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 14 July 2025.







Rabadan & Dornon          Expires 14 July 2025                  [Page 1]

Internet-Draft      EVPN Multicast Leave Synch Update       January 2025


Copyright Notice

   Copyright (c) 2025 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 14 July 2025                  [Page 2]

Internet-Draft      EVPN Multicast Leave Synch Update       January 2025


   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 14 July 2025                  [Page 3]

Internet-Draft      EVPN Multicast Leave Synch Update       January 2025


      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 14 July 2025                  [Page 4]

Internet-Draft      EVPN Multicast Leave Synch Update       January 2025


   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 14 July 2025                  [Page 5]

Internet-Draft      EVPN Multicast Leave Synch Update       January 2025


   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 14 July 2025                  [Page 6]

Internet-Draft      EVPN Multicast Leave Synch Update       January 2025


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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [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,
              <https://www.rfc-editor.org/info/rfc9251>.

9.2.  Informative References

   [RFC2236]  Fenner, W., "Internet Group Management Protocol, Version
              2", RFC 2236, DOI 10.17487/RFC2236, November 1997,
              <https://www.rfc-editor.org/info/rfc2236>.

   [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,
              <https://www.rfc-editor.org/info/rfc3376>.

   [RFC3810]  Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
              Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
              DOI 10.17487/RFC3810, June 2004,
              <https://www.rfc-editor.org/info/rfc3810>.

   [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-12, 20 November 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-bess-
              evpn-fast-df-recovery-12>.

Authors' Addresses







Rabadan & Dornon          Expires 14 July 2025                  [Page 7]

Internet-Draft      EVPN Multicast Leave Synch Update       January 2025


   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 14 July 2025                  [Page 8]