IDR Working Group W. Wang Internet-Draft A. Wang Intended status: Experimental China Telecom Expires: 27 June 2026 H. Wang Huawei Technologies G. Mishra Verizon Inc. J. Dong Huawei Technologies 24 December 2025 VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4 draft-ietf-idr-vpn-prefix-orf-24 Abstract This draft defines a new type of Outbound Route Filter (ORF), known as the Virtual Private Network (VPN) Prefix ORF. The VPN Prefix ORF mechanism is applicable when VPN routes from different Virtual Routing and Forwarding (VRF) instances are exchanged through a single shared Border Gateway Protocol (BGP) session.The purpose of VPN Prefix ORF mechanism is to control the overload of VPN routes based on RT. With this mechanism, the overload can be limited within the minimum range. 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 27 June 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Wang, et al. Expires 27 June 2026 [Page 1] Internet-Draft RD-ORF December 2025 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Existing Solutions . . . . . . . . . . . . . . . . . . . . . 5 3.1. Route Target Constraint (RTC) . . . . . . . . . . . . . . 5 3.2. Address Prefix ORF . . . . . . . . . . . . . . . . . . . 5 3.3. CP-ORF Mechanism . . . . . . . . . . . . . . . . . . . . 5 3.4. PE-CE edge peer Maximum Prefix . . . . . . . . . . . . . 5 3.5. Configuring the Maximum Prefix for each VRF on edge nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. VPN Prefix ORF Encoding . . . . . . . . . . . . . . . . . . . 6 4.1. Source PE TLV (including 3 types) . . . . . . . . . . . . 9 4.2. Source AS TLV . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Route Target TLV . . . . . . . . . . . . . . . . . . . . 10 5. The general procedures of VPN Prefix ORF mechanism . . . . . 10 5.1. Process of VPN Prefix ORF mechanism on sender . . . . . . 10 5.1.1. Intra-domain Scenarios and Solutions . . . . . . . . 13 5.2. Protocol process of VPN Prefix ORF mechanism on receiver . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Source PE Extended Community . . . . . . . . . . . . . . . . 15 7. Operational Considerations . . . . . . . . . . . . . . . . . 16 7.1. Quota value calculation . . . . . . . . . . . . . . . . . 16 7.2. Withdraw of VPN Prefix ORF entries . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9.1. VPN Prefix Outbound Route Filter . . . . . . . . . . . . 18 9.2. VPN Prefix ORF TLV types . . . . . . . . . . . . . . . . 19 9.3. Source PE Extended Community . . . . . . . . . . . . . . 19 9.4. Commen part of ORF entry . . . . . . . . . . . . . . . . 20 10. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 20 12. Normative References . . . . . . . . . . . . . . . . . . . . 20 Appendix A. Experimental topology . . . . . . . . . . . . . . . 22 Appendix B. Intra-domain Scenarios and Solutions . . . . . . . . 23 B.1. Scenario 1: unique RD (per VPN, per PE) . . . . . . . . . 23 B.2. Scenario 2: the same RD (per VPN, same on all PEs) . . . 26 Appendix C. Applicability . . . . . . . . . . . . . . . . . . . 28 Wang, et al. Expires 27 June 2026 [Page 2] Internet-Draft RD-ORF December 2025 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction BGP Maximum Prefix feature [RFC4486] is often used at the network boundary to control the number of prefixes to be injected into the network. But for some scenarios when the VPN routes from several VRFs are advertised via one shared BGP session, there is lack of appropriate methods to control the flooding of VPN routes within one VRF to avoid overwhelming the processing of VPN routes in other VRFs, which consequently affects the route processing performance of other VRFs (such as route dropping, processing delays, and abnormal customer services). Therefore, it is desirable that the excessive VPN routes advertisement be controlled individually for each VRF in such a shared BGP session. There are several solutions that can be used to alleviate this problem: * Route Target Constraint (RTC) as defined in [RFC4684] * Address Prefix ORF as defined in [RFC5292] * Covering Prefixes Outbound Route Filter (CP-ORF) mechanism as defined in [RFC7543] * Provider Edge (PE) - Customer Edge (CE) edge peer Maximum Prefix * Configuring the Maximum Prefix for each VRF on edge nodes However, each existing solution has its own limitation as described in Section 4. This draft defines a new type of Outbound Route Filter (ORF), called the VPN Prefix ORF. This ORF mechanism is event-driven and does not require pre-configuration. When the number of VPN routes in a VRF exceeds the prefix limit, the router will identify the VPN prefix (Route Distinguisher (RD), Route Target (RT), source PE, etc.) of the overload VPN routes in this VRF and send a VPN Prefix ORF message to its BGP peer, who announced these overload routes. Upon receiving a VPN Prefix ORF entry from its BGP peer, the BGP speaker will filter and withdraw any overload VPN routes that was announced to its peer. The purpose of this mechanism is to control the overload within the minimum range and avoid route churn effects when a VRF on a device in the network overflows. Wang, et al. Expires 27 June 2026 [Page 3] Internet-Draft RD-ORF December 2025 VPN Prefix ORF is applicable when the VPN routes from different VRFs are exchanged via one shared BGP session. 1.1. 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. 2. Terminology The following terms are used in this draft: * AFI: Address Family Identifier, defined in [RFC4760] * ASBR: Autonomous System Border Router. * BGP: Border Gateway Protocol, defined in [RFC4271] * EVPN: BGP/MPLS Ethernet VPN, defined in [RFC7432] * MPLS: Multi-Protocol Label Switching. * ORF: Outbound Route Filter, defined in [RFC5291] * Quota: A threshold to limit the number of VPN routes under specific granularities (such as , ). * RD: Route Distinguisher, defined in [RFC4364] * RIB: Routing Information Base. * RR: Route Reflector, provides a simple solution to the problem of IBGP full mesh connection in large-scale IBGP implementation [RFC4456] * RT: Route Target, defined in [RFC4364] * SAFI: Subsequent Address Family Identifier, defined in [RFC4760] * VPN: Virtual Private Networks, defined in [RFC4364] * VRF: Virtual Routing Forwarding, a virtual routing table based on VPN instance. Wang, et al. Expires 27 June 2026 [Page 4] Internet-Draft RD-ORF December 2025 3. Existing Solutions 3.1. Route Target Constraint (RTC) RTC can only filter the VPN routes from any uninterested VRFs, if the route overload comes from an interested VRF, the RTC mechanism can't filter them. 3.2. Address Prefix ORF Using Address Prefix ORF to filter VPN routes requires a pre- configuration, but it is impossible to know in advance which prefix may exceed the predefined threshold. 3.3. CP-ORF Mechanism [RFC7543] defines the Covering Prefixes ORF (CP-ORF). A BGP speaker sends a CP-ORF to a peer in order to pull routes that cover a specified host address. A prefix covers a host address if it can be used to forward traffic towards that host address. CP-ORF is applicable in Virtual Hub-and-Spoke [RFC7024] VPN and also BGP/MPLS Ethernet VPN (EVPN) [RFC7432] networks, but its primary function is to retrieve interested VPN prefixes and it cannot be used to filter overload of VPN prefixes dynamically. 3.4. PE-CE edge peer Maximum Prefix The BGP Maximum-Prefix feature is used to control how many prefixes can be received from a neighbor. By default, this feature allows a router to drop overloading routes or bring down a peer when the number of received prefixes from that peer exceeds the configured Maximum-Prefix limit. This feature is commonly used for external BGP peers. If it is applied to internal BGP peers, for example the VPN scenarios, all the VPN routes from different VRFs will share the common fate. If the number of VPN routes of a certain VPN exceeds the configured Maximum-Prefix limit, the overloading VPN routes will be dropped, or BGP session will be shut down, which will affect the operation of other VPN routes transmitted via this BGP session. If Maximum Prefix is configured on every PE-CE link, it can prevent VPN route overflow. However, reliance solely on the sender side for protection is insufficient; if the sender has not configured Maximum Prefix, the VPN Prefix ORF mechanism can still prevent VPN route overflow from occurring. Wang, et al. Expires 27 June 2026 [Page 5] Internet-Draft RD-ORF December 2025 3.5. Configuring the Maximum Prefix for each VRF on edge nodes When a VRF overflows, some implementations may stops the import of routes. Any additional VPN routes are held into its Routing Information Base (RIB). However, PEs still need to parse the incoming BGP messages. This will cost CPU cycles and further burden the overflowed PE. The VPN Prefix ORF mechanism improves upon this by enabling the overloaded PE to signal the specific offending routes back to the sender, which can then suppress them at the source—eliminating wasted processing and preserving resources for healthy VRFs. 4. VPN Prefix ORF Encoding In this section, we describe the encoding of VPN Prefix ORF entries. The VPN Prefix ORF entries are carried in the BGP ROUTE-REFRESH message as defined in [RFC5291]. A BGP ROUTE-REFRESH message can carry one or more ORF entries. The format of a ROUTE-REFRESH message which carries VPN Prefix ORF entries are as follows: * AFI (2 octets). The AFI MUST be set to IPv4, IPv6, or Layer 2 VPN (L2VPN). * SAFI (1 octet). If the AFI is set to IPv4 or IPv6, the SAFI MUST be set to MPLS-labeled VPN address. If the AFI is set to L2VPN, the SAFI MUST be set to BGP EVPN. It is applicable for all types of EVPN routes as mentioned in [RFC7432]. * When-to-refresh (1 octet): the value is IMMEDIATE or DEFER. * ORF Type (1 octet): The type of VPN Prefix ORF is 66. * Length of ORF entries (2 octets) A VPN Prefix ORF entry contains a common part and type-specific part. The encoding of the common part is shown in Figure 4. Wang, et al. Expires 27 June 2026 [Page 6] Internet-Draft RD-ORF December 2025 +-----------------------------------------+ | | | Action (2 bits) | | | +-----------------------------------------+ | | | Match (1 bits) | | | +-----------------------------------------+ | | | Overload VPN routes process | | method (1 bit) | | | +-----------------------------------------+ | | | Reserved (4 bits) | | | +-----------------------------------------+ Figure 5: VPN Prefix ORF type-specific encoding * Action (2 bits): the value is ADD, REMOVE or REMOVE-ALL. * Match (1 bit): the value is PERMIT or DENY * Overload VPN routes process method (1 bit): if the value is set to 0, it means all overload VPN routes on the sender of VPN Prefix ORF message SHOULD be withdrawn; if the value is set to 1, it means the sender of VPN Prefix ORF message refuse to receive new overload VPN routes. The default value is 0. * Reserved (4 bits) VPN Prefix ORF also contains type-specific part. The encoding of the type-specific part is shown in Figure 5. Wang, et al. Expires 27 June 2026 [Page 7] Internet-Draft RD-ORF December 2025 +-----------------------------------------+ | | | Sequence (4 octets) | | | +-----------------------------------------+ | | | Length (2 octets) | | | +-----------------------------------------+ | | | Route Distinguisher (8 octets) | | | +-----------------------------------------+ | | | Optional TLVs (variable) | | | +-----------------------------------------+ Figure 5: VPN Prefix ORF type-specific encoding * Sequence: identifying the order in which VPN Prefix ORF is generated and evaluated. It can uniquely identify a VPN Prefix ORF entry together with AFI/SAFI, ORF-Type, and Route Distinguisher. The sequence numbers SHOULD be discontinuous to facilitate the insertion of new rules at a later stage. * Length: identifying the length of this VPN Prefix ORF entry. * Route Distinguisher: distinguish the different user routes. The VPN Prefix ORF filters the VPN routes it tends to send based on Route Distinguisher. If RD is equal to 0, it means all VPN prefixes. * Optional TLVs: carry the potential additional information to give the extensibility of the VPN Prefix ORF mechanism. Its format is shown in Figure 6. If one or more TLV(s) are unrecognized, the whole VPN Prefix ORF entry SHOULD be removed. 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 | Length | value (variable) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 The format of optional TLV(s) Note that if the Action component of an ORF entry specifies REMOVE- ALL, the ORF entry does not include the type-specific part. Wang, et al. Expires 27 June 2026 [Page 8] Internet-Draft RD-ORF December 2025 When the BGP ROUTE-REFRESH message carries VPN Prefix ORF entries, it MUST be set as follows: * The ORF-Type MUST be set to 66 (VPN Prefix ORF). * The purpose of VPN Prefix ORF is to block unwanted VPN prefixes, then the "action" of one valid entry SHOULD be set to "DENY". In order to allow other allowed VPN prefixes pass the filter, one default, last resort entry SHOULD be installed in advance in the VPN Prefixes ORF table, with the RD is set to 0 and the corresponding Sequence are set to 0xFFFFFFFF. According to [RFC5291], if any of the fields of a VPN Prefix ORF entry in the message contains an unrecognized value, the whole specified ORF previously received is removed. A BGP speaker that is willing to receive ORF entries from its peer, or a BGP speaker that would like to send ORF entries to its peer, advertises this capability to the peer by using the Outbound Route Filtering Capability defined in [RFC5291]. 4.1. Source PE TLV (including 3 types) Source PE TLV is defined to identify the source of the VPN routes. For the sender of VPN Prefix ORF, it will check the existence of SPE EC on the VPN route being matched. If it exists, the sender will put it into Source PE TLV. Otherwise, the value of Source PE TLV SHOULD be set to next hop address. The Source PE TLV SHOULD only appear once within an individual ORF entry. If one ORF entry contains multiple Source PE TLVs, all MUST be ignored. The source PE TLV contains the following types: * IPv4 Source PE TLV: Type = 1, Length = 4 octets, value = next hop address in IPv4 format. * IPv6 Source PE TLV: Type = 2, Length = 16 octets, value = next hop address in IPv6 format (only global IPv6 address). * Source PE identifier TLV: Type = 3, Length = 4 octets, value = the value of ORIGINATOR_ID in Source PE Extended Community. 4.2. Source AS TLV Source AS TLV is defined to identify the source AS number of source PE. It is only required in inter-domain scenario. Wang, et al. Expires 27 June 2026 [Page 9] Internet-Draft RD-ORF December 2025 The Source AS TLV SHOULD only appear once within an individual ORF entry. If one ORF entry contains multiple Source AS TLVs, it SHOULD be ignored. The encoding of Source AS TLV is as follows: Type = 4, Length = 4 octets, value = the value of Source AS in Source AS Extended Community as defined in [RFC6514]. 4.3. Route Target TLV Route Target TLV is defined to identify the RT of the overload VPN routes. RT and RD can be used together to filter VPN routes when the source VRF contains multiple RTs, and the VPN routes with different RTs MAY be assigned to different VRFs on the receiver. If this TLV contains only one RT but multiple RTs are configured on the VPN route, the device should check whether the RT included in this TLV exists among the multiple RTs configured on the VPN route. If it exists, the device should filter out the VPN route. The Route Target TLV contains the following types: Type = 5, Length = 8*n (n is the number of RTs that the overload VPN routes attached) octets, value = the RT of the overload VPN routes. If multiple RTs are included, there MUST be an exact match. 5. The general procedures of VPN Prefix ORF mechanism 5.1. Process of VPN Prefix ORF mechanism on sender The operation of VPN Prefix ORF mechanism on each device is independent, each of them makes a local judgment to determine whether it needs to send a VPN Prefix ORF message to its upstream peer. Operators can configure the algorithms in the devices according to their own circumstances. This section describes the procedures for the receiving BGP peer to receive VPN route information from the sending BGP peer. The VPN information includes updated VPN routes and their corresponding VPN instance identification information. Based on the VPN instance identification information, the receiving BGP peer determines the newly added VPN routes. It then checks whether the number of newly added VPN routes has caused the total number of VPN routes to exceed the maximum route limit for the associated VPN instance. Wang, et al. Expires 27 June 2026 [Page 10] Internet-Draft RD-ORF December 2025 If the route limit of the VPN instance, which is identified by the VPN instance identification information, is reached or exceeded, the receiving BGP peer will send a VPN Prefix ORF message to the sending BGP peer, indicating that it should stop sending the corresponding VPN routes which are identified by the VPN instance identification information. Before originating a VPN Prefix ORF message, the device SHOULD compare the list of RTs carried by VPN routes with those imported by other VRFs on the device. If the route's RT is included in the import rules of other VRFs, the VPN Prefix ORF message MUST NOT be originated. Before sending a VPN Prefix ORF entry, a sender SHOULD send a "default" entry to the VPN Prefix ORF receiver, to allow other allowed VPN prefixes to pass the filter. The "default" entry should be installed in advance in the VPN Prefixes ORF table, with the overload VPN routes process method set to 0, sequence set to 0xFFFFFFFF, length set to 8, and Route Distinguisher set to 0. The receiving BGP peer and the sending BGP peer are iBGP peers within the same Autonomous System (AS). The VPN instance identification information is RD and the instruction information is sent using ORF in the ROUTE-REFRESH message. The instruction information sent from the receiving BGP peer includes the following information: * The ORF entries that are included in the ROUTE-REFRESH message. * The Action field in the ORF entries is set to a value that instructs the sending BGP peer to add the corresponding filter condition to its outbound route filter. * The Match field in the ORF entries is set to a value that instructs the sending BGP peer to deny VPN routes updates that match the corresponding ORF entries. * The RD value that identifies the above mentioned VPN instance is added to the type-specific part of the ORF entries. Wang, et al. Expires 27 June 2026 [Page 11] Internet-Draft RD-ORF December 2025 When multiple VRFs on a PE are receiving VPN routes with a specific RD, if one VRF exceeds its limit upon receiving routes with that RD, then the PE sends a VPN Prefix ORF message, which will prevent other VRFs that have not exceeded their limits from receiving VPN routes containing that RD, thereby avoiding any communication disruptions between these VRFs and the rejected VPN routes. In order to more finely control VPN routing, when not all VRFs on a PE that are interested in VPN routes with a specific RD exceed the limit, the PE MUST NOT send a VPN Prefix ORF entry. When the VPN Prefix ORF mechanism is triggered, the device SHOULD send an alarm information to network operators. The procedures for senders of VPN Prefix ORF entries are described below: S01. For each VRF v that receives updated VPN routes { S02. If (the total number of prefixes in VRF v exceeds its configured prefix limit) { S03. RT_set = the set of Route Targets imported by VRF v. S04. overload_RD_source_pairs = all tuples from the newly received routes that belong to VRF v. // Check if any RT in RT_set is also imported by another VRF that has NOT exceeded its limit S05. conflict_exists = FALSE; S06. For each RT r in RT_set { S07. For each other VRF u on this device { S08. If (r is in the import RT list of VRF u) AND (prefix count of VRF u <= its prefix limit) { S09. conflict_exists = TRUE; S10. } S11. } S12. } S13. If (conflict_exists == TRUE) { S14. // Cannot send ORF: would block routes needed by healthy VRFs S15. Send warning message to the operator. S16. } S17. // Safe to send ORF entries S18. For each in overload_RD_source_pairs { S19. Collect all RTs carried by routes with RD=RD_x from source PE_y that are imported into VRF v ? RT_list. Wang, et al. Expires 27 June 2026 [Page 12] Internet-Draft RD-ORF December 2025 S20. Construct a VPN Prefix ORF entry with: S21. Action = ADD, S22. Match = DENY, S23. Overload VPN routes process method = 0, S24. Sequence = generate unique sequence number, S25. Route Distinguisher = RD_x, S26. Optional TLVs include: S27. Source PE TLV = PE_y, S28. Route Target TLV = RT_list. S29. Send a BGP ROUTE-REFRESH message containing this ORF entry to the upstream BGP peer (e.g., RR). S30. Send an alarm message to the operator indicating VRF v overflow and ORF transmission. S31. } S32. } Else { S33. // No overflow in this VRF; no ORF triggered S34. Continue normal route processing. S35. } S36. } 5.1.1. Intra-domain Scenarios and Solutions For intra-AS VPN deployment, there are two scenarios: * unique RD (per VPN, per PE). * the same RD (per VPN, same on all PEs) The detailed descriptions about the above solutions are in Appendix B. 5.2. Protocol process of VPN Prefix ORF mechanism on receiver The VPN Prefix ORF is used mainly to block the unwanted BGP updates. When the receiver receives VPN Prefix ORF entry, it MUST check first whether the "Match" bit is "DENY" or not. If the "Match" bit is "PERMIT", and is the "default" entry (the overload VPN routes process method equal to 0, sequence equal to 0xFFFFFFFF, length is equal to 8, and Route Distinguisher is equal to 0), the entry SHOULD be installed. Otherwise, if the "Match" bit is "PERMIT", the entry MUST be discarded and a warning MUST be sent to the operator. The following procedures will only be evaluated when the "Match" bit is "DENY". Wang, et al. Expires 27 June 2026 [Page 13] Internet-Draft RD-ORF December 2025 The receiver of VPN Prefix ORF entries, which may be a RR, ASBR or PE, when receives VPN Prefix ORF entry from its BGP peer, it does the following: S01. The receiver checks the combination of of the received VPN Prefix ORF entry. S02. If (the combination does not already exist in the ORF-Policy table) { S03. The receiver adds the VPN Prefix ORF entry to the ORF-Policy table. S04. } else if (Action is ADD) { S05. Overwrite the old VPN Prefix ORF entry with the new one. S06. } else if (Action is REMOVE) { S07. The corresponding VPN Prefix ORF entries should be removed from the ORF-Policy table. S07. } else { Remove all VPN Prefix ORF entries SHOULD be removed from the ORF-Policy table. S08. } The filtering conditions for the stored VPN Prefix ORF entries contain the RD and RT of the source PE. If the SPE EC is not attached to the BGP Update message of the VPN prefixes, the receiver MUST use NEXT_HOP or ORIGINATOR_ID as the originator of VPN Prefix to match against the VPN Prefix ORF entry. After installing the filter entries for the outbound VPN prefixes, the RR or ASBR does the following before sending VPN routes: Wang, et al. Expires 27 June 2026 [Page 14] Internet-Draft RD-ORF December 2025 S01. RR or ASBR check if there are matching filtering conditions in the ORF-Policy table for the VPN routes. S02. If (matching filtering conditions does not exist) { S03. The RR/ASBR sends the VPN routes. S04. } else { S05. If (the "Overload VPN routes process method" bit is set to 0) { S06. The RR/ASBR withdraws all the VPN routes identified by RD, RT and any relevant information in the optional TLVs within the entry, and stop sending the corresponding VPN routes to the sender of the VPN Prefix ORF entry. S07. } else { S08. The receiver withdraws the extra VPN routes according to the value of RD, RT and any relevant information in optional TLVs within the entry, and stop sending the corresponding VPN routes to the sender of the VPN Prefix ORF entry. S09. } The procedure above can be used for route refresh processing after getting the ORF update and the usual VPN route propagation. A change to the ORF prefixes will trigger a re-scan of the relevant routing information, followed by a route refresh; in contrast, regular individual VPN route updates are subject only to matching against the existing ORF rules. 6. Source PE Extended Community Next hop does not always identify the source as in the following scenarios: * a PE MAY have multiple addresses so that its BGP peer MAY receive several different next hop addresses from the same source. * In Option B inter-domain scenario, the ASBR will change the next hop. ORIGINATOR_ID is a non-transitive attribute generated by RR to identify the source, but ORIGINATOR_ID cannot be advertised outside the local AS. To address the above scenarios, we have defined a new Extended Community: Source PE Extended Community (SPE EC), which is designed to transmit the identifier of source. The value of SPE EC can be set by source PE, RR or Autonomous System Boundary Router (ASBR). Once set and attached to the BGP UPDATE message, its value SHOULD NOT be altered along the advertisement path. Wang, et al. Expires 27 June 2026 [Page 15] Internet-Draft RD-ORF December 2025 The AS number of source PE can be conveyed by Source AS Extended Community, as defined in [RFC6514] The format of SPE EC is shown as Figure 4. 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 (TBD) | ORIGINATOR_ID : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ORIGINATOR_ID (cont.) | Reserved : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 The format of SPE EC Where: * Type: specifies the type value assigned by IANA, now it is TBD. * ORIGINATOR_ID: specifies the identifier of source. * Reserved: MUST be zero on transmit. For the RR/ASBR, it SHOULD perform the following: * Check the existence of the SPE EC. If it exists, does not change it. * If SPE EC does not exist, check the existence of ORIGINATOR_ID. If it exists, put it into SPE EC. * If ORIGINATOR_ID does not exist, put the router-id of source PE into SPE EC. This section extends route reflection behaviours, which means if someone wants this new feature extension, then the RR needs to do something additional as above. 7. Operational Considerations 7.1. Quota value calculation The VPN Prefix ORF mechanism is designed for intra-domain BGP/MPLS IP VPN [RFC4364] and BGP/MPLS Ethernet VPN (EVPN) [RFC7432] deployments where multiple VRFs on a Provider Edge (PE) router exchange VPN routes via a single shared iBGP session (typically with a Route Reflector). This mechanism operates in two modes: Wang, et al. Expires 27 June 2026 [Page 16] Internet-Draft RD-ORF December 2025 * Basic mode: Triggered solely by VRF-level prefix limits. No per- source quota configuration is required. In this mode, the PE sends a VPN Prefix ORF only when all VRFs that import the same Route Target(s) have exceeded their respective prefix limits. * Granular mode (optional): Enabled when operators configure per- quotas via their Network Management System (NMS) or CLI. This allows finer-grained control, enabling ORF triggering even if only one VRF exceeds its limit while others sharing the same RT remain healthy—provided the offending routes originate from a specific source. Quota is a threshold to limit the number of VPN routes under specific granularities (such as , ). In deployment, quota values SHOULD be set and delivered by the Network Management System (NMS). When the granular mode is enabled, an operator may configure a quota for each tuple imported into a VRF. This quota represents the maximum number of prefixes allowed from that specific source for the given RD. The quota value can be derived based on historical traffic patterns, service level agreements (SLAs), or static provisioning via NMS/CLI. It is not a prerequisite for the VPN Prefix ORF mechanism to operate; the mechanism defaults to VRF-level prefix limit enforcement if no per-source quotas are configured. If the quota value is set to (VRF prefix limit/the number of PEs), whenever a new PE access to the network, the quota value SHOULD be re-evaluated or adjusted accordingly. To avoid frequent changes to the quota value, the value SHOULD be set based on the following formula: Quota=MIN[(Margins coefficient)**, VRF Prefixes Limit] It SHOULD be noted that the above formula is only an example, the operators can use different formulas based on actual needs in management plane. Wang, et al. Expires 27 June 2026 [Page 17] Internet-Draft RD-ORF December 2025 7.2. Withdraw of VPN Prefix ORF entries When the VPN Prefix ORF mechanism is triggered, a warning message will be generated and sent to the network operators. Operators SHOULD manually configure the network to resume normal operation. Since devices can record the VPN Prefix ORF entries sent by each VRF, operators can identify the entries that need to be withdrawn and manually trigger the withdraw process. The withdrawal of the VPN Prefix ORF mechanism is manually triggered, and its activation requires two conditions: 1. Network operation and maintenance personnel have confirmed through device alarms that the issue of "overload routes", which originally caused the VRF route count to exceed the limit --- has been resolved; 2. Operation and maintenance personnel have located the target ORF entry to be withdrawn. Devices record the VPN Prefix ORF entries sent by each VRF, providing a basis for personnel to locate the target of the withdrawal. Operation and maintenance personnel manually configure withdrawal commands on the device that triggered the ORF (typically the original ORF sender, such as a PE with an exceeded route limit). The commands MUST include the unique identification information of the target ORF entry, and set the "Action" field of the ORF entry to "REMOVE" (for removing a single entry) or "REMOVE-ALL" (for removing all entries of the same type). The withdrawal of ORF entries relies on manual intervention from a management entity (e.g., NMS), and there is no automatic withdrawal mechanism. This is to prevent route disruptions caused by misoperations. 8. Security Considerations This draft adds no new security considerations beyond those of [RFC5291]. 9. IANA Considerations 9.1. VPN Prefix Outbound Route Filter This document defines a new Outbound Route Filter type - VPN Prefix Outbound Route Filter (VPN Prefix ORF). This new ORF type SHOULD be registered under "BGP Outbound Route Filtering (ORF) Types", value 66 has been allocated to this new ORF type by IANA. Wang, et al. Expires 27 June 2026 [Page 18] Internet-Draft RD-ORF December 2025 under "BGP Outbound Route Filtering (ORF) Types" Registry: "VPN Prefix Outbound Route Filter (VPN Prefix ORF)" Registration Procedure(s): First Come, First Served 9.2. VPN Prefix ORF TLV types This document define a VPN Prefix ORF TLV type under "Border Gateway Protocol (BGP) Parameters", four TLV types are defined: under "Border Gateway Protocol (BGP) Parameters" Registry: "VPN Prefix ORF TLV" +==========+=========================+ | Range | Registration Procedures | +====================================+ | 0-127 | IETF Review | +----------+-------------------------+ | 128-255 | First Come First Served | +----------+-------------------------+ +=====================+=============+===========================+ | Registry | Type | Meaning | +=====================+=============+===========================+ |Reserved | 0(suggested)|Reserved | +---------------------+-------------+---------------------------+ |IPv4 Source PE TLV | 1(suggested)|IPv4 address for source PE.| +---------------------+-------------+---------------------------+ |IPv6 Source PE TLV | 2(suggested)|IPv6 address for source PE.| +---------------------+-------------+---------------------------+ |Source PE Identifier | 3(suggested)|ORIGINATOR_ID in Source PE | |TLV | |Extended Community for | | | |source PE | +---------------------+-------------+---------------------------+ |Source AS TLV | 4(suggested)|Source AS for source PE | +---------------------+-------------+---------------------------+ |Route Target TLV | 5(suggested)|Route Target of the | | | |overload VPN routes | +---------------------+-------------+---------------------------+ 9.3. Source PE Extended Community This document also requests a new Transitive Extended Community Type. The new Transitive Extended Community Type name SHALL be "Source PE Extended Community". Wang, et al. Expires 27 June 2026 [Page 19] Internet-Draft RD-ORF December 2025 Under "BGP Transitive Extended Community Types:" Registry: "Source PE Extended Community" type 0x0d(suggested) Source PE Extended Community 9.4. Commen part of ORF entry This document defines the encoding of the common part of ORF entries as follows: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | A |M|O|R|R|R|R| +-+-+-+-+-+-+-+-+ A (2 bits): specifies the Action of this entry. M (1 bit): specifies the Match method of this entry. O (1 bit): specifies the overload VPN routes process method. R (4 bits): reserved. 10. Contributor Shunwan Zhuang Huawei Technologies Huawei Building, No.156 Beiqing Rd. Beijing Beijing, 100095 China 11. Acknowledgement Thanks Jeffrey Haas, Robert Raszuk, Jim Uttaro, Jakob Heitz, Jeff Tantsura, Rajiv Asati, John E Drake, Gert Doering, Shuanglong Chen, Enke Chen, Srihari Sangli and Igor Malyushkin for their valuable comments on this draft. 12. 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, . Wang, et al. Expires 27 June 2026 [Page 20] Internet-Draft RD-ORF December 2025 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, . [RFC4486] Chen, E. and V. Gillet, "Subcodes for BGP Cease Notification Message", RFC 4486, DOI 10.17487/RFC4486, April 2006, . [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, November 2006, . [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291, August 2008, . [RFC5292] Chen, E. and S. Sangli, "Address-Prefix-Based Outbound Route Filter for BGP-4", RFC 5292, DOI 10.17487/RFC5292, August 2008, . [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, . [RFC7024] Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter, Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS VPNs", RFC 7024, DOI 10.17487/RFC7024, October 2013, . Wang, et al. Expires 27 June 2026 [Page 21] Internet-Draft RD-ORF December 2025 [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, . [RFC7543] Jeng, H., Jalil, L., Bonica, R., Patel, K., and L. Yong, "Covering Prefixes Outbound Route Filter for BGP-4", RFC 7543, DOI 10.17487/RFC7543, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Appendix A. Experimental topology The experimental topology is shown in Figure 6. +------------------------+ +------------------------+ | | | | | | | | | +---------+ | | +---------+ | | | PE1 | | | | PE3 | | | +---------+ | | +---------+ | | \ | | / | | \+---------+ EBGP +---------+/ | | | | | | | | | ASBR1 |-----------| ASBR2 | | | | | | | | | +---------+ +---------+ | | / | | \ | | +---------+/ | | \+---------+ | | | PE2 | | | | PE4 | | | +---------+ | | +---------+ | | | | | | AS1 | | AS2 | +------------------------+ +------------------------+ Figure 6 The experimental topology This topology can be used to verify as follows: * whether the VPN Prefix ORF mechanism could block the overload routes in intra-domain scenario. * whether the VPN Prefix ORF mechanism conflicts with the existing mechanism and cause failure. * whether the quota value leads to flapping. Wang, et al. Expires 27 June 2026 [Page 22] Internet-Draft RD-ORF December 2025 Since all existing standards defining new ORF types are under the standard track, the authors of this draft would like to inquire whether this document can be reclassified into the standard track. Appendix B. Intra-domain Scenarios and Solutions B.1. Scenario 1: unique RD (per VPN, per PE) In this scenario, PE1-PE4 and RR are iBGP peers. RD is allocated per VPN per PE. The overload VPN routes only carry one RT. We assume that the network topology is shown in Figure 1. +----------------------------------------------------------------+ | +-------+ +-------+ | | | PE1 +----------------+ +-----------------+ PE4 | | | +-------+ | | +-------+ | | VPN1(RD11,RT1) | | VPN2(RD12,RT2) | | VPN2(RD12,RT2) | | | | +-+----+-+ | | | RR | | | +-+----+-+ | | | | | | | | | | +-------+ | | +-------+ | | | PE2 +----------------+ +-----------------+ PE3 | | | +-------+ +-------+ | | VPN1(RD21,RT1) VPN1(RD31,RT1) | | VPN2(RD22,RT2,RT1) VPN2(RD32,RT2) | | | | AS 100 | +----------------------------------------------------------------+ Figure 1 Network Topology of Scenario 1 When PE3 sends an excessive number of VPN routes with RT1, and both PE1 and PE2 import VPN routes with RT1, the process of overload VPN routes will influence performance of VRFs on PEs. PEs and RR need to have appropriate mechanisms to identify and control the advertising of offending VPN routes. a) PE1 If quota value is not set on PE1, and each VRF has a prefix limit on PE1. When the PE1 receives VPN routes from its BGP peer, it does the following: Wang, et al. Expires 27 June 2026 [Page 23] Internet-Draft RD-ORF December 2025 S01. If (the prefix limit for VPN1 VRF is exceeded){ S02. PE1 sends a VPN Prefix ORF message to the RR and a warning message to the operator. The VPN Prefix ORF message will carry the RD is set to RD31, the RT value is set to RT1, the source PE is PE3. RR handles the offending VPN routes and controls the number of VPN routes according to the value of "Offending VPN routes process method". S03. } else { S04. PE1 cannot trigger the VPN Prefix ORF mechanism, and only performs VPN route filtering for the target VRF. S05. } NOTE: When the prefix limit for VPN1 VRF is exceeded, there are no other VRFs on PE1 that need the VPN routes with RT1. PE1 sends a VPN Prefix ORF message to the RR and a warning message to the operator. If each tuple imported into a VRF has a quota, and each VRF has a prefix limit. When the PE1 receives VPN routes from its BGP peer, it does the following: S01. If (VPN routes associated with tuple exceed the quota) { S02. If (the prefix limit of VPN1 VRF is not exceeded) { S03. PE1 sends a warning message to the operator, and the VPN Prefix ORF mechanism cannot be triggered. S04. } else { S05. PE1 generates a BGP ROUTE-REFRESH message containing a VPN Prefix ORF entry with (RD31, source PE is PE3, RT is RT1), and send the entry to RR. RR handles the overload VPN routes according to the value of "Overload VPN routes process method". S06. } S07. } b) PE2 If quota value is not set on PE2, and each VRF has a prefix limit on PE2. When the PE2 receives VPN routes from its BGP peer, it does the following: Wang, et al. Expires 27 June 2026 [Page 24] Internet-Draft RD-ORF December 2025 S01. If (the prefix limit for VPN1 VRF is exceeded) { S02. If (the prefix limit for VPN2 VRF is exceeded) { S03. PE2 sends a VPN Prefix ORF message to the RR and a warning message to the operator. The VPN Prefix ORF message will indicate the RD set to RD31, the RT value set to RT1. RR handles the overload VPN routes and controls the number of VPN routes according to the value of "Overload VPN routes process method". S04. } else { S05. PE2 cannot trigger the VPN Prefix ORF mechanism, and only performs VPN route filtering for the target VRF. S06. } S07. } NOTE: PE2 cannot directly trigger the VPN Prefix ORF mechanism when the prefix limit of VPN1 VRF is exceeded, because VPN2 VRF requires the VPN routes with RT1. PE2 triggers the mechanism only when the prefix limits for both the VPN1 and VPN2 VRFs have been exceeded. If each tuple imported into a VRF has a quota, and each VRF has a prefix limit. When the PE2 receives VPN routes from its BGP peer, it does the following: S01. If (VPN routes associated with tuple exceed the quota) { S02. If (the prefix limit of VPN1 VRF is not exceeded) { S03. PE2 sends a warning message to the operator, and the VPN Prefix ORF mechanism cannot be triggered. S04. } else { S05. If (the prefix limit of VPN2 VRF is not exceeded) { S06. PE2 cannot trigger the VPN Prefix ORF mechanism, and only performs VPN route filtering for the target VPN1 VRF, stopping the import of VPN routes with . S07. } else { S08. PE2 generates a BGP ROUTE-REFRESH message containing a VPN Prefix ORF entry with (RD31, source PE is PE3, RTs are RT1 and RT2), and send the entry to RR. RR handles the overload VPN routes according to the value of "Overload VPN routes process method". S09. } S10. } S11. } Wang, et al. Expires 27 June 2026 [Page 25] Internet-Draft RD-ORF December 2025 B.2. Scenario 2: the same RD (per VPN, same on all PEs) In this scenario, PE1-PE4 and RR are iBGP peers. RD is allocated per VPN. One/Multiple RTs are associated with the offending VPN routes and are imported into different VRFs on other devices. We assume the network topology is shown in Figure 2. +----------------------------------------------------------------+ | | | | | +-------+ +-------+ | | | PE1 +----------------+ +-----------------+ PE4 | | | +-------+ | | +-------+ | | VPN1(RD1,RT1) | | VPN2(RD12,RT2) | | VPN2(RD12,RT2) | | | | +-+----+-+ | | | RR | | | +-+----+-+ | | | | | | | | | | +-------+ | | +-------+ | | | PE2 +----------------+ +-----------------+ PE3 | | | +-------+ +-------+ | | VPN1(RD1,RT1) VPN1(RD1,RT1,RT2) | | VPN2(RD32,RT2) | | | | AS 100 | | | +----------------------------------------------------------------+ Figure 2 Network Topology of Scenario 2 When PE3 sends an excessive number of VPN routes associated with RD1, RT1 and RT2, and both PE1 and PE2 import VPN routes with RT1, the process of overload VPN routes can affect the performance of the VRFs on PEs. a) PE1 If quota value is not set on PE1, and each VRF has a prefix limit on PE1. Since VPN2 VRF requires the VPN routes with RT2, PE1 cannot trigger VPN Prefix ORF mechanism directly when the prefix limit of VPN1 VRF is exceeded. This case is similar to PE2 without quota in Scenario 1, which is modified as follows: Wang, et al. Expires 27 June 2026 [Page 26] Internet-Draft RD-ORF December 2025 S03. PE1 sends a VPN Prefix ORF message to the RR and a warning message to the operator. The VPN Prefix ORF message will indicate the RD set to RD1, the RT value set to RT1 and RT2, source PE identified as PE3. RR handles the offending VPN routes and controls the number of VPN routes according to the value of "Overload VPN routes process method". If each tuple imported into a VRF has a quota, and each VRF has a prefix limit. This case is similar to PE2 with quota in Scenario 1, which is modified as follows: S08. PE1 generates a BGP ROUTE-REFRESH message containing a VPN Prefix ORF entry with (RD1, source PE is PE3, RTs are RT1 and RT2), and send the entry to RR. RR handles the overload VPN routes according to the value of "Overload VPN routes process method". b) PE2 If quota value is not set on PE2, and each VRF has a prefix limit on PE2. Since only VPN1 VRF needs to import VPN routes with RT1, this case is similar to PE1 without quota in Scenario 1, which is modified as follows: S02. PE2 sends a VPN Prefix ORF message to the RR and a warning message to the operator. The VPN Prefix ORF message will indicate the RD set to RD1, the RT value set to RT1 and RT2, source PE identified as PE3. RR handles the offending VPN routes and controls the number of VPN routes according to the value of "Overload VPN routes process method". If each tuple imported into a VRF has a quota, and each VRF has a prefix limit. This case is similar to PE1 with quota in Scenario 1, which is modified as follows: S05. PE2 generates a BGP ROUTE-REFRESH message containing a VPN Prefix ORF entry with (RD1, source PE is PE3, RTs are RT1 and RT2), and send the entry to RR. RR handles the offending VPN routes according to the value of "Overload VPN routes process method". Wang, et al. Expires 27 June 2026 [Page 27] Internet-Draft RD-ORF December 2025 Appendix C. Applicability Using the scenario 1 in Appendix B, we demonstrate how to determine each field when the sender generates a VPN Prefix ORF entry. Assuming it is an IPv4 network, after PE1-PE4 and RR have advertised the Outbound Route Filtering Capability, each of PE1-PE4 needs to send a VPN Prefix ORF entry that means "PERMIT-ALL" as follows: * AFI is equal to IPv4 * SAFI is equal to MPLS-labeled VPN address * When-to-refresh is equal to IMMEDIATE * ORF Type is equal to VPN Prefix ORF * Length of ORF entries is equal to 22 * Action is equal to ADD * Match is equal to PERMIT * Overload VPN routes process method is equal to 0 * Sequence is equal to 0xFFFFFFFF * Length is equal to 8 * Route Distinguisher is equal to 0 When the VPN Prefix ORF mechanism is triggered on PE1, PE1 generates a VPN Prefix ORF entry contains the following information: * AFI is equal to IPv4 * SAFI is equal to MPLS-labeled VPN address * When-to-refresh is equal to IMMEDIATE * ORF Type is equal to VPN Prefix ORF * Length of ORF entries is equal to 45 * Action is equal to ADD * Match is equal to DENY Wang, et al. Expires 27 June 2026 [Page 28] Internet-Draft RD-ORF December 2025 * Overload VPN routes process method is equal to 0 * Sequence is equal to 1 * Length is equal to 31 * Route Distinguisher is equal to RD31 * Optional TLV: - Type is equal to 1 (Source PE TLV) - Length is equal to 4 - value is equal to PE3's IPv4 address - Type is equal to 4 (Source AS TLV) - Length is equal to 4 - value is equal to PE3's source AS number - Type is equal to 5 (Route Target TLV) - Length is equal to 8 - value is equal to RT1 Authors' Addresses Wei Wang China Telecom Beiqijia Town, Changping District Beijing Beijing, 102209 China Email: weiwang94@foxmail.com Aijun Wang China Telecom Beiqijia Town, Changping District Beijing Beijing, 102209 China Email: wangaj3@chinatelecom.cn Wang, et al. Expires 27 June 2026 [Page 29] Internet-Draft RD-ORF December 2025 Haibo Wang Huawei Technologies Huawei Building, No.156 Beiqing Rd. Beijing Beijing, 100095 China Email: rainsword.wang@huawei.com Gyan S. Mishra Verizon Inc. 13101 Columbia Pike Silver Spring, MD 20904 United States of America Email: gyan.s.mishra@verizon.com Jie Dong Huawei Technologies Huawei Building, No.156 Beiqing Rd. Beijing Beijing, 100095 China Email: jie.dong@huawei.com Wang, et al. Expires 27 June 2026 [Page 30]