BESS Workgroup J. Rabadan, Ed. Internet-Draft Nokia Intended status: Standards Track A. Sajassi Expires: 23 April 2026 Cisco 20 October 2025 Ingress Replication BUM flag in VXLAN draft-rabsaj-bess-evpn-vxlan-ir-bum-00 Abstract This document proposes the allocation of an “Ingress Replication BUM” flag in the VXLAN Flags IANA registry and defines its use in EVPN networks that employ VXLAN tunnels with ingress replication to forward broadcast, unknown and multicast traffic. 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 23 April 2026. 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. Rabadan & Sajassi Expires 23 April 2026 [Page 1] Internet-Draft EVPN Redundant Sources October 2025 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology and Conventions . . . . . . . . . . . . . . . 3 2. The Ingress Replication BUM Flag in VXLAN tunnels . . . . . . 3 3. Use of the Ingress Replication BUM Flag in EVPN Multi-Homing . . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Section 8.3.3 of [RFC8365] explains why tunnels used for EVPN ingress replication must include an indication that a given BUM (Broadcast, Unknown Unicast, Multicast) frame was ingress-replicated by the ingress PE. A summary of that section is provided here for the reader’s convenience: In EVPN networks using ingress replication, unknown unicast traffic is flooded with a distinct MPLS label to mark it as BUM traffic. This allows egress PEs to apply Designated Forwarder (DF) filtering for All-Active multihomed sites. If unknown unicast flooding is enabled but no specific unknown-unicast label is used, transient duplicate traffic may occur. This happens when the ingress PE has not yet learned a host MAC via EVPN, while the egress PEs already have. The ingress PE floods the packet to all egress PEs, which then forward multiple copies to the multihomed site. Such duplication occurs only when: a. the destination host is multihomed (All-Active) b. unknown-unicast flooding is enabled c. ingress replication is used d. the ingress PE hasn’t learned the MAC yet To prevent this, [RFC8365] recommends the use of VXLAN-GPE encapsulation [I-D.ietf-nvo3-vxlan-gpe], with the ingress PE setting the BUM Traffic Bit (B-bit) to mark the traffic as ingress-replicated BUM. Rabadan & Sajassi Expires 23 April 2026 [Page 2] Internet-Draft EVPN Redundant Sources October 2025 The goal of this document is twofold. First, it requests the allocation of the B-bit (also referred to as the “Ingress Replication BUM” flag) in the VXLAN Flags registry established by [I-D.ietf-nvo3-rfc7348bis], and updates [RFC8365] to allow the use of this flag in VXLAN tunnels. Second, it analyzes additional use cases where the “Ingress Replication BUM” flag should be applied, beyond the scenario described in Section 8.3.3 of [RFC8365]. 1.1. Terminology and Conventions 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. * BUM traffic: Broadcast, Unknown unicast and Multicast traffic. * PE: Provider Edge device. In this document a PE can be a Leaf node in a Data Center or a traditional Provider Edge router in an MPLS network. 2. The Ingress Replication BUM Flag in VXLAN tunnels This document requests the allocation of the the Ingress Replication BUM flag (B-bit) in VXLAN tunnels [I-D.ietf-nvo3-rfc7348bis] as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|R|R|R|I|R|B|R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VXLAN Network Identifier (VNI) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This document requests IANA to allocate bit 6 of the VXLAN Flags registry for the “Ingress Replication BUM” flag. The chosen bit position aligns with that used in [I-D.ietf-nvo3-vxlan-gpe], facilitating data path implementations that support both VXLAN-GPE and the procedures defined in this document for VXLAN tunnels. In an EVPN broadcast domain that uses Ingress Replication to forward BUM traffic: 1. Ingress PEs MUST set the Ingress Replication BUM flag in VXLAN packets that encapsulate broadcast, multicast, or unknown unicast frames. Rabadan & Sajassi Expires 23 April 2026 [Page 3] Internet-Draft EVPN Redundant Sources October 2025 2. Egress PEs MUST treat any received packet with the Ingress Replication BUM flag set as BUM traffic, regardless of the destination MAC address in the encapsulated frame. 3. Egress PEs MUST treat any received packet with the Ingress Replication BUM flag unset as known unicast traffic, regardless of the destination MAC address in the encapsulated frame. In an EVPN broadcast domain that uses Assisted Replication [RFC9574], the ingress PE MUST set the Ingress Replication BUM flag in VXLAN packets that encapsulate broadcast, multicast or unknown unicast frames. In this context, the ingress PE may be an Assisted Replication Replicator, Leaf or RNVE (Regular Network Virtualization Edge) node. The following section illustrates how the use of the Ingress Replication BUM flag addresses issues in EVPN multi-homing networks. 3. Use of the Ingress Replication BUM Flag in EVPN Multi-Homing Consider the scenario in Figure 1, where PE1 and PE2 are multi-homed to CE1 in all-active mode, and ingress replication is used. Without the enhancement described in this document, when CE2 sends traffic to MAC M1, it is possible that PE3 has not yet learned M1, even though it already exists in the FIBs of PE1 and PE2. In this case, PE3 will ingress-replicate the frame in VXLAN packets to both PE1 and PE2, and since both egress PEs forward the traffic to CE1, packet duplication occurs. This is considered a transient scenario, but packet duplication may still be harmful for the applications. Using the procedures in this document: * In the same example PE3 sets the Ingress Replication BUM flag. * PE1 and PE2 receive the VXLAN packet with the flag set and treat it as BUM traffic. As a result, only the Designated Forwarder (DF) forwards the frame to CE1, thereby preventing packet duplication. Rabadan & Sajassi Expires 23 April 2026 [Page 4] Internet-Draft EVPN Redundant Sources October 2025 PE1 +-------+ M1| +---+ |--------------+ +--------| |BD1| | | | | +---+ | <----+ | PE3 | +-------+ | +-------+ +---+ | +----+ +---+ | +---+ |CE1| | | |BD1| +---|CE2| +---+ | +----+ +---+ | +---+ M1 | | | +-------+ | +-------+ <----+ | ? <------ | M1| +---+ | | to-M1 +--------| |BD1| |--------------+ | +---+ | +-------+ PE2 Figure 1: Packet Duplication Figure 2 illustrates a similar example under different conditions. Without the enhancement described in this document, consider a scenario where CE2 sends a unicast frame destined for MAC M1. It is possible that PE3’s FIB still contains an entry for M1 pointing to PE1, while PE1 has already removed M1 from its own FIB (due to MAC aging or other conditions). In this case, if PE1 is not the Designated Forwarder (DF) for the Ethernet Segment, it will discard the frame, disrupting communication between CE2 and CE1. This represents another transient condition that can negatively affect applications. Using the procedures in this document: * PE3 does not set the Ingress Replication BUM flag for the VXLAN packet that encapsulates the frames to M1. * PE1 receives the VXLAN packet with the flag unset and therefore treats it as unicast traffic. This allows PE1 to safely forward the frame to CE1, and to any other local attachment circuits, if present. The communication between CE2 and CE1 is no longer disrupted. Rabadan & Sajassi Expires 23 April 2026 [Page 5] Internet-Draft EVPN Redundant Sources October 2025 PE1 +-------+ ? | +---+ |--------------+ +--------| |BD1| | | | | +---+ | <----+ | PE3 | +-------+ | +-------+ +---+ | +----+ +---+ | +---+ |CE1| | | |BD1| +---|CE2| +---+ | | +---+ | +---+ M1 | | +-------+ | +-------+ | PE1 <------ | | +---+ | | to-M1 +--------| |BD1| |--------------+ | +---+ | +-------+ PE2 Figure 2: Packet Discard 4. Security Considerations The use of the Ingress Replication BUM flag in VXLAN packets is not expected to introduce any new security risks in existing EVPN VXLAN networks. On the contrary, this flag provides a clear indication to receiving PEs whether the traffic was originally classified as BUM or unicast. Since the setting of this bit for BUM-encapsulated packets is automatic and not controlled by configuration commands, an attacker with access to an EVPN VXLAN PE cannot exploit or modify it as a means of attack. 5. IANA Considerations This document requests a new Flag in the registry called "VxLAN Flags", to indicate "Ingress Replication BUM". Bit Name Reference -------------------------------------------------------- 6 Ingress Replication BUM This document Figure 3 6. Contributors 7. Acknowledgements The authors would like to acknowledge the authors of [RFC8365] and [I-D.ietf-nvo3-vxlan-gpe] for their initial discussions about the use of an Ingress Replication BUM flag in VXLAN-GPE. Rabadan & Sajassi Expires 23 April 2026 [Page 6] Internet-Draft EVPN Redundant Sources October 2025 8. References 8.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, . [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., Uttaro, J., and W. Henderickx, "A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI 10.17487/RFC8365, March 2018, . [RFC9574] Rabadan, J., Ed., Sathappan, S., Lin, W., Katiyar, M., and A. Sajassi, "Optimized Ingress Replication Solution for Ethernet VPNs (EVPNs)", RFC 9574, DOI 10.17487/RFC9574, May 2024, . [I-D.ietf-nvo3-rfc7348bis] Mahalingam, M., Dutt, D., Kreeger, L., Sridhar, T., and A. Sajassi, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", Work in Progress, Internet-Draft, draft-ietf-nvo3-rfc7348bis-01, 23 July 2025, . 8.2. Informative References [I-D.ietf-nvo3-vxlan-gpe] Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol Extension for VXLAN (VXLAN-GPE)", Work in Progress, Internet-Draft, draft-ietf-nvo3-vxlan-gpe-13, 4 November 2023, . Authors' Addresses Rabadan & Sajassi Expires 23 April 2026 [Page 7] Internet-Draft EVPN Redundant Sources October 2025 Jorge Rabadan (editor) Nokia 520 Almanor Avenue Sunnyvale, CA 94085 United States of America Email: jorge.rabadan@nokia.com Ali Sajassi Cisco Email: sajassi@cisco.com Rabadan & Sajassi Expires 23 April 2026 [Page 8]