VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4

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.¶

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.¶

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.¶

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.¶

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.¶

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 <RD, Source PE>
             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 <RD_x, PE_y> 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.

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.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".¶

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 <AFI/SAFI, ORF-Type,
     Sequence, Route Distinguisher> 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:¶

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.¶

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:¶

• 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-<Route Distinguisher, Source PE> 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 <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 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)*<PE,CE limit>*<Number of PEs within the VPN, includes the possibility expansion in futures>, 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.¶

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.¶

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".¶

        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.¶

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:¶

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 <RD31, source PE3> 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 <RD31, PE3>
     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:¶

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 <RD31, source PE3> 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 <RD31, PE3> 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 <RD31, PE3>.
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. }

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:¶

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 <RD1, source PE3> 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 <RD31, source PE3> 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".