Internet-Draft RD-ORF June 2023
Wang, et al. Expires 1 January 2024 [Page]
Workgroup:
IDR Working Group
Internet-Draft:
draft-ietf-idr-vpn-prefix-orf-02
Published:
Intended Status:
Experimental
Expires:
Authors:
W. Wang
China Telecom
A. Wang
China Telecom
H. Wang
Huawei Technologies
G. Mishra
Verizon Inc.
S. Zhuang
Huawei Technologies
J. Dong
Huawei Technologies

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

Abstract

This draft defines a new Outbound Route Filter (ORF) type, called the VPN Prefix ORF. The described VPN Prefix ORF mechanism is applicable when the VPN routes from different VRFs are exchanged via one shared BGP session (e.g., routers in a single-domain connect via Route Reflector).

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 1 January 2024.

Table of Contents

1. Introduction

[I-D.wang-idr-vpn-routes-control-analysis] analysis the scenarios and necessaries for VPN routes control in the shared BGP session. This draft analyzes the existing solutions and their limitations for these scenarios, proposes the new VPN Prefix ORF solution to meet the requirements that 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:

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, RFC mechanism can't filter them.

2) Address Prefix ORF

Using Address Prefix ORF to filter VPN routes need to pre-configuration, but it is impossible to know which prefix may cause overflow in advance.

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, which is not desirable for the fining control of the VPN Prefixes advertisement.

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 ORF-type, called the VPN Prefix ORF. This mechanism is event-driven and does not need to be pre-configured. When a VRF of a router overflows, the router will find out the VPN prefix (RD, RT, source PE, etc.) of offending VPN routes in this VRF, and send a VPN Prefix ORF to its BGP peer that carries the relevant information. If a BGP speaker receives a VPN Prefix ORF entry from its BGP peer, it will filter the VPN routes it tends to send according to the entry.

The purpose of this mechanism is to control the outrage within the minimum range and avoid 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 defined in this draft:

4. Operation 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 judgement to determine whether it needs to send VPN Prefix ORF to its upstream peer. The operators need to make sure the algorithms in different devices consistent.

The general procedures of the VPN Prefix ORF mechanism on the sender are the followings:

It is one kind of route control method, which is excuted by one of the BGP peer(the first BGP peer) when it receives the VPN routes information from another BGP peer(the second BGP peer). The VPN information includes the newly VPN routes and their corresponding VPN instance identification information. Based on the VPN instance identification information, the first BGP peer determines the newly added VPN routes, and check whether the routes number of VPN instance that identified by the VPN instance identification information is reached or excess its limit.

If the routes number of the VPN instance that identified by the VPN instance identification information is reached or excess its limit, it will send the instruction information to the second BGP peer, let the second BGP peer stop increasing the corresponding VPN routes that identified by the VPN instance identification information.

The first BGP peer and the second BGP peer are iBGP peers that are within one AS. The VPN instance identification information is RD and the instruction information is sent via the route-refresh message.

The instruction information that sends to the second 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 to add the corresponding filter condition into outbound route filter of the second the BGP peer.

Set the Match filed in the ORF entries to the value that instructs to deny the VPN routes updates that matches the corresponding ORF entries.

The RD value that identifies the above mentioned VPN instance is added at the type-specific part of the ORF entries.

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, due to the received VPN routes may belong to different VPN and carry the corresponding RDs, the PE should extract the VPN route information from BGP UPDATE message which contains VPN routes related to BGP optimal routing. PE can determine the target VRFs of the received VPN route based on the RT of the VPN route and the RT-import of VRFs. Then, the PE should sequentially determine whether each target VRF will exceed the limit after importing the received VPN routes. If a target VRF exceeds the limit which is caused by the VPN routes carrying a certain RD and the other target VRFs have not overflow, PE should not trigger the VPN Prefix ORF mechanism, and only performs VPN route filtering for the target VRF and stop importing VPN routes carrying the specific RD. If a target VRF exceeds the limit and there is no other VRFs need these VPN routes, the 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, which will generate a VPN routes filtering strategy for the VRF. And if the "Offending VPN routes process method" bit is 1, the receiver of VPN Prefix ORF entry should withdraw the extra VPN routes according to the value of VRF Prefix Limit, RD, RT and information in optional TLVs in the entry, and stop sending the corresponding VPN routes to the sender. If the target VRF no longer exceeds the limit, the relevant VPN routing filtering strategy needs to be deleted.

When importing VPN routes to a VRF, it is necessary to determine whether there is a VPN routes filtering strategy on the PE for that VRF. If a VPN routes filtering strategy for a certain VRF which is overflow already exists on the PE, VPN routes that comply with this strategy should not be imported, and should be discarded.

b) Quota value is set on PE

On PE, each VRF has a prefix limit, and routes associated with each <RD, source PE> tuple has a pre-configurated quota. Due to the received VPN routes may belong to different VPN and carry the corresponding RDs, the PE should determine whether VRF will exceed the limit after adding the received VPN routes.

When the VPN Prefix ORF mechanism is triggered, the device must send an alarm information to network operators.

4.1. Intra-domain Scenarios and Solutions

For intra-AS VPN deployment, there are three scenarios:

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 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 excessive VPN routes with RT1, while 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 some mechanisms to identify and control the advertisement 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 prefix limit of VPN1 VRF is exceeded, due to there is no other VRFs on PE1 need the VPN routes with RT1, PE1 will send VPN Prefix ORF message to RR and send warning to operator. The message will carry the prefix limit of VPN1 VRF, the RD value is set to 0 and the RT value is set to RT1. RR will withdraw the offending VPN routes and control the number of VPN routes sending to PE1.

If quota value is set on PE1, each VRF has a prefix limit, and each <RD, source PE> tuple imported into VRF has a quota. When routes associated with <RD31, PE3> tuple pass the quota but the prefix limit of VPN1 VRF is not exceeded, PE1 sends a warning message to the operator, and the VPN Prefix ORF mechanism should not be triggered. After the prefix limit of VPN1 VRF is exceeded, due to there is no other VRFs on PE1 need the VPN routes with RT1, PE1 will generate a BGP ROUTE-REFRESH message contains a VPN Prefix ORF entry, and send to RR. RR will withdraw and stop to advertise such offending VPN routes (RD31, the prefix limit of VPN1 VRF, source PE is PE3, RT is RT1) to PE1.

b) PE2

If quota value is not set on PE2, when the prefix limit of VPN1 VRF is exceeded, PE2 cannot trigger VPN Prefix ORF mechanism directly, because VPN2 VRF needs the VPN routes with RT1. Only when both VPN1 VRF and VPN2 VRF are overflow, PE2 triggers the mechanism. The VPN Prefix ORF message will carry the VRF Prefix Limit = min(prefix limit of VPN1 VRF, prefix limit of VPN2 VRF), the RD value is set to 0 and the RT value is set to RT1. RR will withdraw the offending VPN routes and control the number of VPN routes sending to PE1.

If quota value is set on PE2, both VPN1 VRF and VPN2 VRF import VPN routes with RT1. If PE2 triggers VPN Prefix ORF mechanism when VPN1 VRF overflows, VPN2 VRF cannot receive VPN routes with RT1 as well. PE2 should not trigger the VPN Prefix ORF mechanism to RR (RD31, min(prefix limit of VPN1 VRF, prefix limit of VPN2 VRF), RT1, RT2, source PE is PE3) until all the VRFs that import RT1 on it overflow.

4.1.2. Scenario-2 and Solution (Unique RD, Multiple RTs)

In this scenario, PE1-PE4 and RR are iBGP peers. RD is allocated per VPN per PE. Multiple RTs are associated with the offending VPN routes, and are imported into different VRFs in other devices. We assume the network topology is shown in Figure 2.

 +------------------------------------------------------------------------+
 |                                                                        |
 |                                                                        |
 |        +-------+                                       +-------+       |
 |        |  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 excessive 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, when the prefix limit of VPN1 VRF is exceeded, PE1 cannot trigger VPN Prefix ORF mechanism directly, because VPN2 VRF needs the VPN routes with RT1. Only when both VPN1 VRF and VPN2 VRF are overflow, PE1 will send VPN Prefix ORF message to RR and send warning to operator. The message will carry the VRF Prefix Limit = min(prefix limit of VPN1 VRF, prefix limit of VPN2 VRF), the RD value is set to RD31, the RT value is set to RT1, RT2 and the source PE is PE3. RR will withdraw and stop to advertise such offending VPN routes to PE1.

If quota value is set on PE1, when routes associated with <RD31, PE3> tuple pass the quota but the prefix limit of VPN1 VRF is not exceeded, PE1 sends a warning to the operator. When the prefix limit of VPN1 VRF is exceeded, if the VPN2 VRF does not reach its limit at the same time, PE1 should still not send out the trigger message, because if it does so, the VPN2 VRF can't receive the VPN routes too (RR will filter all the VPN prefixes that contain RT1). PE1 just discard the offending VPN routes locally. PE1 should only generate a BGP ROUTE-REFRESH message contains a VPN Prefix ORF entry(RD31, min(prefix limit of VPN1 VRF, prefix limit of VPN2 VRF), RT1, RT2, comes from PE3) when both the VRFs that import such prefixes are overflow.

b) PE2

If quota value is not set on PE2, when the prefix limit of VPN1 VRF is exceeded, due to there is no other VRFs on PE2 need the VPN routes with RT1, PE2 will send VPN Prefix ORF message to RR and send warning to operator. The message will carry the prefix limit of VPN1 VRF, the RD value is set to RD31 and the RT value is set to RT1. RR will withdraw and stop to advertise such offending VPN routes to PE2.

If quota value is set on PE2, due to there is only one VRF imports VPN routes with RT1. If it overflows, it will trigger VPN Prefix ORF (RD31, the prefix limit of VPN1 VRF, RT1, comes from PE3) mechanisms. RR will withdraw and stop to advertise such offending VPN routes to PE2.

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 be imported into different VRFs in other devices. We assume the network topology is shown in Figure 3.

 +------------------------------------------------------------------------+
 |                                                                        |
 |                                                                        |
 |        +-------+                                       +-------+       |
 |        |  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 excessive VPN routes with RD1 and attached RT1 and RT2, while both PE1 and PE2 import VPN routes with RT1, the process of offending VPN routes will influence performance of VRFs on PEs.

a) PE1

If quota value is not set on PE1, when the prefix limit of VPN1 VRF is exceeded, PE1 cannot trigger VPN Prefix ORF mechanism directly, because VPN2 VRF needs the VPN routes with RT2. Only when both VPN1 VRF and VPN2 VRF are overflow, PE1 will send VPN Prefix ORF message to RR and send warning to operator. The message will carry the VRF Prefix Limit = min(prefix limit of VPN1 VRF, prefix limit of VPN2 VRF), the RD value is set to RD1 and the RT value is set to RT1, RT2. RR will withdraw and stop to advertise such offending VPN routes to PE1.

If quota value is set on PE1, when routes associated with <RD1, PE3> tuple pass the quota but the prefix limit of VPN1 VRF is not exceeded, PE1 sends a warning to the operator. When the prefix limit of VPN1 VRF is exceeded, if the VPN2 VRF does not reach its limit at the same time, PE1 should still not send out the trigger message, because if it does so, the VPN2 VRF can't receive the VPN routes too (RR will filter all the VPN prefixes that contain RT1). PE1 just discard the offending VPN routes locally. PE1 should only generate a BGP ROUTE-REFRESH message contains a VPN Prefix ORF entry(RD1, min(prefix limit of VPN1 VRF, prefix limit of VPN2 VRF), RT1, RT2, comes from PE3) when both the VRFs that import such prefixes are overflow.

b) PE2

If quota value is not set on PE2, when the prefix limit of VPN1 VRF is exceeded, due to there is no other VRFs on PE2 need the VPN routes with RT1, PE2 will send VPN Prefix ORF message to RR and send warning to operator. The message will carry the prefix limit of VPN1 VRF, the RD value is set to RD1 and the RT value is set to RT1. RR will withdraw and stop to advertise such offending VPN routes to PE2.

If quota value is set on PE2, due to there is only one VRF imports VPN routes with RT1. If it overflows, it will trigger VPN Prefix ORF (RD1, the prefix limit of VPN1 VRF, RT1, comes from PE3) mechanisms. RR will withdraw and stop to advertise such offending VPN routes to PE2.

When PE2 overflows and PE1 does not overflow. PE2 triggers the VPN Prefix ORF message (RD1, RT1, comes from PE3). Using Source PE and RD, RR will only withdraw and stop to advertise VPN routes with <RD1, RT1, come from PE3> to PE2. The communication between PE2 and PE1 for VPN1 will not be influenced.

5. Source PE Extended Community

We usually use NEXT_HOP to identify the source, but it may not useful in the following scenarios:

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 cover the above scenarios, we define a new Extended Community: Source PE Extended Community(SPE EC) to transmit the identifier of source. Its value can be set by source PE/RR/ASBR. Once set and attached with the BGP UPDATE message, its value should not be changed along the advertisement path.

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            |    Autonomous System Number   :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :     AS Number (cont.)         |         ORIGINATOR_ID         :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :     ORIGINATOR_ID (cont.)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Figure 4 The format of SPE EC

For the RR/ASBR, it should perform as following:

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:

A VPN Prefix ORF entry contains a common part and type-specific part. The common part is encoded as follows:

VPN Prefix ORF also contains type-specific part. The encoding of the type-specific part is shown in Figure 5.

 +-----------------------------------------+
 |                                         |
 |            Sequence (4 octets)          |
 |                                         |
 +-----------------------------------------+
 |                                         |
 |             Length (2 octets)           |
 |                                         |
 +-----------------------------------------+
 |                                         |
 |        VRF Prefix Limit (2 octets)      |
 |                                         |
 +-----------------------------------------+
 |                                         |
 |      Route Distinguisher (8 octets)     |
 |                                         |
 +-----------------------------------------+
 |                                         |
 |        Optional TLVs (variable)         |
 |                                         |
 +-----------------------------------------+

   Figure 5: VPN Prefix ORF type-specific encoding

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:

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.

The source PE TLV contains the following types:

  • Type = 1, Length = 8 octets, value = local AS number + NEXT_HOP.
  • Type = 2, Length = 20 octets, value = local AS number + NEXT_HOP.
  • Type = 3, Length = 8 octets, value = the value of AS number and ORIGINATOR_ID in Source PE Extended Community.

6.2. 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 encoding of Route Target TLV is as follow:

7. Operation process of VPN Prefix ORF mechanism on receiver

The receiver of VPN Prefix ORF entries may be a RR or PE. As it receives the VPN Prefix ORF entries, it will check <AFI/SAFI, ORF-Type, Sequence, Route Distinguisher> to find if it already existed in its ORF-Policy table. If not, the receiver will add the VPN Prefix ORF entries into its ORF-Policy table; otherwise, the receiver will discard it.

Before the receiver send a VPN route, it should check its ORF-Policy table with <RD, Source PE> tuple of the VPN route. The Route Distinguisher information can be extracted directly from the BGP UPDATE message. The source PE information should be compared against the Source PE Extended Community if it is contained in BGP UPDATE message, or else the NEXT_HOP.

If there is not a related VPN Prefix ORF entry in ORF-Policy table, the receiver will send this VPN route; otherwise, the receiver will perform the following operations:

8. Withdraw of VPN Prefix ORF entries

When the VPN Prefix ORF mechanism is triggered, the alarm information will be generated and sent to the network operators. Operators should manually configure the network to resume normal operation. Due to devices can record the VPN Prefix ORF entries sent by each VRF, operators can find the entries needs to be withdrawn, and trigger the withdraw process as described in [RFC5291] manually. After returning to normal, the device sends withdraw ORF entries to its peer who have previously received ORF entries.

9. Applicability

We take the scenario in Section 4.1.1 as an example to illustrate how to determine each field when the sender generates a VPN Prefix ORF entry. We assume it is an IPv4 network. After PE1-PE4 and RR advertising the Outbound Route Filtering Capability, each of PE1-PE4 should send a VPN Prefix ORF entry that means "PERMIT-ALL" as follows:

When the VPN Prefix ORF mechanism is triggered on PE1, PE1 will generate a VPN Prefix ORF contains the following information:

10. Implementation Considerations

This draft is experimental in order to determine if the proposed mechanism could block the offending routes as expected or not, and whether it would arise other potential network failures. The first section below describes implementation considerations for the mechanism. The second section below provides a short summary of the experimental topology and the results.

10.1. Implementation Considerations

Before originating an VPN Prefix ORF message, the device should compare the list of RDs carried by VPN routes signaled for filtering and the RDs imported by not affected VRF(s). Once they have intersection, the VPN Prefix ORF message MUST NOT be originated.

In deployment, the quota value can be set with different granularity, such as <PE>, <RD, Source AS>, 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 changed.

To avoid the frequently change of the quota value, the value can be set according to 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.

10.2. Experimental topology

The experiments will text whether the VPN Prefix ORF blocks the offending routes in the following scenarios:

10.3. Results of Experiments

[TBD]

11. Security Considerations

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). The code point is from the "BGP Outbound Route Filtering (ORF) Types". It is recommended to set the code point of VPN Prefix ORF to 66.

This document also define a VPN Prefix ORF TLV type under "Border Gateway Protocol (BGP) Parameters", four TLV types are defined:

 +===========================+======+===========================+
 | Registry                  | Type |       Meaning             |
 +===========================+======+===========================+
 |IPv4 Source PE TLV         | 1    |IPv4 address for source PE.|
 +---------------------------+------+---------------------------+
 |IPv6 Source PE TLV         | 2    |IPv6 address for source PE.|
 +---------------------------+------+---------------------------+
 |Source PE Extended         | 3    |Source PE Extended         |
 |Community TLV              |      |Community for source PE    |
 +---------------------------+------+---------------------------+
 |Route Target TLV           | 4    |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 "Transitive Extended Community:"
        Registry: "Source PE Extended Community"
        Registration Procedure(s): First Come, First Served
         0x0d               Source PE Extended Community

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

14. 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, , <https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-inter-subnet-forwarding-15>.
[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, , <https://datatracker.ietf.org/doc/html/draft-wang-idr-vpn-routes-control-analysis-04>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC4360]
Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, , <https://www.rfc-editor.org/info/rfc4360>.
[RFC4364]
Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, , <https://www.rfc-editor.org/info/rfc4364>.
[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, , <https://www.rfc-editor.org/info/rfc4684>.
[RFC4760]
Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, , <https://www.rfc-editor.org/info/rfc4760>.
[RFC5291]
Chen, E. and Y. Rekhter, "Outbound Route Filtering Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291, , <https://www.rfc-editor.org/info/rfc5291>.
[RFC5292]
Chen, E. and S. Sangli, "Address-Prefix-Based Outbound Route Filter for BGP-4", RFC 5292, DOI 10.17487/RFC5292, , <https://www.rfc-editor.org/info/rfc5292>.
[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, , <https://www.rfc-editor.org/info/rfc7432>.
[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, , <https://www.rfc-editor.org/info/rfc7543>.

Appendix A. Experimental topology

The experimental topology is shown in Figure 6.

+--------------------------+             +--------------------------+
|                          |             |                          |
|                          |             |                          |
|   +---------+            |             |            +---------+   |
|   |   PE1   |            |             |            |   PE3   |   |
|   +---------+            |             |            +---------+   |
|              \           |             |           /              |
|                \+---------+    EBGP   +---------+/                |
|                 |         |           |         |                 |
|                 |  ASBR1  |-----------|  ASBR2  |                 |
|                 |         |           |         |                 |
|                 +---------+           +---------+                 |
|                /         |             |         \                |
|   +---------+/           |             |           \+---------+   |
|   |   PE2   |            |             |            |   PE4   |   |
|   +---------+            |             |            +---------+   |
|                          |             |                          |
|           AS1            |             |           AS2            |
+--------------------------+             +--------------------------+
                 Figure 6 The experimental topology

This topology can be used to verify as follows:

Authors' Addresses

Wei Wang
China Telecom
Beiqijia Town, Changping District
Beijing
Beijing, 102209
China
Aijun Wang
China Telecom
Beiqijia Town, Changping District
Beijing
Beijing, 102209
China
Haibo Wang
Huawei Technologies
Huawei Building, No.156 Beiqing Rd.
Beijing
Beijing, 100095
China
Gyan S. Mishra
Verizon Inc.
13101 Columbia Pike
Silver Spring, MD 20904
United States of America
Phone: 301 502-1347
Shunwan Zhuang
Huawei Technologies
Huawei Building, No.156 Beiqing Rd.
Beijing
Beijing, 100095
China
Jie Dong
Huawei Technologies
Huawei Building, No.156 Beiqing Rd.
Beijing
Beijing, 100095
China