IDR Working Group W. Wang Internet-Draft A. Wang Intended status: Experimental China Telecom Expires: 27 March 2025 H. Wang Huawei Technologies G. Mishra Verizon Inc. J. Dong Huawei Technologies 23 September 2024 VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4 draft-ietf-idr-vpn-prefix-orf-08 Abstract This draft defines a new type of Outbound Route Filter (ORF), known as the VPN Prefix ORF. The VPN Prefix ORF mechanism is applicable when VPN routes from different VRFs are exchanged through a single shared BGP session. 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 March 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights Wang, et al. Expires 27 March 2025 [Page 1] Internet-Draft RD-ORF September 2024 and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. The general procedures of VPN Prefix ORF mechanism on sender . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Intra-domain Scenarios and Solutions . . . . . . . . . . 7 4.1.1. Scenario-1 and Solution (Unique RD, One RT) . . . . . 7 4.1.2. Scenario-2 and Solution (Unique RD, Multiple RTs) . . 10 4.1.3. Scenario-3 and Solution (Universal RD) . . . . . . . 12 5. Source PE Extended Community . . . . . . . . . . . . . . . . 14 6. VPN Prefix ORF Encoding . . . . . . . . . . . . . . . . . . . 15 6.1. Source PE TLV . . . . . . . . . . . . . . . . . . . . . . 18 6.2. Source AS TLV . . . . . . . . . . . . . . . . . . . . . . 18 6.3. Route Target TLV . . . . . . . . . . . . . . . . . . . . 18 7. Operation process of VPN Prefix ORF mechanism on receiver . . 19 8. Withdraw of VPN Prefix ORF entries . . . . . . . . . . . . . 20 9. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 20 10. Implementation Considerations . . . . . . . . . . . . . . . . 21 10.1. Implementation Considerations . . . . . . . . . . . . . 22 10.2. Implementation status . . . . . . . . . . . . . . . . . 22 10.3. Experimental topology . . . . . . . . . . . . . . . . . 23 11. Security Considerations . . . . . . . . . . . . . . . . . . . 23 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 13. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 24 14. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 24 15. Normative References . . . . . . . . . . . . . . . . . . . . 25 Appendix A. Experimental topology . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 1. Introduction [I-D.wang-idr-vpn-routes-control-analysis] analyzes the scenarios and requirements for controlling VPN routes within a shared BGP session. Furthermore, this draft examines the existing solutions and their limitations pertaining to these scenarios and proposes a new VPN Prefix ORF solution to meet the requirements as described in section 8 of [I-D.wang-idr-vpn-routes-control-analysis]. Now, there are several solutions can be used to alleviate these problem: Wang, et al. Expires 27 March 2025 [Page 2] Internet-Draft RD-ORF September 2024 * Route Target Constraint (RTC) as defined in [RFC4684] * Address Prefix ORF as defined in [RFC5292] * CP-ORF mechanism as defined in [RFC7543] * PE-CE edge peer Maximum Prefix * Configure the Maximum Prefix for each VRF on edge nodes However, there are limitations to existing solutions: 1) Route Target Constraint RTC can only filter the VPN routes from the uninterested VRFs, if the “offending routes” come from the interested VRF, RTC mechanism can't filter them. 2) Address Prefix ORF Using Address Prefix ORF to filter VPN routes requires pre- configuration, but it is impossible to know in advance which prefix may exceed the predefined threshold. 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 the BGP/MPLS Ethernet VPN (EVPN)[RFC7432] networks, but its main aim is also to get the wanted VPN prefixes and can't be used to filter the overwhelmed VPN prefixes dynamically. 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 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 BGP session will be shut down, which will effect the operation of other VPN routes transmitted via this BGP session. Wang, et al. Expires 27 March 2025 [Page 3] Internet-Draft RD-ORF September 2024 5) Configure the Maximum Prefix for each VRF on edge nodes When a VRF overflows, it stops the import of routes and log the extra VPN routes into its RIB. However, PEs still need to parse the BGP updates. These processes will cost CPU cycles and further burden the overflowed PE. This draft defines a new type of Outbound Route Filter (ORF), called the VPN Prefix ORF. This 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 (RD, RT, source PE, etc.) of the offending VPN routes in this VRF and send a VPN Prefix ORF message to its BGP peer, which contains the relevant information. If a BGP speaker receives a VPN Prefix ORF entry from its BGP peer, it will filter the VPN routes it intends to send according to the entry. The purpose of this mechanism is to control the outage within the minimum range and avoid route churn effects when a VRF on a device in the network overflows. VPN Prefix ORF is applicable when the VPN routes from different VRFs are exchanged via one shared BGP session. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] . 3. Terminology The following terms are used in this draft: * RD: Route Distinguisher, defined in [RFC4364] * ORF: Outbound Route Filter, defined in [RFC5291] * AFI: Address Family Identifier, defined in [RFC4760] * SAFI: Subsequent Address Family Identifier, defined in [RFC4760] * EVPN: BGP/MPLS Ethernet VPN, defined in [RFC7432] * RR: Router Reflector, provides a simple solution to the problem of IBGP full mesh connection in large-scale IBGP implementation. Wang, et al. Expires 27 March 2025 [Page 4] Internet-Draft RD-ORF September 2024 * VRF: Virtual Routing Forwarding, a virtual routing table based on VPN instance. 4. The general procedures 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 the 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 the newly added VPN routes has caused the number of total VPN routes to exceed the maximum route limit for the associated VPN instance. If the route number of the VPN instance, which is identified by the VPN instance identification information, is reached or exceeds its limit, it will send the instruction information to the sending BGP peer, indicating that the sending BGP peer stop sending the corresponding VPN routes which are identified by the VPN instance identification information. The receiving BGP peer and the sending BGP peer are iBGP peers within the same AS. The VPN instance identification information is RD and the instruction information is sent through the ROUTE-REFRESH message. The instruction information that sends from the receiving BGP peer includes the followings information: * The ORF entries that are included in the route-refresh message. * Set the Action field in the ORF entries to the value that instructs adding the corresponding filter condition to the outbound route filter of the sending BGP peer. * Set the Match field in the ORF entries to the value that instructs denying the 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 March 2025 [Page 5] Internet-Draft RD-ORF September 2024 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, leading to 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. The detail procedures for further subdivisions are described below: a) No quota value is set on PE On PE, each VRF has a prefix limit. When the PE receives VPN routes from its BGP peer, PE does the following: S01. PE extracts the VPN route information from BGP UPDATE message, and determines the target VRFs for the received VPN routes based on the RT of the VPN route and the RT-import of VRFs. S02. If (a target VRF exceeds the limit which caused by VPN routes carry a certain RD) { S03. If (not all the other target VRFs have overflowed) { S04. PE should not trigger the VPN Prefix ORF mechanism, and only performs VPN route filtering for the target VRF, stopping the import of VPN routes carrying the specific RD. S05. } else { S06. PE should trigger the VPN Prefix ORF mechanism and send a BGP ROUTE-REFRESH message contains the corresponding VPN Prefix ORF entry to its peer. S07. } S08. } b) Quota value is set on PE On PE, each VRF has a prefix limit, and routes associated with each tuple have a pre-configured quota. When the PE receives VPN routes from its BGP peer, PE does the following: Wang, et al. Expires 27 March 2025 [Page 6] Internet-Draft RD-ORF September 2024 S01. PE extracts the VPN route information from BGP UPDATE message, and determines the target VRFs for the received VPN routes based on the RT of the VPN route and the RT-import of VRFs. S02. If (VPN routes associated with tuple exceed the quota) { S03. If (the prefix limit of VRF is not exceeded) { S04. PE may send a warning message to the operator, and the VPN Prefix ORF mechanism should not be triggered. S05. } else { S06. If (not all the other target VRFs have overflowed) { S07. PE should not trigger the VPN Prefix ORF mechanism, and only performs VPN route filtering for the target VRF, stopping the import of VPN routes carrying the specific RD. S08. else { S09. PE triggers the VPN Prefix ORF mechanism and send a BGP ROUTE-REFRESH message containing the corresponding VPN Prefix ORF entry to its peer. S10. } S11. } S12. } When the VPN Prefix ORF mechanism is triggered, the device SHOULD send an alarm information to network operators. 4.1. Intra-domain Scenarios and Solutions For intra-AS VPN deployment, there are three scenarios: * RD is allocated per VPN per PE, each VRF only import one RT (see Section 4.1.1). * RD is allocated per VPN per PE. Multiple RTs are associated with such VPN routes, and are imported into different VRFs in other devices(see Section 4.1.2). * RD is allocated per VPN, each VRF imports one/multiple RTs(see Section 4.1.3). The following sections will describe solutions to the above scenarios in detail. 4.1.1. Scenario-1 and Solution (Unique RD, One RT) In this scenario, PE1-PE4 and RR are iBGP peers. RD is allocated per VPN per PE. The offending VPN routes only carry one RT. We assume that the network topology is shown in Figure 1. Wang, et al. Expires 27 March 2025 [Page 7] Internet-Draft RD-ORF September 2024 +------------------------------------------------------------------------+ | | | | | +-------+ +-------+ | | | 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 offending VPN routes will influence performance of VRFs on PEs. PEs and RR should 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: 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 prefix limit of VPN1 VRF, with 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 should not trigger the VPN Prefix ORF mechanism, and only performs VPN route filtering for the target VRF. S05. } Wang, et al. Expires 27 March 2025 [Page 8] Internet-Draft RD-ORF September 2024 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 should not be triggered. S04. } else { S05. PE1 generates a BGP ROUTE-REFRESH message containing a VPN Prefix ORF entry with (RD31, the prefix limit of VPN1 VRF, source PE is PE3, RT is RT1), and send the entry to RR. RR handles the offending VPN routes according to the value of "Offending 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: 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 VRF Prefix Limit = min(prefix limit of VPN1 VRF, prefix limit of VPN2 VRF), with the RD set to RD31, the RT value set to RT1. RR handles the offending VPN routes and controls the number of VPN routes according to the value of "Offending VPN routes process method". S04. } else { S05. PE2 should not 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. Wang, et al. Expires 27 March 2025 [Page 9] Internet-Draft RD-ORF September 2024 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 should not be triggered. S04. } else { S05. If (the prefix limit of VPN2 VRF is not exceeded) { S06. PE2 should not 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, min(prefix limit of VPN1 VRF, prefix limit of VPN2 VRF), 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 "Offending VPN routes process method". S09. } S10. } S11. } 4.1.2. Scenario-2 and Solution (Unique RD, Multiple RTs) In this scenario, PE1-PE4 and RR are iBGP peers. RDs are allocated per VPN per PE. Multiple RTs are associated with the offending VPN routes and are imported into different VRFs on other devices. We assume the network topology is depicted in Figure 2. Wang, et al. Expires 27 March 2025 [Page 10] Internet-Draft RD-ORF September 2024 +------------------------------------------------------------------------+ | | | | | +-------+ +-------+ | | | PE1 +----------------+ +-----------------+ PE4 | | | +-------+ | | +-------+ | | VPN1(RD11,RT1) | | VPN2(RD42,RT2) | | VPN2(RD12,RT2) | | | | +-+----+-+ | | | RR | | | +-+----+-+ | | | | | | | | | | +-------+ | | +-------+ | | | PE2 +----------------+ +-----------------+ PE3 | | | +-------+ +-------+ | | VPN1(RD21,RT1) VPN1(RD31,RT1,RT2) | | VPN2(RD32,RT2) | | | | AS 100 | | | +------------------------------------------------------------------------+ Figure 2 Network Topology of Scenario-2 When PE3 sends an excessive number of VPN routes with RT1 and RT2, while both PE1 and PE2 import VPN routes with RT1, and PE1 also imports VPN routes with RT2. 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 RT1, PE1 cannot directly trigger VPN Prefix ORF mechanism when the prefix limit of VPN1 VRF is exceeded. This case is similar to PE2 without quota in Section 4.1.1, which is modified as follows: 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 VRF Prefix Limit = min(prefix limit of VPN1 VRF, prefix limit of VPN2 VRF), with the RD set to RD31, 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 "Offending VPN routes process method". Wang, et al. Expires 27 March 2025 [Page 11] Internet-Draft RD-ORF September 2024 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 Section 4.1.1, which is modified as follows: S08. PE1 generates a BGP ROUTE-REFRESH message containing a VPN Prefix ORF entry with (RD31, min(prefix limit of VPN1 VRF, prefix limit of VPN2 VRF), 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 "Offending 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 Section 4.1.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 VRF Prefix Limit = prefix limit of VPN1 VRF, with the RD set to RD31, 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 "Offending 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 Section 4.1.1, which is modified as follows: S05. PE2 generates a BGP ROUTE-REFRESH message containing a VPN Prefix ORF entry with (RD31, prefix limit of VPN1 VRF, 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 "Offending VPN routes process method". 4.1.3. Scenario-3 and Solution (Universal RD) 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 3. Wang, et al. Expires 27 March 2025 [Page 12] Internet-Draft RD-ORF September 2024 +------------------------------------------------------------------------+ | | | | | +-------+ +-------+ | | | 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 3 Network Topology of Scenario-3 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 offending 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 Section 4.1.1, which is modified as follows: 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 VRF Prefix Limit = min(prefix limit of VPN1 VRF, prefix limit of VPN2 VRF), with 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 "Offending VPN routes process method". Wang, et al. Expires 27 March 2025 [Page 13] Internet-Draft RD-ORF September 2024 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 Section 4.1.1, which is modified as follows: S08. PE1 generates a BGP ROUTE-REFRESH message containing a VPN Prefix ORF entry with (RD1, min(prefix limit of VPN1 VRF, prefix limit of VPN2 VRF), 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 "Offending 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 Section 4.1.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 VRF Prefix Limit = prefix limit of VPN1 VRF, with 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 "Offending 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 Section 4.1.1, which is modified as follows: S05. PE2 generates a BGP ROUTE-REFRESH message containing a VPN Prefix ORF entry with (RD1, prefix limit of VPN1 VRF, 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 "Offending VPN routes process method". 5. Source PE Extended Community We usually use next hop to identify the source, but it may not be useful 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. Wang, et al. Expires 27 March 2025 [Page 14] Internet-Draft RD-ORF September 2024 * 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 ASBR. Once set and attached to the BGP UPDATE message, its value should not be altered along the advertisement path. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x0d | ORIGINATOR_ID : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ORIGINATOR_ID (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 The format of SPE EC For the RR/ASBR, it should perform as 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. 6. VPN Prefix ORF Encoding In this section, we defined a new ORF type called VPN Prefix Outbound Route Filter (VPN Prefix ORF). The 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 ROUTE-REFRESH message which carries ORF entries contains the following fields: * AFI (2 octets) Wang, et al. Expires 27 March 2025 [Page 15] Internet-Draft RD-ORF September 2024 * SAFI (1 octet) * When-to-refresh (1 octet): the value is IMMEDIATE or DEFER * ORF Type (1 octet) * Length of ORF entries (2 octets) A VPN Prefix ORF entry contains a common part and type-specific part. The common part is encoded as follows: * Action (2 bits): the value is ADD, REMOVE or REMOVE-ALL * Match (1 bit): the value is PERMIT or DENY * Offending VPN routes process method (1 bit): if the value is set to 0, it means all offending 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 offending 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 March 2025 [Page 16] Internet-Draft RD-ORF September 2024 +-----------------------------------------+ | | | Sequence (4 octets) | | | +-----------------------------------------+ | | | Length (2 octets) | | | +-----------------------------------------+ | | | VRF Prefix Limit (4 octets) | | | +-----------------------------------------+ | | | Route Distinguisher (8 octets) | | | +-----------------------------------------+ | | | Optional TLVs (variable) | | | +-----------------------------------------+ Figure 5: VPN Prefix ORF type-specific encoding * Sequence: identifying the order in which RD-ORF is generated. * Length: identifying the length of this VPN Prefix ORF entry. * VRF Prefix Limit: carrying the prefix limt of the overflowed VRF. * 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. Note that if the Action component of an ORF entry specifies REMOVE- ALL, the ORF entry does not include the type-specific part. 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 AFI MUST be set to IPv4, IPv6, or Layer 2 VPN (L2VPN). Wang, et al. Expires 27 March 2025 [Page 17] Internet-Draft RD-ORF September 2024 * 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. * The Match field should be set to PERMIT when VRF Prefix Limit = 0xFFFF and RD=0; otherwise, the Match field should be set to DENY. 6.1. Source PE TLV 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. If it exists, the sender will put it into Source PE TLV. Otherwise, the value of Source PE TLV should be set to local AS number and next hop address. The source PE TLV contains the following types: * IPv4 Source PE TLV: Type = 1 (suggested), Length = 4 octets, value = next hop address in IPv4 format. * IPv6 Source PE TLV: Type = 2 (suggested), Length = 16 octets, value = next hop address in IPv6 format. * Source PE identifier TLV: Type = 3 (suggested), Length = 4 octets, value = the value of ORIGINATOR_ID in Source PE Extended Community. 6.2. Source AS TLV Source AS TLV is defined to identify the source AS number of source PE. The encoding of Source AS TLV is as follow: Type = 4 (suggested), Length = 4 octets, value = the value of Source AS in Source AS Extended Community as defined in [RFC6514]. 6.3. Route Target TLV Route Target TLV is defined to identify the RT of the offending 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. The Route Target TLV contains the following types: Wang, et al. Expires 27 March 2025 [Page 18] Internet-Draft RD-ORF September 2024 Type = 5 (suggested), Length = 8*n (n is the number of RTs that the offending VPN routes attached) octets, value = the RT of the offending VPN routes. If multiple RTs are included, there must be an exact match. 7. Operation process of VPN Prefix ORF mechanism on receiver The receiver of VPN Prefix ORF entries, which may be a Route Reflector (RR) or Provider Edge (PE), when receives VPN Prefix ORF entry from its BGP peer, it does the following: S01. The receiver check 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 { S05. The receiver discards the entry. S06. } The filtering conditions for the stored VPN Prefix ORF entries contain the RD and RT of the source PE. When all downstream devices send the VPN Prefix ORF entries with the same filtering condition to the receiver, the receiver SHOULD generate a VPN Prefix ORF entry that includes this filtering condition and send it to its upstream devices. After installing the filter entries for the outbound VPN prefixes, the RR or ASBR does the following before sending VPN routes: 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 "Offending 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. S06. } else { S07. The receiver withdraw the extra VPN routes according to the value of VRF Prefix Limit, 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. S06. } Wang, et al. Expires 27 March 2025 [Page 19] Internet-Draft RD-ORF September 2024 8. 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 are needed to be withdrawn and manually trigger the withdraw process as described in [RFC5291]. 9. Applicability Using the scenario in Section 4.1.1, 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 should 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 26 * Action is equal to ADD * Match is equal to PERMIT * Offending VPN routes process method is equal to 0 * Sequence is equal to 0xFFFFFFFF * Length is equal to 12 * VRF Prefix Limit is equal to 0xFFFF * 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 Wang, et al. Expires 27 March 2025 [Page 20] Internet-Draft RD-ORF September 2024 * When-to-refresh is equal to IMMEDIATE * ORF Type is equal to VPN Prefix ORF * Length of ORF entries is equal to 49 * Action is equal to ADD * Match is equal to DENY * Offending VPN routes process method is equal to 0 * Sequence is equal to 1 * Length is equal to 35 * VRF Prefix Limit is equal to the prefix limit of VPN1 VRF * 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 10. Implementation Considerations This draft is experimental to determine whether the proposed mechanism can block the offending routes as expected and whether it could cause potential network failures. The first subsection describes implementation considerations for the mechanism. The second subsection gives a brief description of implementation status. The third subsection provides a short summary of the experimental Wang, et al. Expires 27 March 2025 [Page 21] Internet-Draft RD-ORF September 2024 topology. 10.1. Implementation Considerations Before originating a VPN Prefix ORF message, the device should compare the list of RDs and RTs carried by VPN routes to those are imported by other VRFs on the device. If there is an intersection, the VPN Prefix ORF message MUST NOT be originated. In deployment, the quota value can be set with different granularity, such as by , , etc. 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. 10.2. Implementation status Currently, H3C has implemented VPN Prefix ORF mechanism related functions as follows: * By configuring VRF Prefix limit and quota, achieve the use of RD and Source PE to control VPN routing. * Generating, transmitting and processing Type 1 and Type 2 Source PE TLV. * Using the Offending VPN routes process method to revoke all routes. Besides, we also implemented the following functions based on the open-source BGP implementation (FRR): * VPN Prefix ORF mechanism triggered based on VRF limit in intra- domain and inter-domain scenarios. Wang, et al. Expires 27 March 2025 [Page 22] Internet-Draft RD-ORF September 2024 * RD based VPN routing filtering in intra-domain and inter-domain scenarios. 10.3. Experimental topology The experiments will test whether the VPN Prefix ORF blocks the offending routes in the following scenarios: * Intra-domain as a standalone mechanism, * Inter-domain as a standalone mechanisms, * Adding the VPN Prefix ORF to existing mechanisms for intra-domain VPNs, * Adding the VPN Prefix ORF to existing mechanisms for intra-domain VPNs. 11. Security Considerations This draft does build upon [RFC5291]. A BGP speaker will maintain the VPN Prefix ORF entries in an ORF-Policy table, this behavior consumes its memory and compute resources. To avoid the excessive consumption of resources, [RFC5291] specifies that a BGP speaker can only accept ORF entries transmitted by its interested peers. 12. IANA Considerations This document defines a new Outbound Route Filter type - VPN Prefix Outbound Route Filter (VPN Prefix ORF). under "BGP Outbound Route Filtering (ORF) Types" Registry: "VPN Prefix Outbound Route Filter (VPN Prefix ORF)" Registration Procedure(s): First Come, First Served Value: 66 This document also define a VPN Prefix ORF TLV type under "Border Gateway Protocol (BGP) Parameters", four TLV types are defined: Wang, et al. Expires 27 March 2025 [Page 23] Internet-Draft RD-ORF September 2024 under "Border Gateway Protocol (BGP) Parameters" Registry: "VPN Prefix ORF TLV" Registration Procedure(s): IETF Review Value range:0-255, value 0 is reserved. +===========================+=============+===========================+ | Registry | Type | Meaning | +===========================+=============+===========================+ |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 TLV | 3(suggested)|ORIGINATOR_ID in Source PE | | | |Extended Community for | | | |source PE | +---------------------------+-------------+---------------------------+ |Source AS TLV | 4(suggested)|Source AS for source PE | +---------------------------+-------------+---------------------------+ |Route Target TLV | 5(suggested)|Route Target of the | | | |offending VPN routes | +---------------------------+-------------+---------------------------+ This document also requests a new Transitive Extended Community Type. The new Transitive Extended Community Type name shall be "Source PE Extended Community". Under "BGP Transitive Extended Community Types:" Registry: "Source PE Extended Community" type 0x0d(suggested) Source PE Extended Community 13. Contributor Shunwan Zhuang Huawei Technologies Huawei Building, No.156 Beiqing Rd. Beijing Beijing, 100095 China 14. Acknowledgement Thanks 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. Wang, et al. Expires 27 March 2025 [Page 24] Internet-Draft RD-ORF September 2024 15. Normative References [I-D.ietf-bess-evpn-inter-subnet-forwarding] Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. Rabadan, "Integrated Routing and Bridging in Ethernet VPN (EVPN)", Work in Progress, Internet-Draft, draft-ietf- bess-evpn-inter-subnet-forwarding-15, 26 July 2021, . [I-D.wang-idr-vpn-routes-control-analysis] Wang, A., Wang, W., Mishra, G. S., Wang, H., Zhuang, S., and J. Dong, "Analysis of VPN Routes Control in Shared BGP Session", Work in Progress, Internet-Draft, draft-wang- idr-vpn-routes-control-analysis-04, 6 September 2021, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 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, . Wang, et al. Expires 27 March 2025 [Page 25] Internet-Draft RD-ORF September 2024 [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, . [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, . 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 Wang, et al. Expires 27 March 2025 [Page 26] Internet-Draft RD-ORF September 2024 This topology can be used to verify as follows: * whether the VPN Prefix ORF mechanism could block the offending routes in intra-domain scenario. * whether the VPN Prefix ORF mechanism could block the offending routes in inter-domain scenario. * whether the VPN Prefix ORF mechanism conflicts with the existing mechanism and cause failure. * whether the quota value leads to flapping. * TBD 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 Haibo Wang Huawei Technologies Huawei Building, No.156 Beiqing Rd. Beijing Beijing, 100095 China Email: rainsword.wang@huawei.com Wang, et al. Expires 27 March 2025 [Page 27] Internet-Draft RD-ORF September 2024 Gyan S. Mishra Verizon Inc. 13101 Columbia Pike Silver Spring, MD 20904 United States of America Phone: 301 502-1347 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 March 2025 [Page 28]