]> China Telecom

Beiqijia Town, Changping District Beijing Beijing 102209 China weiwang94@foxmail.com

China Telecom

Beiqijia Town, Changping District Beijing Beijing 102209 China wangaj3@chinatelecom.cn

Huawei Technologies

Huawei Building, No.156 Beiqing Rd. Beijing Beijing 100095 China rainsword.wang@huawei.com

Verizon Inc.

13101 Columbia Pike Silver Spring MD 20904 United States of America hayabusagsm@gmail.com

Huawei Technologies

Huawei Building, No.156 Beiqing Rd. Beijing Beijing 100095 China jie.dong@huawei.com

RTG Area IDR Working Group RFC This document 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 the VPN Prefix ORF mechanism is to control the overload of VPN routes based on Route Distinguisher (RD), Route Target (RT) and other necessary routing information. This mechanism is applicable to intra-domain scenarios.

The BGP Maximum Prefix feature is often used at the network boundary to control the number of prefixes injected into the network. However, in scenarios where VPN routes from multiple VRFs are advertised over a shared BGP session, there is a lack of appropriate methods to control route flooding within one VRF. This flooding can overwhelm the processing of VPN routes in other VRFs, consequently degrading their performance (e.g., causing route drops, processing delays, and abnormal customer services). Therefore, it is desirable to control excessive VPN route advertisements individually for each VRF within such a shared BGP session. Several solutions can be used to alleviate this problem: Route Target Constraint (RTC) as defined in Address Prefix ORF as defined in Covering Prefixes Outbound Route Filter (CP-ORF) mechanism as defined in 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 3. This document propose 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 identifies the VPN prefix (Route Distinguisher (RD), Route Target (RT), source PE, etc.) of the overload VPN routes (VPN routes that exceed the maximum number of storable VPN routes of the corresponding VRF on the receiver and thus cannot be imported.) and sends a VPN Prefix ORF message to the BGP peer that announced these overload VPN routes. Upon receiving a VPN Prefix ORF entry, the BGP speaker filters and withdraws any overload VPN routes that were previously announced to its peer. The purpose of this mechanism is to control the overload VPN routes, avoid route churn effects and resource exhaustion when a VRF overloads. The VPN Prefix ORF mechanism is applicable when VPN routes from different VRFs are exchanged via a shared BGP session.

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 when, and only when, they appear in all capitals, as shown here.

The following terms are used in This document: AFI: Address Family Identifier, defined in ASBR: Autonomous System Border Router BGP: Border Gateway Protocol, defined in EVPN: BGP/MPLS Ethernet VPN, defined in MPLS: Multi-Protocol Label Switching ORF: Outbound Route Filter, defined in Quota: A threshold to limit the number of VPN routes under specific granularities (such as <PE>, <RD, Source AS>) RD: Route Distinguisher, defined in RIB: Routing Information Base RR: Route Reflector, provides a simple solution to the problem of Internal Border Gateway Protocol (iBGP) full mesh connection in large-scale iBGP implementation RT: Route Target, defined in SAFI: Subsequent Address Family Identifier, defined in VPN: Virtual Private Network, defined in VRF: VPN Routing and Forwarding, defined in

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.

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.

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 VPN and also BGP/MPLS Ethernet VPN (EVPN) networks, but its primary function is to retrieve interested VPN prefixes and it cannot be used to filter overload of VPN prefixes dynamically.

The BGP Maximum-Prefix feature controls the number of prefixes received from a neighbor. Configuring it on every PE-CE link can prevent VPN route overload. However, relying solely on sender-side protection is insufficient. If the sender has not configured Maximum Prefix, the VPN Prefix ORF mechanism can still prevent VPN route overload.

When a VRF overloads, some implementations may stop importing routes. Any additional VPN routes are held in the Routing Information Base (RIB). However, PEs still need to parse the incoming BGP messages, which consumes CPU cycles and further burdens the overloaded PE. The VPN Prefix ORF mechanism improves upon this by enabling the overloaded PE to signal the VPN routes matching the overload criteria back to the sender. The sender can then suppress these routes at the source, eliminating wasted processing and preserving resources for non-overloaded VRFs.

This section describes the encoding of VPN Prefix ORF entries. The VPN Prefix ORF entries are carried in the BGP ROUTE-REFRESH message as defined in . A BGP ROUTE-REFRESH message can carry one or more ORF entries. VPN Prefix ORF entries consist exclusively of Match fields with the value DENY. VPN Prefix ORF entries are evaluated in sequential order based on the Sequence field, defined below. When no VPN Prefix ORF entries in a non-empty VPN Prefix ORF match the route that is passed through the ORF, the Match criterion for the route is considered PERMIT. The format of a ROUTE-REFRESH message carrying VPN Prefix ORF entries is as follow: 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 can be set to MCAST-VPN, or MPLS-Labeled VPN. If the AFI is set to L2VPN, the SAFI can be set to BGP EVPN, VPLS, or MCAST-VPLS. The combination relationships between SAFI and AFI are presented in Table 1:

When-to-refresh (1 octet): the value MUST be 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 1.

Action (2 bits): the value is ADD, REMOVE or REMOVE-ALL as described in . If the received ORF entry contains an unrecognized value(0x11), such an ORF entry MUST be removed. Match (1 bit): the value is PERMIT(0) or DENY(1) as described in . For the purpose of this document, only the DENY value is permitted. This bit MUST be set to DENY(1). Overload VPN routes process method (1 bit): if the value is set to 0, it means the receiver of such message MUST withdraw all previously advertised overload VPN routes that match the ORF's type-specific part. If the value is set to 1, it means the sender of the VPN Prefix ORF message will refuse to accept VPN routes matching the overload criteria and that the receiver of the VPN Prefix ORF message MUST NOT announce VPN routes matching the overload criteria. The default value is 0. Note well, this bit is specific to the ORF Type introduced by this document. Reserved (4 bits): These bits are set to zero and ignored by the receiver. VPN Prefix ORF also contains a type-specific part. The encoding of the type-specific part is shown in Figure 2.

Sequence: Identifies the order in which the VPN Prefix ORF is generated and evaluated. It uniquely identifies a VPN Prefix ORF entry, along with the AFI/SAFI, ORF-Type, and Route Distinguisher. The Sequence SHOULD be non-contiguous to facilitate the insertion of new rules at a later stage, which means the receiver should not assume the sequence numbers are contiguous; a gap in sequence numbers (e.g., receiving sequence N then N+k, k>1) is valid. Length: Specifies the length of this VPN Prefix ORF entry. Route Distinguisher: Distinguishes different user routes. The VPN Prefix ORF filters the VPN routes it intends to send based on Route Distinguisher. If the RD is set to 0, it indicates all VPN prefixes. Optional Type-Length-Values (TLVs): Carries potential additional information to provide extensibility for the VPN Prefix ORF mechanism. Its format is shown in Figure 3. If one or more TLV(s) are unrecognized, the entire VPN Prefix ORF entry MUST be discarded.

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 purpose of VPN Prefix ORF is to block unwanted VPN prefixes; therefore, the "Action" of a valid entry MUST be set to "DENY". VPN routes that do not match any corresponding VPN Prefix ORF entries MUST be imported into the corresponding VRF. According to , if any field in a VPN Prefix ORF entry in the message contains an unrecognized value, the entire 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 by using the Outbound Route Filtering Capability defined in .

The Source PE TLV is defined to identify the originator of the VPN routes. The sender of the VPN Prefix ORF MUST check for the existence of the Source PE Extended Community (SPE EC; see section 6) on the VPN route being matched. If the SPE EC exists, the sender MUST include its value in the Source PE TLV. Otherwise, the value of Source PE TLV MUST be set to the Next Hop address. The Source PE TLV MUST appear at most once within an individual ORF entry. If an ORF entry contains multiple Source PE TLVs, the entire ORF entry MUST be ignored. The source PE TLV supports 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 (global IPv6 address only). Source PE identifier TLV: Type = 3, Length = 4 octets, value = the value of ORIGINATOR_ID in the Source PE Extended Community.

The Route Target TLV is defined to identify the RT of the overloaded VPN routes. The RT and RD can be used together to filter VPN routes if 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 VPN prefix ORF receiver MUST check whether the RT included in this TLV exists among the configured RTs. If so, it MUST filter out the VPN route. The Route Target TLV is defined as: Type = 5, Length = 8*n octets (where n is the number of RTs associated with the overloaded VPN routes), value = the RT value(s) of the overload VPN routes. If multiple RTs are included, an exact match is required.

This TLV applies to all VPN routes containing a route type field, to distinguish between different types of VPN routes and enable more granular control. The encoding of the Route Type TLV is as follow: Type = 6, Length = 1 octet, value = the value of Route Type field of the overload routes.

The operation of the VPN Prefix ORF mechanism on each sender is independent. Each sender 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 according to their specific circumstances. This section specifies procedures for a receiving BGP speaker to process VPN route information received from a sending BGP speaker. The VPN route information includes VPN routes and associated Route Distinguishers (RDs). The receiving BGP speaker determines the newly received VPN routes and evaluates whether installation of those routes would cause the configured VPN route limit for the associated VRF to be exceeded. If the configured VPN route limit for a VRF is exceeded, the receiving BGP speaker SHOULD send a VPN Prefix ORF message to the sending BGP speaker requesting that transmission of the identified VPN routes cease. Before originating a VPN Prefix ORF message, the receiving BGP speaker MUST compare the Route Targets (RTs) associated with the affected VPN routes against the import RTs configured on other VRFs of the device. If any RT associated with a VPN route is also imported by another VRF, the receiving BGP speaker MUST NOT originate a VPN Prefix ORF message for that route. The procedures described in this section apply to iBGP peers within the same Autonomous System (AS). VPN route identification is based on the RD. VPN Prefix ORF information is carried using ORF entries within a ROUTE-REFRESH message. The receiving BGP speaker includes the following information in the VPN Prefix ORF message: ORF entries carried within a ROUTE-REFRESH message. An Action field in each ORF entry indicating that the receiving BGP speaker requests installation of the specified outbound route filter. A Match field in each ORF entry indicating that VPN route updates matching the specified ORF entry are to be denied. An RD value identifying the affected VPN routes, encoded in the type-specific portion of the ORF entry. If multiple VRFs on a PE import VPN routes associated with the same RD, and only a subset of those VRFs exceed their configured route limits, the PE MUST NOT originate a VPN Prefix ORF entry for that RD. When the VPN Prefix ORF mechanism is triggered, the VPN Prefix ORF sender MUST send alarm information to network operators. The procedures for senders of VPN Prefix ORF entries are described below:

tuples from the newly received routes that were sent for incorporation into 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 the VPN Prefix ORF sender { S08. If (r is in the import RT list of VRF u) { S09. conflict_exists = TRUE; S09a break; S10. } S10a If (conflict_exists == TRUE) { S10b break; S10c } S11. } S12. } S13. If (conflict_exists == TRUE) { S14. // Cannot send ORF: would block routes needed by non-overloaded VRFs S15. Send warning message to the operator. Continue with next VRF. 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. 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 overload and ORF transmission. S31. } S32. } Else { S33. // No overload in this VRF; no ORF triggered S34. Continue normal route processing. S35. } S36. }]]>

For intra-AS VPN deployment, there are two scenarios: unique RD (per VPN, per PE). the same RD (per VPN, same on all PEs) Detailed descriptions about the above solutions are provided in Appendix B.

The VPN Prefix ORF is primarily used to block unwanted BGP updates. When the receiver receives a VPN Prefix ORF entry, it MUST check first whether the "Match" bit is "DENY" or not. If the "Match" bit is "PERMIT", the entry MUST be discarded and a warning MUST be sent to the operator. The default entry for the VPN Prefix ORF type is "Permit All", which means that all routes that do not match the existing entries in the VPN Prefix ORF table shall be advertised. The following procedures will only be evaluated when the "Match" bit is "DENY". The receiver of VPN Prefix ORF entries (which may be an RR, ASBR, or PE) performs the following actions upon receiving a VPN Prefix ORF entry from its BGP peer:

in the received VPN Prefix ORF entry. S03. If (Action == ADD) { S04 If (entry exists) { Replace existing entry. } S05 else { Add new entry. } } S06 else if (Action == REMOVE) { S07 If (entry exists) { Remove entry. } } S08 else if (Action == REMOVE-ALL) { Remove all matching VPN Prefix ORF entries. } S09 else { Handle as malformed or unsupported Action. } ]]>

The filtering conditions for stored VPN Prefix ORF entries include the RD and RT of the overloaded VPN Prefix Route. If the SPE EC is not attached to the BGP Update message for the VPN prefixes, the receiver MUST use the NEXT_HOP or ORIGINATOR_ID attribute as the originator of the VPN prefix to match against the VPN Prefix ORF entry. After installing the filter entries for outbound VPN prefixes, the receiver performs the following actions before sending VPN routes:

The procedure above can be used for route refresh processing after receiving an ORF update and the usual VPN route propagation. A change to the ORF prefixes triggers a rescan of the relevant routing information, followed by a route refresh. In contrast, regular individual VPN route updates are only subject to matching against the existing ORF rules. The route-refresh procedure as specified in is modified in the presence of VPN Prefix ORF Type entry with O-bit set to 1. The receiver is required to keep track of routes matching the ORF entries with O-bit set to 1 that have been already sent to the peer before those ORF entries were received and continue to advertise them even if denied by those ORF entries during both route-refresh processing and subsequent updates received for those routes.

Next Hop does not always identify the source as seen 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 an Option B inter-domain scenario, the ASBR will change the Next Hop. ORIGINATOR_ID is a non-transitive attribute generated by an RR to identify the source, but ORIGINATOR_ID cannot be advertised outside the local AS. To address these scenarios, this section defines a new Extended Community: Source PE Extended Community (SPE EC), which is designed to transmit the identifier of the source PE. The value of the SPE EC can be set by the source PE, RR, or Autonomous System Boundary Router (ASBR). Once set and attached to a BGP UPDATE message, its value MUST NOT be altered along the advertisement path. The peering AS number of the source PE can be conveyed by the Source AS Extended Community, as defined in The format of SPE EC is shown as Figure 4.

Where: Type(16 bit): Specifies the type value assigned by IANA, now it is TBD. ORIGINATOR_ID(32 bit): Specifies the identifier of the source PE. Reserved(16 bit): The sender MUST set the Reserved field to 0 and a received MUST ignore the Reserved field. An RR/ASBR SHOULD perform the following actions: Check for the existence of the SPE EC. If it exists, the RR/ASBR MUST NOT change it. If the SPE EC does not exist, check for the existence of the ORIGINATOR_ID. If it exists, put it into the SPE EC. If the ORIGINATOR_ID does not exist, put the router-id of the source PE into the SPE EC. This section extends route reflection behaviors, meaning that if support for this feature extension is required, the RR MUST perform the additional actions specified above.

Figure 5 illustrates the intra-domain topology of the application of VPN Prefix ORF mechanism.

To achieve the finer control of VPN prefixes, the VPN Prefix ORF mechanism needs both the sender and receiver of such message support the procedures described in this document. It influences only the advertisement and withdrawn of overloaded routes, and has no impact to other non-matched VPN routes. It can lessen the receiving and parsing stress of the overloaded routes on the VPN prefixes routes receiver timely. In order to reduce the complex configuration, it is RECOMMENDED that PEs within the network use the same formula to calculate the quota value, start from the basic mode, to the granular mode that described in the following section. Once such mechanism is triggered, it is RECOMMENDED that the operator to identify the source of overloaded VPN routes, based on the VPN Prefix ORF message, to find the root cause of overloaded VPN routes (malicious inject, or error manual configuration etc.), eliminate the advertisements of the overloaded VPN routes at the source and recover the advertisement of VPN routes into normal states. The algorithm that triggers the VPN Prefix ORF may lead some CPU consumption on the BGP speaker, but it depends on the implementation of such algorithm. Actually, it requires only the judgement whether the overloaded VPN routes are required also by other VRFs on the same device. The implementation of this mechanism should give the flexibility on controlling of advertisement of VPN Prefix ORF message, and also the withdrawn methods of the overloaded VPN routes, based on the description of this document.

The VPN Prefix ORF mechanism is designed for intra-domain BGP/MPLS IP VPN and BGP/MPLS Ethernet VPN (EVPN) 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: Basic mode: Triggered solely by local VRF-level prefix limits. No per-source quota configuration is required. In this mode, the PE sends a VPN Prefix ORF only if all VRFs that import the same Route Target(s) have exceeded their respective prefix limits. Granular mode (optional): Enabled when operators configure per-<Route Distinguisher, Source PE> quotas via their Network Management System (NMS) or CLI. This enables finer-grained control, allowing ORF triggering even if only one VRF exceeds its limit while others sharing the same RT remain non-overloaded, provided that the overload routes originate from a specific source. Quota is a threshold to limit the number of VPN routes under specific granularities (such as <PE>, <RD, Source 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 <RD, Source PE> 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 new PE access is added 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[(Adjust Coefficient)*<PE,CE Prefix Limit>*<Number of PEs within the VPN, includes the possibility of expansion in futures>, Local VRF Prefixes Limit] It should be noted that the above formula is only an example; operators can use different formulas based on actual needs in the management plane.

When the VPN Prefix ORF mechanism is triggered, the device SHOULD notify the network operator. Withdrawal of VPN Prefix ORF entries is manually initiated and requires the following conditions: 1. The network operator has confirmed that the overload condition causing the VRF route limit to be exceeded has been resolved. 2. The network operator has identified the VPN Prefix ORF entry to be withdrawn. Devices SHOULD maintain records of originated VPN Prefix ORF entries for this purpose. To withdraw VPN Prefix ORF entries, the operator configures the originating device to send a VPN Prefix ORF entry with the Action field set to REMOVE or REMOVE-ALL. The withdrawal request MUST include sufficient information to identify the target ORF entry. Automatic withdrawal of VPN Prefix ORF entries is not defined.

Security considerations for this work are the same as what is documented in . A compromised or misconfigured BGP peer could potentially send an excessive number of VPN Prefix ORF entries. Since these entries are processed on the VPN Prefix ORF receiver, an unbounded number of VPN Prefix ORF entries could consume excessive system resources (CPU cycles for route filtering and memory for storing the entries). On devices that support the VPN Prefix ORF mechanism, it is necessary to enforce a per-peer limit on the number of VPN Prefix ORF entries. Once this limit is exceeded, this device will ignore all newly received VPN Prefix ORF entries to prioritize its own stability, rather than continuously processing new filter rules advertised by the peer.

This document defines a new Outbound Route Filter type, named "VPN Prefix Outbound Route Filter (VPN Prefix ORF)", and assigns a value of 66 from the BGP Outbound Route Filtering (ORF) Types space which is under the "Border Gateway Protocol (BGP) Parameters" registry group.

This document defines a new "VPN Prefix ORF TLV Type" registry in the "Border Gateway Protocol (BGP) Parameters" registry group. The registration policies, per , for this registry are as follows:

IANA should make initial assignments as follows:

This document defines a new BGP Transitive Extended Community Type called "Source PE Extended Community" under "BGP Transitive Extended Community Types"

IANA is requested to make a new "ORF Entry Bits" registry in the "Border Gateway Protocol (BGP) Parameters" registry group. The registration policy for this registry is IETF Review. IANA should make initial assignments as follows:

Shunwan Zhuang Huawei Technologies Huawei Building, No.156 Beiqing Rd. Beijing Beijing, 100095 China

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 are thanked for their valuable comments on This document. Thanks Qian Wang and Penglun Zhang for their development work on the FRR-based implementation of the technical solution described in this document.

The experimental topology is shown in Figure 6.

This topology can be used to verify the following: whether the VPN Prefix ORF mechanism can block overload routes in intra-domain scenarios. whether the VPN Prefix ORF mechanism conflicts with an existing mechanism and causes failure. whether the quota value leads to route flapping. This document is experimental in order to determine if the proposed mechanism could block the overload routes as expected or not, and whether it would cause other potential network failures or operational challenges. The status of the document may be changed to proposed standard once there is sufficient deployment experience and issues identified, if any, are addressed.

This section describes the workflow of some example scenarios for illustrative purposes.

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. the network topology is shown in Figure 7.

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 overload VPN routes. a) PE1 If no quota value is set on PE1 and each VRF on PE1 has a prefix limit, when PE1 receives VPN routes from its BGP peer, it performs the following actions:

NOTE: When the prefix limit for the VPN1 VRF is exceeded, no other VRFs on PE1 import VPN routes with RT1. PE1 sends a VPN Prefix ORF message to the RR and a warning message to the operator. If a quota is configured for each <RD31, source PE3> tuple imported into a VRF and each VRF has a prefix limit, when PE1 receives VPN routes from its BGP peer, it performs the following actions:

tuple exceed the quota) { S02. If (the prefix limit of the VPN1 VRF is not exceeded) { S03. PE1 sends a warning message to the operator, and the VPN Prefix ORF mechanism is not triggered. S04. } else { S05. PE1 generates a BGP ROUTE-REFRESH message containing a VPN Prefix ORF entry with the parameters (RD = RD31, source PE = PE3, RT = RT1), and sends this entry to the RR. The RR processes the overload VPN routes based on the value of the "Overload VPN routes process method". S06. } S07. } ]]>

b) PE2 If no quota value is set on PE2 and each VRF on PE2 has a prefix limit, when PE2 receives VPN routes from its BGP peer, it performs the following actions:

NOTE: PE2 does not directly trigger the VPN Prefix ORF mechanism when the prefix limit of the VPN1 VRF is exceeded, because the VPN2 VRF imports VPN routes with RT1. PE2 triggers the mechanism only when the prefix limits for both the VPN1 and VPN2 VRFs are exceeded. If a quota is configured for each <RD31, source PE3> tuple imported into a VRF and each VRF has a prefix limit, when PE2 receives VPN routes from its BGP peer, it performs the following actions:

tuple exceed the quota) { S02. If (the prefix limit of the VPN1 VRF is not exceeded) { S03. PE2 sends a warning message to the operator, and the VPN Prefix ORF mechanism is not triggered. S04. } else { S05. If (the prefix limit of the VPN2 VRF is not exceeded) { S06. PE2 does not trigger the VPN Prefix ORF mechanism and only performs VPN route filtering for the target VPN1 VRF, stopping the import of VPN routes associated with . S07. } else { S08. PE2 generates a BGP ROUTE-REFRESH message containing a VPN Prefix ORF entry with the parameters (RD31, source PE = PE3, RTs = RT1 and RT2), and sends this entry to the RR. The RR processes the overload VPN routes based on the value of the "Overload VPN routes process method" field. S09. } S10. } S11. } ]]>

In this scenario, PE1-PE4 and RR are iBGP peers. RD is allocated per VPN. One/Multiple RTs are associated with the overload VPN routes and are imported into different VRFs on other PEs. The network topology is shown in Figure 8.

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 no quota value is set on PE1 and each VRF on PE1 has a prefix limit, PE1 does not directly trigger the VPN Prefix ORF mechanism when the prefix limit of the VPN1 VRF is exceeded, because the VPN2 VRF imports VPN routes with RT2. This case is similar to that of PE2 without a quota in Scenario 1, with modifications as follows:

If a quota is configured for each <RD1, source PE3> tuple imported into a VRF and each VRF has a prefix limit, this case is similar to that of PE2 with a quota in Scenario 1, with modifications as follows:

b) PE2 If no quota value is set on PE2 and each VRF on PE2 has a prefix limit, since only the VPN1 VRF needs to import VPN routes with RT1, this case is similar to that of PE1 without a quota in Scenario 1, with modifications as follows:

If a quota is configured for each <RD31, source PE3> tuple imported into a VRF and each VRF has a prefix limit, this case is similar to that of PE1 with a quota in Scenario 1, with modifications as follows:

Using scenario 1 in Appendix B, this section demonstrates how to determine each field when the sender generates a VPN Prefix ORF entry. Assuming an IPv4 network. When the VPN Prefix ORF mechanism is triggered on PE1, PE1 generates a VPN Prefix ORF entry that 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 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