BESS Working Group A. Sajassi, Ed Internet-Draft N. Malhotra Intended status: Standards Track R. Kachalia Expires: 6 May 2027 Cisco C. Zeledon Meta 2 November 2026 EVPN Subnet Slicing draft-sajassi-bess-evpn-subnet-slicing-00 Abstract Ethernet VPN (EVPN) Integrated Routing and Bridging (IRB) distributes Layer 2 and Layer 3 reachability through BGP. In a large stretched broadcast domain, traditional IRB can cause every Provider Edge (PE) to install MAC and IP addresses for every endpoint in the subnet thus resulting in exhaustion of forwarding resources (MAC-VRF and IP-VRF) on the PEs - i.e., route population is approximately proportional to the number of endpoints in every stretched subnet imported by the PE [Optimized-IRB] proposes a solution to alleviate the MAC-VRF resource consumption by terminating ARP/ND messages on the PE and providing L3 forwarding (routing) for both intra and inter subnets. Therefore, eliminating the need for MAC lookups and the maintenance of MAC addresses in MAC-VRF for IP hosts. However, this solution does not solve the IP-VRF resource consumption issue as IP host addresses still need to be maintained in IP-VRF for both the locally connected hosts and the remote hosts. This problem is particularly pronounced in campus networks where most subnets are stretched across the entire campus (and thus all access switches) and the access switches used as EVPN-IRB PE devices have significantly smaller forwarding tables and hence limit the total endpoint scale that can be attached to stretched subnets across the network. This document defines an EVPN Subnet Slicing solution to horizontally scale stretched subnets across the network without being constrained by any PE's forwarding table size. The solution enables access layer PE devices to maintain only locally attached host routes and allows host routes to be distributed across distribution or aggregation layer PE devices as opposed to each PE maintaining all host IP routes. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Sajassi, Ed, et al. Expires 6 May 2027 [Page 1] Internet-Draft EVPN Subnet Slicing November 2026 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 6 May 2027. Copyright Notice Copyright (c) 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Scope of This Document . . . . . . . . . . . . . . . . . 5 1.2. Applicability Statement . . . . . . . . . . . . . . . . . 6 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 6 1.4. Conventions and Terminology . . . . . . . . . . . . . . . 6 2. Problem Statement and Design Goals . . . . . . . . . . . . . 8 2.1. Scale Characteristics of Traditional IRB . . . . . . . . 8 2.2. Problems Addressed by This Document . . . . . . . . . . . 8 2.3. Design Goals . . . . . . . . . . . . . . . . . . . . . . 9 2.4. Scale Model . . . . . . . . . . . . . . . . . . . . . . . 9 3. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Logical Topology . . . . . . . . . . . . . . . . . . . . 10 3.2. PE Roles . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Anchor Groups and Redundancy . . . . . . . . . . . . . . 11 3.4. Forwarding State on a Non-anchor PE . . . . . . . . . . . 11 3.5. Forwarding State at an Anchor . . . . . . . . . . . . . . 12 4. Required EVPN routes and Enhancements to EVPN Procedures . . 12 4.1. Required EVPN Routes . . . . . . . . . . . . . . . . . . 12 4.2. Integrated Routing and Bridging . . . . . . . . . . . . . 12 4.3. EVPN IP Prefix Routes . . . . . . . . . . . . . . . . . . 13 Sajassi, Ed, et al. Expires 6 May 2027 [Page 2] Internet-Draft EVPN Subnet Slicing November 2026 4.4. Default Gateway Extended Community . . . . . . . . . . . 13 4.5. L3-Optimized IRB . . . . . . . . . . . . . . . . . . . . 13 4.6. Behavior of Unknown or Legacy Receivers . . . . . . . . . 14 5. Subnet Slicing Model . . . . . . . . . . . . . . . . . . . . 14 5.1. Partition Definition . . . . . . . . . . . . . . . . . . 14 5.2. Supported Partition Sizes . . . . . . . . . . . . . . . . 15 5.3. Slice Ownership . . . . . . . . . . . . . . . . . . . . . 15 5.4. Single-Group and Multi-Group Models . . . . . . . . . . . 16 5.5. Slice Prefixes Are Not Independent Subnets . . . . . . . 16 5.6. Prefix Overlap and Route Selection . . . . . . . . . . . 16 5.7. Partition Changes . . . . . . . . . . . . . . . . . . . . 17 6. BGP-EVPN Signaling . . . . . . . . . . . . . . . . . . . . . 17 6.1. Subnet-Slice Extended Community . . . . . . . . . . . . . 17 6.2. RT-5 Slice Route Contents . . . . . . . . . . . . . . . . 18 6.3. Slice Route Validation . . . . . . . . . . . . . . . . . 19 6.4. Subnet-Slice Route Target . . . . . . . . . . . . . . . . 19 6.5. RT-2 Export for a Sliced Subnet . . . . . . . . . . . . . 20 6.6. RT-2 Import at an Anchor . . . . . . . . . . . . . . . . 20 6.7. RT-3 and BUM Signaling . . . . . . . . . . . . . . . . . 20 6.8. Route Reflectors and Policy . . . . . . . . . . . . . . . 21 7. Route Origination and Import Procedures . . . . . . . . . . . 21 7.1. Anchor Advertisement Procedure . . . . . . . . . . . . . 21 7.2. Non-Anchor Import Procedure . . . . . . . . . . . . . . . 22 7.3. Local Host Route Procedure . . . . . . . . . . . . . . . 22 7.4. Connected Prefix and Slice Route Coexistence . . . . . . 22 7.5. Anchor Host-Route Installation . . . . . . . . . . . . . 23 7.6. Withdrawal and Stale State . . . . . . . . . . . . . . . 23 7.7. Route-Target Import Matrix . . . . . . . . . . . . . . . 23 8. Forwarding Procedures . . . . . . . . . . . . . . . . . . . . 24 8.1. Host to Remote Host for both Intra/Inter-Subnet Forwarding . . . . . . . . . . . . . . . . . . . . . . . 24 8.2. External to Sliced Host . . . . . . . . . . . . . . . . . 25 8.3. Anchor to Local Host . . . . . . . . . . . . . . . . . . 25 8.4. Unknown Unicast and Unknown IP Destinations . . . . . . . 25 8.5. Packet Encapsulation . . . . . . . . . . . . . . . . . . 25 8.6. Intra-Site East-West Trade-Off . . . . . . . . . . . . . 25 9. Unknown Host Discovery . . . . . . . . . . . . . . . . . . . 26 9.1. ARP and ND Gleaning Procedure . . . . . . . . . . . . . . 26 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 13.1. Normative References . . . . . . . . . . . . . . . . . . 27 13.2. Informative References . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Sajassi, Ed, et al. Expires 6 May 2027 [Page 3] Internet-Draft EVPN Subnet Slicing November 2026 1. Introduction EVPN provides a BGP control-plane based solution for L2 P2P and Multipoint Ethernet services, Ethernet-Tree services, L2 and L3 multicast services, and other services including Integrated , including Integrated Routing and Bridging (IRB) service while providing flexible multihoming, aliasing, overlay and underlay ECMPs for full utilization of cross-sectional bandwidth of the fabric, etc. For EVPN IRB service, an EVPN PE model associates a broadcast domain with a bridge table in a MAC-VRF. An IRB interface connects that bridge table to an IP-VRF. The resulting model supports both intra- subnet bridging and inter-subnet routing. The IRB procedures defined in [RFC9135] and the EVPN IP Prefix route defined in [RFC9136] provide the basis for efficient inter-subnet forwarding. An EVPN PE may advertise a host IP and MAC in a MAC/IP Advertisement route (RT-2) or advertise an IP prefix in an IP Prefix route (RT-5). The EVPN procedures in [RFC7432bis] define the underlying route processing, multihoming, route-target, and flooding behavior. In a large enterprise, campus, data-center, or industrial network, a single broadcast domain may be stretched across many access PEs. A distributed anycast gateway is desirable because it avoids centralized hair-pinning and allows a host to use the nearest first- hop gateway. However, distributing anycast gateways do not by themselves solve the scale problem: if every PE installs every remote endpoint's host route, the IP-VRF and forwarding tables grow with the total endpoint population rather than with the local endpoint population. Subnet slicing changes the distribution of IP forwarding state without changing the IP subnet seen by attached hosts. The original subnet remains intact and stretched across all participating PEs using one default-gateway address. Only the control-plane and forwarding-plane representation of reachability is partitioned. More-specific slice prefixes steer traffic to an anchor group; host routes are retained at the anchors that own the corresponding slice. The design further enhances L3-Optimized IRB. L3-Optimized IRB reduces unnecessary Layer 2 state by routing intra-subnet traffic and may retain MAC state primarily for locally connected hosts. Subnet slicing addresses the remaining IP host-route scale problem by both reducing remote host-route state on anchor PEs and eliminating them completely on non-anchor PEs. A deployment MAY use either solution independently - i.e., some subnets can be configured for standard IRB, some for L3-Optimized IRB, and some others for EVPN Subnet Slicing. Sajassi, Ed, et al. Expires 6 May 2027 [Page 4] Internet-Draft EVPN Subnet Slicing November 2026 This document defines EVPN subnet slicing, an operating mode in which an IP subnet is partitioned into a set of more-specific prefixes called slices. Each slice is anchored on one or more anchor PE(s) that install all host routes for locally anchored slice(s) and advertise EVPN IP prefix routes (Route Type 5) for each locally anchored slice. Non-anchor PEs that participate in the IP VRF but don't anchor any slices don't install any remote host routes. They install locally attached host routes and slice prefix routes received from the anchor PEs. As a result, total host route scale across a stretched subnet is distributed across a set of anchor PEs, and completely decoupled from non-anchor PEs that only have locally attached host routes. The document specifies the control-plane signaling, route-target procedures, data-plane forwarding behavior, unknown-host discovery, failure handling, and operational safeguards required to use with EVPN Subnet Slicing. The procedures apply to both IPv4 and IPv6, and are independent of the underlay encapsulation. 1.1. Scope of This Document This document specifies: * a prefix-partitioning model for IPv4 and IPv6 subnets * an anchor role and an anchor redundancy group for each slice * the use of RT-5 routes to steer traffic to anchor groups * a subnet-slice indication carried in the Default Gateway Extended Community * per-slice route-target procedures for selective RT-2 import * leaf, anchor, and external forwarding behavior * ARP and ND discovery for hosts that have not yet advertised reachability * consistency checks and micro-loop protection Sajassi, Ed, et al. Expires 6 May 2027 [Page 5] Internet-Draft EVPN Subnet Slicing November 2026 1.2. Applicability Statement Subnet slicing is intended for a broadcast domain with a large endpoint population where most traffic is north-south, inter-site, or destined to services reachable through anchor PEs. A sliced broadcast domain may have suboptimal intra-site east-west paths because a packet for a remote endpoint may travel through an anchor even when the endpoint is attached to another PE in the same site. Operators SHOULD use an unsliced optimized-IRB mode for a domain whose dominant traffic pattern is local east-west traffic. 1.3. Requirements Language 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. 1.4. Conventions and Terminology This document assumes familiarity with [RFC7432bis], [RFC9135], and [RFC9136]. *Anchor PE: A PE that originates one or more slice RT-5 routes and imports the RT-2 host routes belonging to those slices into the IP- VRF used for forwarding. *Anchor group: One or more PEs that provide redundant reachability for a slice. An anchor group can consist of a redundant pair, a multihomed set, or another group with equivalent forwarding semantics. All members of an anchor group advertise reachability to the same slice. *Broadcast domain (BD): An EVPN broadcast domain. In this document, the BD is normally associated with one IP subnet and one IRB interface. The terms "BD" and "subnet" are used interchangeably only when the context is clear. *Connected prefix: The original subnet prefix configured on an IRB interface, for example, 192.0.2.0/16. A connected prefix remains present for local host attachment and adjacency processing even when slice routes are installed. *Leaf PE: A participating PE that is not an anchor for a particular slice. The term is descriptive and does not imply a particular physical topology. Sajassi, Ed, et al. Expires 6 May 2027 [Page 6] Internet-Draft EVPN Subnet Slicing November 2026 *Local host route: A host route learned from a locally attached endpoint or locally attached Ethernet segment. A local host route is retained on the PE that learned it and normally has precedence over a slice prefix. *Remote host route: A host route learned from another PE by EVPN control plane procedures. *Slice: A more-specific IP prefix that is a non-overlapping part of a sliced subnet. A slice is identified by its prefix and, within a configured partition, by a zero-based slice index. *Slice index: The ordinal identifying a slice within a partition. For a binary partition of size N, the valid indices are 0 through N-1. *Sliced subnet: A BD for which subnet slicing is enabled and for which all participating PEs follow the procedures in this document. *Subnet-slice indication: The S flag defined in Section 7.2. It marks an RT-5 route as a slice route and tells a receiving PE that the route may override the connected-prefix behavior specified in Section 9. *RT-2: EVPN MAC/IP Advertisement route, as defined in [RFC7432bis]. *RT-3: EVPN Inclusive Multicast Ethernet Tag route, as defined in [RFC7432bis]. *RT-5: EVPN IP Prefix route, as defined in [RFC9136]. *S-RT: Slice Route Target. A route target used to import RT-2 host routes for a particular slice into the IP-VRF of the anchor group that owns that slice. An S-RT can be explicitly provisioned or deterministically derived as described in Section 7.5. *IP-VRF: The virtual routing and forwarding table associated with a tenant or service context. *MAC-VRF: The EVPN MAC virtual routing and forwarding table containing one or more bridge tables. *NVE: Network Virtualization Edge. This document uses PE and NVE according to the applicable EVPN deployment model. *BUM: Broadcast, Unknown-unicast, and Multicast traffic. Sajassi, Ed, et al. Expires 6 May 2027 [Page 7] Internet-Draft EVPN Subnet Slicing November 2026 *Glean: A forwarding action that causes a PE to generate an ARP Request or ND Neighbor Solicitation, or otherwise initiate endpoint discovery, when a destination IP address is covered by a connected subnet but no host adjacency is known. 2. Problem Statement and Design Goals 2.1. Scale Characteristics of Traditional IRB In traditional symmetric or asymmetric IRB, a PE can install remote host routes learned in RT-2 routes into its IP-VRF. This enables direct forwarding to a remote endpoint and supports familiar EVPN mobility behavior. The cost is that the route population is approximately proportional to the number of endpoints in every stretched subnet in the IP VRF. For a subnet with an average of H active local endpoints and L participating leaf PEs, a traditional deployment can create an IP forwarding state of approximately H x L entries on each of L PEs. IPv6 host routes can consume more forwarding resources than IPv4 routes on some implementations, so dual-stack operation can increase the pressure further. The same distribution can create a large number of route updates during endpoint churn. A move, link failure, or endpoint restart may cause RT-2 withdrawals and updates to be processed by every PE even when most PEs do not need a data-plane entry for that endpoint. 2.2. Problems Addressed by This Document Subnet slicing addresses four related problems: 1. A leaf PE should not need to install every remote host route in a large stretched subnet merely to reach the subnet. 2. A single border or gateway pair should not be required to hold all host routes when the endpoint population is larger than the forwarding capacity of one pair. 3. A packet for an unknown or silent endpoint should be discoverable without requiring every leaf PE to originate the same ARP or ND request. 4. Introducing or removing slicing should not require renumbering endpoints or replacing the EVPN service instance. Sajassi, Ed, et al. Expires 6 May 2027 [Page 8] Internet-Draft EVPN Subnet Slicing November 2026 2.3. Design Goals The design goals are: * preserve the existing IP subnet and default-gateway semantics; * support IPv4 and IPv6 with the same conceptual procedures; * use existing EVPN route types where possible; * allow one anchor group to serve all slices or multiple groups to share the host-route population; * permit ECMP between redundant anchors; * maintain local host reachability at every PE attached to an endpoint; * avoid requiring remote host routes in leaf IP-VRF forwarding tables; * support controlled unknown-host discovery for ARP and ND; * make incorrect or incomplete slicing configuration detectable; * provide a safe operational path for mixed deployments. 2.4. Scale Model Let: * H be the average number of active local hosts in a leaf PE; * L be the number of leaf PEs participating in the subnet; * S be the number of slices; * A be the number of anchor groups; * Ha be the number of active hosts on an anchor PE With slicing, an access (or leaf) PE keeps H local host addresses and up to S slice prefixes, while an anchor group keeps approximately the host population assigned to its slice or slices. If the endpoint population is balanced, an anchor group keeps approximately Ha = (H x L)/S host routes for a one-slice-per-group deployment. This is a control-plane and forwarding-state distribution property; the total number of endpoints in the system is unchanged. Sajassi, Ed, et al. Expires 6 May 2027 [Page 9] Internet-Draft EVPN Subnet Slicing November 2026 3. Reference Model 3.1. Logical Topology The following example shows a two-slice deployment. L1, L2, L3andL4are leaf PEs.A1form the anchor group for slice 0, andA2` form the anchor group for slice 1. The same topology can use one anchor group for both slices. slice 0: 10.0.0.0/17 slice 1: 10.0.128.0/17 +--------+ +--------+ | A1 | | A2 | | anchor | | anchor | +--------+ +--------+ +---+---+ +-------+ +---+---+ +---+---+ | L1 | | L2 | | L3 | | L4 | | leaf | | leaf | | leaf | | leaf | +---+---+ +---+---+ +---+---+ +---+---+ | | | | H1 H2 H3 H4 10.0.0.5 10.0.128.5 10.0.0.6 10.0.128.6 | | | | +---------+---------+---------+ broadcast domain 10.0.0.0/16 Figure 1: Subnet Slicing Logical Topology The diagram is logical. The anchor PEs can be physically adjacent to leaves, located in a distribution layer, or connected through a hierarchical EVPN fabric. The procedure only depends on the control- plane and forwarding relationships. 3.2. PE Roles For every sliced subnet, a PE has one of the following roles: * Anchor for slice i: originates the RT-5 for slice i, imports the S-RT for slice i, and maintains remote host forwarding state for that slice. * Non-anchor participant: imports the slice RT-5s, retains local host forwarding state, and does not install remote host routes for the sliced subnet into its IP-VRF forwarding table. Sajassi, Ed, et al. Expires 6 May 2027 [Page 10] Internet-Draft EVPN Subnet Slicing November 2026 * Non-participant: does not import the slice RT-5s and does not provide the subnet-slicing behavior for the subnet. A PE MAY be an anchor for some slices and a non-anchor participant for other slices. A PE MAY be a leaf for one tenant and an anchor for another tenant. Role selection is global; however, subnet slicing can be enabled on per subnet basis. 3.3. Anchor Groups and Redundancy An anchor group has one or more members. For high availability, an operator SHOULD deploy at least two members for every slice. Existing EVPN Ethernet Segment, Ethernet A-D, aliasing, backup-path, DF-election, and split-horizon procedures continue to apply. All members of an anchor group MUST agree on: * the subnet prefix and address family; * the partition size and slice index; * the S-RT used for host-route import; * the tenant and MAC-VRF/IP-VRF context; * the default-gateway IP address and anycast gateway behavior. An anchor group MUST NOT contain members that advertise inconsistent slice prefixes for the same slice. An implementation SHOULD detect inconsistent advertisements and report an operational alarm. 3.4. Forwarding State on a Non-anchor PE For a sliced subnet, a non-anchor leaf maintains at least the following logical state: connected subnet P local subnet and adjacency context local host /32 or /128 directly attached endpoints slice P_0 slice P_0 prefix via anchor group A_0 slice P_1 slice P_1 prefix via anchor group A_1 ... slice P_S-1 slice P_S-1 prefix via anchor group A_S-1 The leaf does not need a remote host route such as 10.0.0.140/32 when that host is attached to another PE. The destination matches the relevant slice prefix and is sent to the anchor group. A local host route is more specific than the slice prefix and therefore remains directly attached. Sajassi, Ed, et al. Expires 6 May 2027 [Page 11] Internet-Draft EVPN Subnet Slicing November 2026 3.5. Forwarding State at an Anchor An anchor maintains: * the slice route for every slice it owns; * local host routes for endpoints attached to the anchor; * remote host routes for endpoints in its anchored slices; * a glean action for an anchored slice when no host adjacency is known; * overlay resolution toward the PE that advertised each selected RT- 2. An anchor MAY retain route information for non-owned slices for transit or external policy purposes, but it MUST NOT import non-owned host routes into the forwarding table merely because it is participating in the same EVPN instance. Such imports would defeat the horizontal scaling objective. 4. Required EVPN routes and Enhancements to EVPN Procedures 4.1. Required EVPN Routes This document uses the EVPN route types as follows: Route | Use in subnet slicing ---------------|---------------------------------------------- Ethernet A-D | Multihoming, aliasing, and failure procedures RT-2 MAC/IP Adv| Local host identity and host reachability RT-3 IMET | BUM replication and ARP/ND discovery RT-5 IP Prefix | Slice-prefix reachability to anchor groups No new EVPN NLRI route type is required. An implementation that does not recognize the subnet-slice indication can still parse the RT-5 NLRI according to [RFC9136], but it cannot safely infer the special connected-prefix and remote-host import behavior defined here. 4.2. Integrated Routing and Bridging The procedures in [RFC9135] remain the foundation for IRB Subnet Slicing. In particular: * the IP-VRF is associated with one or more MAC-VRF bridge tables; * the IRB interface provides the tenant default-gateway function; Sajassi, Ed, et al. Expires 6 May 2027 [Page 12] Internet-Draft EVPN Subnet Slicing November 2026 * Type-2 routes can carry a MAC and an IP binding; * the EVPN Router's MAC Extended Community and overlay labels are used when required for inter-subnet forwarding; * symmetric or asymmetric IRB may be selected according to the deployment. Subnet slicing changes which PE imports a remote RT-2 into its IP-VRF forwarding state. It does not change the identity of the attached host or the MAC-VRF procedures used to distribute that identity. 4.3. EVPN IP Prefix Routes The RT-5 encoding and route processing defined in [RFC9136] are used for slice prefixes. For IPv4, the prefix length is between 0 and 32; for IPv6, it is between 0 and 128. The route carries the normal EVPN fields, including the Route Distinguisher, Ethernet Segment Identifier, Ethernet Tag ID, IP prefix, gateway IP address when applicable, and label or VNI. Unless an overlay index is deliberately used, the RT-5 path identifies the anchor PE through the EVPN next hop, label, router MAC, and encapsulation procedures defined by the deployment type (e.g., MPLS v.s. VXLAN). 4.4. Default Gateway Extended Community The Default Gateway Extended Community is defined by [RFC7432bis] with an opaque type and a reserved Value field. This document assigns one bit in the Value field as the subnet-slice indication. The use of the bit on an RT-5 is an extension of the community's applicability; the existing meaning of the community on a default- gateway RT-2 remains unchanged. 4.5. L3-Optimized IRB L3-Optimized IRB can reduce MAC state by routing intra-subnet traffic and by using ARP/ND termination. Subnet slicing complements that behavior by making the anchor the point at which a remote-host route is resolved. A deployment using both EVPN Subnet Slicing and traditional IRB mechanisms MUST define the behavior for an optimized PE communicating with a traditional IRB PE. The common-denominator behavior is bridging for traffic that cannot be routed with the information available at both PEs, as described in the optimized-IRB work. Sajassi, Ed, et al. Expires 6 May 2027 [Page 13] Internet-Draft EVPN Subnet Slicing November 2026 4.6. Behavior of Unknown or Legacy Receivers An EVPN receiver that does not understand the S bit will process the RT-5 as an ordinary RT-5 or ignore it according to its normal route- type support. It will not apply the subnet-slicing import and loop- prevention procedures. Therefore, an operator MUST NOT advertise sliced RT-5 routes to a legacy PE that may install them in a way that conflicts with its connected-prefix or host-route behavior. Mixed deployments are supported only when explicit route-target policy or an equivalent capability boundary ensures that legacy PEs either: 1. do not import sliced RT-5 routes and continue to import the required RT-2 host routes; or 2. have an implementation-specific capability that provides equivalent subnet-slicing semantics. 5. Subnet Slicing Model 5.1. Partition Definition Let P be an IPv4 or IPv6 subnet prefix with prefix length p. A partition with S slices is an ordered set: Subnet(P, S) = { P_0, P_1, ..., P_S-1 } For the default binary partition, S MUST be a power of two. The slice prefix length is: p_slice = p + log2(S) The partition MUST satisfy all of the following: * every P_i is contained in P; * no two P_i overlap; * the union of all P_i is exactly P; * every P_i has the same address family; * every P_i has the same prefix length for a uniform partition; * the mapping from prefix to slice index is deterministic for all participating PEs. Sajassi, Ed, et al. Expires 6 May 2027 [Page 14] Internet-Draft EVPN Subnet Slicing November 2026 For the canonical example used in this document, 10.0.0.0/16 with two slices produces: P_0 = 10.0.0.0/17 P_1 = 10.0.128.0/17 For IPv6, the same rule applies. A /64 partitioned into eight slices uses eight aligned /67 prefixes. 5.2. Supported Partition Sizes An implementation MUST support a two-slice partition. It MAY support four, eight, or sixteen slices. A deployment MUST NOT advertise a slice count that any participating PE cannot process. The set of supported sizes is an implementation capability and can be extended in future documents. The number of slices is a property of the sliced subnet, not of an individual RT-5 advertisement. All PEs that participate in the subnet MUST be provisioned with the same partition or must learn an equivalent partition from a trusted controller. When an explicit, non-uniform partition is used, every slice prefix MUST be advertised and each PE MUST know the complete prefix to S-RT mapping. 5.3. Slice Ownership Each slice MUST have exactly one active anchor group at a time within an administrative EVPN domain. An anchor group may have multiple members for redundancy. Two independent groups MUST NOT concurrently claim the same slice unless the operator intentionally uses anycast ownership and has verified that both groups can forward every host route in the slice. An anchor PE that owns slice i MUST: * originate the RT-5 for P_i with the S bit set; * import RT-2 host routes for P_i using S-RT_i route target; * install a glean action for unresolved destinations in P_i, subject to the discovery policy; * advertise or withdraw its RT-5 as its ability to serve P_i changes. Sajassi, Ed, et al. Expires 6 May 2027 [Page 15] Internet-Draft EVPN Subnet Slicing November 2026 5.4. Single-Group and Multi-Group Models In the single-group model, one redundant group owns all slices. The leaf route table contains one route per slice, but the anchor group retains all host routes. This model decouples leaf IP-VRF scale from the endpoint count but does not horizontally divide the anchor load. In the multi-group model, different anchor groups own different slices. Host routes are imported only by the anchor group that owns the slice. This model reduces the host-route population per anchor group and allows capacity to be added by adding groups and reassigning future slices. Single-group Multi-group B1/B2/B3/B4 B1/B2 B3/B4 own P0..P3 own P0,P1 own P3,P4 | \\ / +------------- all leaf PEs ------------+-----+ Figure 2: Single-group v.s. Multi-group 5.5. Slice Prefixes Are Not Independent Subnets The slice prefixes are an internal reachability partition. Hosts continue to use the original subnet mask and default-gateway address. ARP and ND remain associated with the original broadcast domain. A slice prefix MUST NOT be advertised to an attached host as a new on- link prefix, and an anchor MUST NOT respond to ARP or ND as if the slice were a separate link. External routing is different: an operator MAY advertise slice prefixes to an external router as more-specific routes, as described in Section 12, because the external router is not a member of the original broadcast domain. 5.6. Prefix Overlap and Route Selection A slice route is intentionally more specific than the connected prefix. It therefore wins a normal longest-prefix match for a remote address inside the slice. A local host route, when present, is more specific than the slice route and MUST continue to win. An implementation MUST preserve local adjacency behavior even when the connected prefix is covered by more-specific slice routes. Sajassi, Ed, et al. Expires 6 May 2027 [Page 16] Internet-Draft EVPN Subnet Slicing November 2026 The subnet-slice indication exists because some route consumers use the covering route to decide whether a local host adjacency is valid. Such consumers MUST be able to identify and skip a slice route when they need the original connected-prefix context. This requirement applies to adjacency creation, DHCP or other control-plane packet injection, and any equivalent operation that expects the configured IRB interface to be the output context. 5.7. Partition Changes Changing S, changing slice boundaries, or changing slice ownership is a control-plane change that can affect forwarding. An implementation MUST NOT change the partition implicitly when receiving an RT-5. The operator or controller MUST coordinate the change across all participating PEs. A safe change procedure is described in Sections 14.4 through 14.6. In summary, new routes are advertised before old routes are withdrawn, ownership is changed only after all required anchors can import the corresponding host routes, and the old partition is removed after a convergence interval. 6. BGP-EVPN Signaling EVPN Subnet Slicing requires the following BGP-EVPN signaling changes: 1. An anchor advertises an RT-5 for each slice and all other anchor and non-anchor PEs install these prefixes 2. The RT-5 carries the S bit in the Default Gateway Extended Community indicating that this prefix represents a subnet slice 3. A non-anchor PE that originates a local host advertises an RT-2 with the S-RT for the host's slice, allowing only the slice owner to import that host into its IP-VRF 6.1. Subnet-Slice Extended Community This document defines a new Extended Community for Subnet Slicing as follow: Sajassi, Ed, et al. Expires 6 May 2027 [Page 17] Internet-Draft EVPN Subnet Slicing November 2026 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x06 | Sub-Type=0x11 | Res(1 octet) | Slice Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Subnet-Slice EC All other bits in the reserved field SHOULD be transmitted as zero and MUST be ignored on receipt. An anchor-originated slice RT-5 MUST carry the Subnet Slice Extended Community (SS EC). A non-slice RT-5 MUST NOT this extended community according to [RFC9136]. Slice Size gives the number of slices and it is used for consistency check among anchor PEs. An implementation receiving an RT-5 with SS EC MUST perform the validation in Section 6.4 before installing it as a slice route. If validation fails, the route MUST be treated as unusable for subnet slicing and an operator-visible error SHOULD be generated. The receiver MAY retain the route as an ordinary RT-5 only if doing so cannot override a connected prefix or create a forwarding loop; otherwise it MUST treat the route as withdrawn for local forwarding. 6.2. RT-5 Slice Route Contents Each slice RT-5 MUST contain: * the route key and RD required by [RFC9136]; * the exact slice prefix and prefix length; * the appropriate Ethernet Tag ID for the broadcast domain; * a valid EVPN next hop or overlay index; * a label or VNI as required by the selected encapsulation; * the Subnet-Sliced Extended Community with a valid slice size; * the IP-VRF route target used to import the sliced subnet; * the normal EVPN Router's MAC Extended Community when required by the forwarding model. Sajassi, Ed, et al. Expires 6 May 2027 [Page 18] Internet-Draft EVPN Subnet Slicing November 2026 6.3. Slice Route Validation Before accepting an S-marked RT-5 as a slice route, a PE MUST verify: 1. the prefix is contained by a locally configured sliced subnet; 2. the prefix is a valid member of the configured partition; 3. the Ethernet Tag ID and tenant context match the sliced subnet; 4. the route's address matches the IRB interface; 5. the next hop, label, VNI, and router MAC are usable under [RFC9136]; 6. the advertising PE is authorized to serve the slice by route policy or anchor-group membership; 7. no conflicting slice route from an unauthorized owner has been selected. 6.4. Subnet-Slice Route Target Each slice has an S-RT. The S-RT controls import of host routes into the IP-VRF of the anchor group. An S-RT is a normal BGP Route Target Extended Community; this document does not require a new route-target encoding. An operator MAY provision the S-RT explicitly. Explicit provisioning is RECOMMENDED when multiple administrative domains, non-uniform partitions, or legacy PEs are present. An implementation SHOULD derive S-RTs deterministically. The per-VRF slice RT (S-RT) is auto derived using the following scheme to ensure uniqueness and proper Association with slices. The auto derivation of RT for VxLAN as defined in [RFC8365] is extended as follow: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Administrator |A| TYPE| D-ID | Service ID | +-----------------------------------------------+---------------+ | Service ID (Cont.) | +-------------------------------+ Figure 4: Subnet-Slice Route Target * "A" field as before Sajassi, Ed, et al. Expires 6 May 2027 [Page 19] Internet-Draft EVPN Subnet Slicing November 2026 * a new "Type" 6 is defined for VxLAN-SS * When Type==6, then D-ID field needs to be interpreted as Slice ID The slice count MAY be included in the management data used to derive an S-RT, but it MUST NOT change the S-RT of an existing slice during an otherwise unchanged deployment. This property permits a partition to be extended only through an explicit migration procedure. 6.5. RT-2 Export for a Sliced Subnet A PE that originates a local RT-2 for a host in slice i MUST include the S-RT for slice i in the route's export policy. It MAY also include the normal BD route target required for MAC-VRF distribution and host identity. If both are present, import policies MUST distinguish MAC-VRF consumption from IP-VRF host-route installation. For the IP-VRF import function: * an anchor group for slice i MUST import S-RT_i; * an anchor group for a different slice SHOULD NOT import S-RT_i; * a non-anchor PE MUST NOT install the imported RT-2 as a remote host route in the sliced subnet's IP-VRF forwarding table; 6.6. RT-2 Import at an Anchor The anchor IP-VRF import policy selects RT-2 routes by S-RT_i and then applies the normal EVPN route-selection, MAC mobility, ESI, and next-hop resolution procedures. The resulting host route is installed only if its IP address is inside P_i and the route's service context is the expected sliced subnet. An anchor MUST reject or quarantine an RT-2 that carries S-RT_i but has a host IP outside P_i. This check is important when a host route is imported through a route reflector or a multi-site gateway. 6.7. RT-3 and BUM Signaling RT-3 procedures are unchanged for ordinary BUM behavior. When selective ARP/ND discovery is used, anchor PEs MUST import enough RT-3 state to reach all participating PEs that may contain a host in the slice. A leaf PE MUST not be required to import an anchor-only RT-3 route if its local flooding policy already provides the required delivery. Sajassi, Ed, et al. Expires 6 May 2027 [Page 20] Internet-Draft EVPN Subnet Slicing November 2026 An operator SHOULD use selective replication when the number of participating PEs is large. 6.8. Route Reflectors and Policy Route reflectors SHOULD treat S-marked RT-5 routes and S-RT-bearing RT-2 routes as ordinary transitive EVPN routes, subject to the route- reflector policy. A route reflector MUST NOT rewrite or remove the S bit. It MUST NOT rewrite an S-RT in a way that breaks the anchor import contract unless the domain's route-target policy deliberately remaps the same value at both ends. When a route reflector is used across sites or administrative domains, the operator MUST ensure that the S-RT remains meaningful in the receiving domain. Site-local SRTs MAY be remapped, but the receiving site MUST map the host route to the local slice that contains the host prefix. 7. Route Origination and Import Procedures 7.1. Anchor Advertisement Procedure An anchor PE that is operationally able to serve slice i MUST originate an RT-5 for P_i as follows: 1. Associate P_i with the sliced subnet's EVI, BD, and IP-VRF. 2. Select the anchor PE's RD and the Ethernet Tag ID. 3. Set the IP prefix and prefix length to P_i. 4. Set the next hop, overlay index, VNI (or label), and Router's MAC according to [RFC9136] and the encapsulation deployment. 5. Attach the IP-VRF import/export route targets for the sliced subnet. 6. Attach the Default Gateway Extended Community with S=1. 7. Advertise the route through the BGP EVPN address family. The anchor MUST withdraw the RT-5 when it cannot forward traffic to the endpoints in the slice, when the subnet is administratively disabled, or when the anchor loses the required IP-VRF or tunnel state. An anchor MUST NOT continue advertising a slice only because the connected slice prefix remains configured if the anchor cannot provide the required route resolution. Sajassi, Ed, et al. Expires 6 May 2027 [Page 21] Internet-Draft EVPN Subnet Slicing November 2026 7.2. Non-Anchor Import Procedure A non-anchor PE that receives and accepts an S-marked RT-5 MUST: 1. verify the route as specified in Section 6.4; 2. install the slice prefix in the sliced subnet's IP-VRF with the EVPN next-hop resolution; 3. mark the route as a slice route for route consumers and forwarding policy; 4. suppress installation of remote RT-2 host routes for the sliced subnet in the IP-VRF forwarding table; 5. retain local host routes and local adjacency state; 6. apply the loop-prevention behavior in Section 10 If multiple anchor paths for the same slice are valid, the non-anchor PE SHOULD install ECMP to the anchor group. If the paths are not equivalent under the deployment's redundancy model, the PE MUST apply the normal EVPN best-path and multihoming procedures. 7.3. Local Host Route Procedure A PE that learns a host locally MUST install a local host route or adjacency that is more specific than the slice route. The local host route MUST use the local attachment context and MUST NOT be recursively resolved through the anchor group merely because the slice route is more specific than the slice prefix. The local host route SHOULD be exported as an RT-2 according to Section 6.6. A local host route SHOULD be marked non-redistributable into unrelated routing domains unless the operator explicitly requests redistribution. This prevents the internal helper route from being mistaken for an externally originated route. 7.4. Connected Prefix and Slice Route Coexistence The following logical lookup order applies to a sliced subnet: 1. local host route 10.0.1.10/32 -> local adjacency 2. remote host route (anchor only) -> remote PE 3. slice route 10.0.0.0/17 -> anchor group 4. slice route 10.0.128.0/17 -> anchor group 5. connected prefix 10.0.0.0/16 -> local subnet context Sajassi, Ed, et al. Expires 6 May 2027 [Page 22] Internet-Draft EVPN Subnet Slicing November 2026 The list expresses forwarding preference, not necessarily one implementation RIB's administrative-distance rules. If a PE does not have a local host route, the slice route is selected. If a PE is an anchor and has a remote host route, the host route is selected. The connected prefix remains available for local endpoint handling and for addresses not covered by an active slice route during a controlled transition. 7.5. Anchor Host-Route Installation An anchor imports an RT-2 with S-RT_i only if the route is valid for P_i. The anchor resolves the route's next hop using the EVPN procedures for the advertising PE, Ethernet Segment, VNI (or label), and Router's MAC. The anchor then installs the host route in its IP- VRF forwarding table. If the route is received from two or more PEs, the anchor applies the normal EVPN best-path and aliasing rules. If ECMP is allowed, the anchor SHOULD install multiple next hops. The anchor MUST NOT install a host route whose selected path resolves back to itself unless the local attachment is the valid selected path. 7.6. Withdrawal and Stale State When an RT-2 is withdrawn, an anchor MUST remove the corresponding remote host route or mark it unresolved according to its normal EVPN convergence behavior. When an anchor removes a host route, the associated glean state MAY be recreated after the configured hold- down or dampening interval. 7.7. Route-Target Import Matrix The following table summarizes the intended import behavior for a two-slice, two-anchor-group example. |Receiver |Import P0|Import P1|Install remote|Install remote| | |RT-5 |RT-5 |RT-2 for P0 |RT-2 for P1 | |---------------|---------|---------|--------------|--------------| |Leaf L1 | Yes | Yes | No | No | |Leaf L2 | Yes | Yes | No | No | |Anchor group A0| Yes |Optional | Yes | No | |Anchor group A1|Optional | Yes | No | Yes | |External GW |Policy- |Policy- |Policy-based |Policy-based | | based based | Figure 5: Route Target Import Matrix Sajassi, Ed, et al. Expires 6 May 2027 [Page 23] Internet-Draft EVPN Subnet Slicing November 2026 "Optional" means that the route may be retained or installed for a specific inter-site or service function, but it is not required for the anchor's local host-route scale objective. 8. Forwarding Procedures 8.1. Host to Remote Host for both Intra/Inter-Subnet Forwarding When a local endpoint sends a packet to a remote endpoint in the same sliced subnet, the local PE performs the following steps: 1. The packet is received on the attachment circuit and reaches the IP-VRF forwarding context. 2. The PE looks up the destination IP address. 3. If a local host route exists, the PE forwards locally. 4. Otherwise, the destination matches a slice prefix P_i. 5. The PE selects the anchor group for P_i and encapsulates the packet using the EVPN IRB/NVO procedure. 6. The anchor receives and decapsulates the packet. 7. The anchor looks up the destination host route in the corresponding IP-VRF table. 8. The anchor forwards the packet to the PE advertising the destination host, or initiates gleaning if no host route is present. H1 L1 A0 L2 H2 | | | | | | IP to H2 | | | | |------------->| LPM = P0 | | | | |================>| host /32 -> L2 | | | | |================>|----------->| | | | | | Figure 6: Subnet Slicing Packet Forwarding Sajassi, Ed, et al. Expires 6 May 2027 [Page 24] Internet-Draft EVPN Subnet Slicing November 2026 8.2. External to Sliced Host When external traffic enters through an anchor or service gateway, the receiving PE performs a lookup for the destination. If it has the appropriate host route, it forwards directly to the hosting PE. Otherwise, the external packet is sent to the anchor group selected by the slice prefix. This behavior requires that the external route domain learn either the slice prefixes or an appropriate summary route to a PE that can discover the host. 8.3. Anchor to Local Host An anchor that owns a slice may also have local endpoints in the same subnet. A local host route is preferred over the slice route and the anchor forwards directly to the local attachment. An anchor MUST NOT send a packet to another anchor solely because the destination is inside a slice that the anchor owns when a valid local host route exists. 8.4. Unknown Unicast and Unknown IP Destinations Subnet slicing is an IP host-route distribution mechanism. It does not change the EVPN behavior for a packet that is not an IP packet or that cannot be associated with the sliced IP-VRF. Non-IP traffic, mismatched IP versions, and ordinary Layer 2 unknown-unicast behavior follow the EVPN service policy. For an IP packet whose destination matches a slice but has no resolved host route at the anchor, the anchor uses the glean procedure in Section 9 or drops the packet according to policy. A leaf MUST NOT flood an unknown IP destination independently merely because it selected the slice route. 8.5. Packet Encapsulation The packet from a leaf to an anchor uses the overlay encapsulation for the deployment. For an MPLS EVPN network, this may be an EVPN label stack. For an NVO network, this may be VXLAN, GENEVE, or another supported encapsulation. The inner Ethernet source and destination, label, VNI, and Router's MAC MUST follow [RFC9135], [RFC9136], and the selected encapsulation specification. 8.6. Intra-Site East-West Trade-Off Because a leaf does not contain remote host routes, a packet from H1 on L1 to H2 on L2 follows the slice route to the anchor and then returns to L2. The operator can choose one of three policies: Sajassi, Ed, et al. Expires 6 May 2027 [Page 25] Internet-Draft EVPN Subnet Slicing November 2026 * use subnet slicing and accept the anchor path; * use optimized IRB without slicing for high east-west efficiency; * deploy a hybrid policy in which only high-density, north-south- oriented subnets are sliced. 9. Unknown Host Discovery A silent host may not have originated an RT-2 and may not have answered a recent ARP or ND request. Since only the anchor owns the slice route and remote host table, the anchor is the correct point to initiate discovery for an unknown destination. 9.1. ARP and ND Gleaning Procedure For an IPv4 destination D in slice P_i with no host route, the anchor SHOULD: 1. create or confirm a glean entry for D; 2. generate an ARP Request or ND Neighbor Solicitation using the anycast gateway IP and MAC for that broadcast domain; 3. replicate the ARP Request or ND Neighbor Solicitation message to the participating PEs according to the RT-3 and BUM policy; 4. leaf terminates and accepts the ARP Reply or Neighbor Advertisement and associate the returned MAC with D; 5. the leaf that receives the ARP reply or Neighbor Advertisement, originates an RT-2 for the MAC & IP pair 6. the anchor import the RT-2 using S-RT_i and resolve subsequent data traffic. 10. Security Considerations The security considerations outlined in [RFC7432] [RFC8365] for EVPN routes are applicable to this specification. In addition, the security considerations sections in [RFC9135] and [RFC9136] are relevant to this document. 11. IANA Considerations This document defines a new flag in Default Gateway Extended Community as follow: Sajassi, Ed, et al. Expires 6 May 2027 [Page 26] Internet-Draft EVPN Subnet Slicing November 2026 S flag: Subnet_Slice flag, the least-significant bit of the first octet of the reserved field 12. Acknowledgments The authors want to thank Chuanfa Wang for his significant contribution to this document. The authors want to also thank Ramchander Nadipally and Krishnamoorthy Arumugham from Cisco and Dinu Thomas from Meta for their valuable feedback and engaging discussions. 13. References 13.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, . [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. Henderickx, "Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, September 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and A. Sajassi, "IP Prefix Advertisement in Ethernet VPN (EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021, . 13.2. Informative References [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, . Sajassi, Ed, et al. Expires 6 May 2027 [Page 27] Internet-Draft EVPN Subnet Slicing November 2026 [RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos, Ed., "The Locator/ID Separation Protocol (LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022, . [RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, Ed., "Locator/ID Separation Protocol (LISP) Control Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022, . Authors' Addresses Ali Sajassi Cisco Email: sajassi@cisco.com Neeraj Malhotra Cisco Email: nmalhotr@gmail.com Rahul Kachalia Cisco Email: kachalia@cisco.com Carlos Zeledon Meta Email: czeledon@meta.com Sajassi, Ed, et al. Expires 6 May 2027 [Page 28]