[Idr] Shepherd Review of draft-ietf-idr-vpn-prefix-orf-06

Keyur Patel <keyur@arrcus.com> Tue, 02 July 2024 18:46 UTC

From: Keyur Patel <keyur@arrcus.com>
To: "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-vpn-prefix-orf.authors@ietf.org" <draft-ietf-idr-vpn-prefix-orf.authors@ietf.org>
Thread-Topic: Shepherd Review of draft-ietf-idr-vpn-prefix-orf-06
Thread-Index: AQHazLAejEUi2HU3dEu139X6Mxu+dg==
Date: Tue, 02 Jul 2024 18:46:15 +0000
Message-ID: <917D5A9E-A188-414B-B62E-7903D7CD3381@arrcus.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 50ouavU4b+CmB3Nef9QFIVPBguV+/K5NdV9ECO/ONVp+UI5Ly6Z45LNVjNqAOdRSdP+fyULZiV9vmg56zeFPNU8+q8U3IRkLBix9F3G1STAl0Naj1F0yNrMH7e1ERCvGUmPE7duWcuhgiyhAKsKBlQLQZYiJUtbDFjrnjdxOg8Ol1N1qn8hBj9/8sbkJXIRDv5Dk0tSTW5B/wkToqWzW/nHwFbMN/vBSHi/sDf1aW3uYGiR56t19jffshzg6+mB2dAymUMggUE2lKlntw26mUkMpO4kuIIgdP0AP8RfUIncyr3PIc/J/nlw4p6a0FVT0ClMLR78Nn8V8YiesBQ1IjUs/t76Ksebc3/lQCH4W4ROHz3KqdOGNtzs9i2MOc0UqcYUY/mymt1Vf7eCaTQOE7pWmFVwqwY1Bd++P+gWB419v/LRsfE37QA4ENCJJgtmqjnF0EdqvOh9MA88WBRZrvWLBPKpklEToZKO/QNBm4VRwvxb5rPtnbrFBmAjUwEWRQpx5YT02A0y9fAmYKo0GtCm+BjElx1WTCKiifMgpWTd1fa3YoQmT0zNI1CNhs3NghAxtsg23+PRmZoYjC9asSqSxQo1VfCxereD7PZO4MEF9GSX5hvxZhvYxhc44Z6zrxulQabArVTQmjm62tNfiCz+euZtwp5C3ZZC5XlQ+Rm2kdXZGk/k1DkHO8T88nG+4NEufFh2CplUmhNy/PnxiaRPDFT7Gn6QnCosVizL7a72aGy3Zn4lHW/cM3vkL9eqdq3+lmX0xbPDhsoNnLt9jYEg/D5I6lisnpdwtGcmEES6w6bruyNDG/oyP3fW8iH13rwjwJZ/ZtzgU2C8LjI+eOjLAmqYYC34NIZgQSorIQwYrppITNc6JJrdNXMkwex5s4wQIdrdVcIY+qROyNjx+xbxvBlLz/JomulI1qaZk3qWYMa3NkB8m4m6k4g+BqiKc/s9LMT1Ok7li7RxOqEO/2Yct7JUjjgy691Wf3qLKNvRdkuiKDRtMJFdB5Ze4+VdlpQKby0E7utMSai9NZaXX4HwG2vNXOO6zOjVXKdkff7Z1d10yH4K7PiO1fccOzRRD9wUDeT6iYH8BYPmUtLA/GOqu++KjA71VRBqV0afiz8G9CEA3t4r6X3x/U07PNMvcz1we9T6sxzS9uOnJjtwTtXsNT/0wZ2o+ARlsgtaG5vgo7uzKmBF3k3LPdCyz9zCCcOdQD4TgAxycX5R8Gr2tCFWRPHCNiVUe4OJ7hFntIb5Leq3gIo/rcQpNmmpRpu6b5LzaxU4/B3oI+OYcHSOh/HrfGmUGHNZclbqP2id7Y+VDN7D9RVevdPWxp5PTMvuIyg4I3eZkpBMpJWr044viP+KdqvROiXn8evuzOSqh4tApXmzEZV0ctnhwVJiPPhOG5miR8VLIzy4kyKBoVdzoFsQ3NNOUEkiOFzmBs3XZf1ytGkOFNe8Uu6mNMPwbYFJUCZmCMi6JgIt06wH+QV6IAwa6rE6iwBHQ4g2MY3tLPqsn6tc9nKD7YXh6u00nUGBC6p3ZrrwecQ2Q8L65/rZ41Bqsy9Ug2a7rkxSATMqaS4PeGwpNL6VSWaMSGXKuTJK1
Content-Type: multipart/alternative; boundary="_000_917D5A9EA188414BB62E7903D7CD3381arrcuscom_"
MIME-Version: 1.0
X-OriginatorOrg: arrcus.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR18MB2696.namprd18.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 68f5a1c4-b7a1-4019-6b4b-08dc9ac740ba
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jul 2024 18:46:15.4564 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: j24MwNYw8lFJWkvvKSEfzpwiGOWza0zOp+cQ5DOwgjd8FBwMnygW45MNL08Rt4+0erG4H7ll/z4foEdsvXy3OA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR18MB4938
Message-ID-Hash: B3AS77QARHCKAN3OFHZ7FAJOCOQVOR4E
X-Message-ID-Hash: B3AS77QARHCKAN3OFHZ7FAJOCOQVOR4E
X-MailFrom: keyur@arrcus.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Idr] Shepherd Review of draft-ietf-idr-vpn-prefix-orf-06
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/j3zzJjsUEoI9a1W6LjBMM_Y4Xac>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Owner: <mailto:idr-owner@ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Subscribe: <mailto:idr-join@ietf.org>
List-Unsubscribe: <mailto:idr-leave@ietf.org>

Hi Authors,

Attached is the early shepherd’s review on the draft before issuing WGLC. My comments are inlined #Keyur :)

IDR Working Group W. Wang
Internet-Draft A. Wang
Intended status: Experimental China Telecom
Expires: 20 September 2024 H. Wang
Huawei Technologies
G. Mishra
Verizon Inc.
S. Zhuang
J. Dong
Huawei Technologies
19 March 2024

#Keyur: The author limit needs to be at 5. Please address this requirement ahead of the WGLC.

VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4
draft-ietf-idr-vpn-prefix-orf-06

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

#Keyur: Is this draft specific to intra as only? If so please call it out explicitly in the introduction.
Otherwise, I suggest you remove (e.g….).

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 20 September 2024.

Wang, et al. Expires 20 September 2024 [Page 1]

Internet-Draft RD-ORF March 2024

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Operation process of VPN Prefix ORF mechanism on sender . . . 5
4.1. Intra-domain Scenarios and Solutions . . . . . . . . . . 7
4.1.1. Scenario-1 and Solution (Unique RD, One RT) . . . . . 8
4.1.2. Scenario-2 and Solution (Unique RD, Multiple RTs) . . 9
4.1.3. Scenario-3 and Solution (Universal RD) . . . . . . . 11
5. Source PE Extended Community . . . . . . . . . . . . . . . . 13
6. VPN Prefix ORF Encoding . . . . . . . . . . . . . . . . . . . 14
6.1. Source PE TLV . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Route Target TLV . . . . . . . . . . . . . . . . . . . . 16
7. Operation process of VPN Prefix ORF mechanism on receiver . . 17
8. Withdraw of VPN Prefix ORF entries . . . . . . . . . . . . . 18
9. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 18
10. Implementation Considerations . . . . . . . . . . . . . . . . 20
10.1. Implementation Considerations . . . . . . . . . . . . . 20
10.2. Implementation status . . . . . . . . . . . . . . . . . 20
10.3. Experimental topology . . . . . . . . . . . . . . . . . 21
10.4. Results of Experiments . . . . . . . . . . . . . . . . . 21
11. Security Considerations . . . . . . . . . . . . . . . . . . . 21
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
13. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 22
14. Normative References . . . . . . . . . . . . . . . . . . . . 22
Appendix A. Experimental topology . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25

1. Introduction

[I-D.wang<http://i-d.wang/>-idr-vpn-routes-control-analysis] analysis the scenarios and

#Keyur: s/analysis/analyzed

necessaries for VPN routes control in the shared BGP session. This

#Keyur: s/necessaries/requirements. s/in/for

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<http://i-d.wang/>-idr-vpn-routes-control-analysis].

Wang, et al. Expires 20 September 2024 [Page 2]

Internet-Draft RD-ORF March 2024

Now, there are several solutions can be used to alleviate these
problem:

* Route Target Constraint (RTC) as defined in [RFC4684]

* Address Prefix ORF as defined in [RFC5292]

* CP-ORF mechanism as defined in [RFC7543]

* PE-CE edge peer Maximum Prefix

* Configure the Maximum Prefix for each VRF on edge nodes

However, there are limitations to existing solutions:

1) Route Target Constraint

RTC can only filter the VPN routes from the uninterested VRFs, if the
“offending routes” come from the interested VRF, 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

Wang, et al. Expires 20 September 2024 [Page 3]

Internet-Draft RD-ORF March 2024

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.

#Keyur: s/fining/finer

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.

#Keyur: How is this draft solving the problem of parsing of BGP Updates for the first time announcements? I understand that the subsequent announcements are addressed. If so, it should clearly call that out.

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.

#Keyur: Again, how are you controlling the outage if the receiving PE is holding on all the routes, then generates the filters so that the unwanted routes are withdrawn. My point being: the memory spike has already happened by that time.

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:

* RD: Route Distinguisher, defined in [RFC4364]

* ORF: Outbound Route Filter, defined in [RFC5291]

* AFI: Address Family Identifier, defined in [RFC4760]

Wang, et al. Expires 20 September 2024 [Page 4]

Internet-Draft RD-ORF March 2024

* SAFI: Subsequent Address Family Identifier, defined in [RFC4760]

* EVPN: BGP/MPLS Ethernet VPN, defined in [RFC7432]

* RR: Router Reflector, provides a simple solution to the problem of
IBGP full mesh connection in large-scale IBGP implementation.

* VRF: Virtual Routing Forwarding, a virtual routing table based on
VPN instance.

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.

#Keyur: I don’t understand the last line. Why is it needed?

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

#Keyur: s/are the followings/are as follows:

It is one kind of route control method, which is executed 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).

#Keyur: I suggest you re-word the text. Maybe you mean: This section describes the procedures for the BGP peer(the first BGP peer) receiving 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.

#Keyur: Does it have to be newly? It could be an updated route information as well. Please note ORF doesn’t guarantee that the sender of the VPN routes will always filter the subsequent route updates per RFC5291.
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.

#Keyur: consider re-wording the text: Maybe you mean:
Based on the VPN instance
identification information, the first BGP peer determines the newly
added VPN routes, and checks whether the newly added VPN route count has caused the total VPN route count to go beyond the maximum route limit of the associated VPN instance

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

#Keyur: s/routes number/ route number. s/let/indicating that

the second BGP peer stop increasing the corresponding VPN routes that

#Keyur: s/increasing/sending

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.

Wang, et al. Expires 20 September 2024 [Page 5]

Internet-Draft RD-ORF March 2024

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

#Keyur: s/filed/field

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.

In order to more finely control VPN routing, PE parses the received

#Keyur: please clarify which PE here. I believe you mean the receiving BGP peer. Also please explain in a pictorial format how the ORF entry looks like.

BGP update message to obtain routing information, and obtains VPN
routing entries associated with the BGP optimal path from the routing
information.

#Keyur: What does the optimal path mean? Maybe just say path….
Then, PE should determine the target VRF based on the
RT import information of the routing target entry, and configure
filters for the target VRF. PE should first detect whether there is
currently a filter associated with the target VRF. If yes, PE should
use the filter to filter the VPN routing entries, so that VPN routing
entries carrying the specified routing identifier RD are not
introduced into the target VRF.
If there is currently no filter
associated with the target VRF, PE will directly introduce the VPN
routing entry into the target VRF.

#Keyur: Your describing the case where the route limit is reached. Maybe you mean: In case where the maximum route limit is not reached? Otherwise why would a filter be not present when the maximum limit is reached?

When configuring a filter for the target VRF, the PE should detect
whether there is currently a routing overflow issue with the target
VRF. If the target VRF currently has a routing overflow issue and
the reason for the routing overrun is caused by a VPN routing entry
carrying the specified RD, a filter is generated for the target VRF,
wherein the filter is used to filter VPN routing entries carrying the
specified RD. If the target VRF currently does not have routing
overflow issues, PE will delete the filter for the target VRF.

#Keyur: So let’s say the limit is set to 50 routes, PE receives 51 routes, a filter is placed and routes are filtered. It so happens that the routes are also flapping and suddenly route count goes to 45 so the filters are removed. Now the route count goes back to 51 so we add the filter… It would be helpful if you add some text to clarify what should happen….

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

Wang, et al. Expires 20 September 2024 [Page 6]

Internet-Draft RD-ORF March 2024

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,

#Keyur: maybe you mean: BGP peers supporting this functionality has VRFs that has maximum route limit reached should comply with the procedures defined in this document
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

#Keyur: s/pre-configurated/pre-configured. Also how do you enforce the quota for RD, source PE ahead of time?

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.

#Keyur: maybe you mean: Considering that the received VPN routes may belong to different VPNs and therefore carry different RDs…..

* when routes associated with <RD, source PE> tuple pass the quota
but the prefix limit of VRF is not exceeded, PE should send
warnings to the operator, and the VPN Prefix ORF mechanism should
not be triggered.

#Keyur: How do you enforce this?

* when routes associated with <RD, source PE> tuple pass the quota
and the prefix limit is exceeded and there is no other VRFs on
offended PE need VPN routes with this <RD, source PE> tuple, PE
should trigger VPN Prefix ORF mechanism and send a BGP ROUTE-
REFRESH message contains the corresponding VPN Prefix ORF entry to
its peer.

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:

Wang, et al. Expires 20 September 2024 [Page 7]

Internet-Draft RD-ORF March 2024

* RD is allocated per VPN per PE, each VRF only import one RT (see
Section 4.1.1).

* RD is allocated per VPN per PE. Multiple RTs are associated with
such VPN routes, and are imported into different VRFs in other
devices(see Section 4.1.2).

* RD is allocated per VPN, each VRF imports one/multiple RTs(see
Section 4.1.3).

The following sections will describe solutions to the above scenarios
in detail.

4.1.1. Scenario-1 and Solution (Unique RD, One RT)

In this scenario, PE1-PE4 and RR are iBGP peers. RD is allocated per
VPN per PE. The offending VPN routes only carry one RT. We assume
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.

Wang, et al. Expires 20 September 2024 [Page 8]

Internet-Draft RD-ORF March 2024

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

#Keyur: s/due to/since there….

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

#Keyur: s/and send to RR/and send the entry to a RR.

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.

#Keyur: s/Only when both VPN1 and VPN2 VRF/PE2 triggers the mechanism only when the prefix limit for both, the VPN1 and VPN2 VRF has exceeded...
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.

Wang, et al. Expires 20 September 2024 [Page 9]

Internet-Draft RD-ORF March 2024

+------------------------------------------------------------------------+
| |
| |
| +-------+ +-------+ |
| | PE1 +----------------+ +-----------------+ PE4 | |
| +-------+ | | +-------+ |
| VPN1(RD11,RT1) | | VPN2(RD42,RT2) |
| VPN2(RD12,RT2) | | |
| +-+----+-+ |
| | RR | |
| +-+----+-+ |
| | | |
| | | |
| +-------+ | | +-------+ |
| | PE2 +----------------+ +-----------------+ PE3 | |
| +-------+ +-------+ |
| VPN1(RD21,RT1) VPN1(RD31,RT1,RT2) |
| VPN2(RD32,RT2) |
| |
| AS 100 |
| |
+------------------------------------------------------------------------+
Figure 2 Network Topology of Scenario-2

When PE3 sends 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,

#Keyur: Same rewording comment as in the above section...
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.

#Keyur: Maybe you mean… RR will withdraw and stop advertising such….

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

#Keyur: Maybe you mean.. In case where the VPN1 VRF has exceeded its prefix limit and VPN2 VRF has not yet exceeded its prefix limit, PE1 should not send out the trigger message. Otherwise, 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.

#Keyur: PE1 should just discard ….
PE1 should only generate a

Wang, et al. Expires 20 September 2024 [Page 10]

Internet-Draft RD-ORF March 2024

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.

#Keyur: maybe you mean: 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) in case where the prefix limit has exceeded for both the VRFs.

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.

#Keyur: same comment as above.. /s/stop to advertise/ withdraw and stop advertising such...

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.

#Keyur: same comment as above.. /s/stop to advertise/ withdraw and stop advertising such...

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.

Wang, et al. Expires 20 September 2024 [Page 11]

Internet-Draft RD-ORF March 2024

+------------------------------------------------------------------------+
| |
| |
| +-------+ +-------+ |
| | PE1 +----------------+ +-----------------+ PE4 | |
| +-------+ | | +-------+ |
| VPN1(RD1,RT1) | | VPN2(RD12,RT2) |
| VPN2(RD12,RT2) | | |
| +-+----+-+ |
| | RR | |
| +-+----+-+ |
| | | |
| | | |
| +-------+ | | +-------+ |
| | PE2 +----------------+ +-----------------+ PE3 | |
| +-------+ +-------+ |
| VPN1(RD1,RT1) VPN1(RD1,RT1,RT2) |
| VPN2(RD32,RT2) |
| |
| AS 100 |
| |
+------------------------------------------------------------------------+
Figure 3 Network Topology of Scenario-3

When PE3 sends 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

Wang, et al. Expires 20 September 2024 [Page 12]

Internet-Draft RD-ORF March 2024

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.

#Keyur: Please fixed this section as my comments earlier. (Not repeating)

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.

#Keyur: Please fixed this section as my comments earlier. (Not repeating)

5. Source PE Extended Community

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

* a PE may have multiple addresses so that its BGP peer will receive
several different NEXT_HOP from the same source.

* In Option B inter-domain scenario, the ASBR will change the
NEXT_HOP.

#Keyur: Please fix all the above references where you indicate the scope to IBGP.

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.

Wang, et al. Expires 20 September 2024 [Page 13]

Internet-Draft RD-ORF March 2024

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:

* Check the existence of the SPE EC. If it exists, does not change
it.

* If SPE EC does not exist, check the existence of ORIGINATOR_ID.
If it exists, put it into SPE EC.

* If ORIGINATOR_ID does not exist, put the router-id of source PE
into SPE EC.

#Keyur: What if this is in a pure IPv6 network?

6. VPN Prefix ORF Encoding

In this section, we defined a new ORF type called VPN Prefix Outbound
Route Filter (VPN Prefix ORF). The ORF entries are carried in the
BGP ROUTE-REFRESH message as defined in [RFC5291]. A BGP ROUTE-
REFRESH message can carry one or more ORF entries. The ROUTE-REFRESH
message which carries ORF entries contains the following fields:

* AFI (2 octets)

* SAFI (1 octet)

* When-to-refresh (1 octet): the value is IMMEDIATE or DEFER

#Keyur: since these filter is VPN specific, any reason to not do IMMEDIATE?

* ORF Type (1 octet)

* Length of ORF entries (2 octets)

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

* Action (2 bits): the value is ADD, REMOVE or REMOVE-ALL

* Match (1 bit): the value is PERMIT or DENY

Wang, et al. Expires 20 September 2024 [Page 14]

Internet-Draft RD-ORF March 2024

* Offending VPN routes process method (1 bit): if the value is set
to 0, it means all offending VPN routes on the sender of VPN
Prefix ORF message should be withdrawn; if the value is set to 1,
it means the sender of VPN Prefix ORF message refuse to receive
new offending VPN routes. The default value is 0.

#Keyur: how do you determine new? How do u identify the offending routes in transit that caused the issue in first place?

* Reserved (4 bits)

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 (4 octets) |
| |
+-----------------------------------------+
| |
| Route Distinguisher (8 octets) |
| |
+-----------------------------------------+
| |
| Optional TLVs (variable) |
| |
+-----------------------------------------+

Figure 5: VPN Prefix ORF type-specific encoding

* Sequence: identifying the order in which RD-ORF is generated.

* Length: identifying the length of this VPN Prefix ORF entry.

* VRF Prefix Limit: carrying the prefix limt of the overflowed VRF.

* Route Distinguisher: distinguish the different user routes. The
VPN Prefix ORF filters the VPN routes it tends to send based on
Route Distinguisher. If RD is equal to 0, it means any VPN
prefixes.

#Keyur: s/any/all

* Optional TLVs: carry the potential additional information to give
the extensibility of the VPN Prefix ORF mechanism.

Wang, et al. Expires 20 September 2024 [Page 15]

Internet-Draft RD-ORF March 2024

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 VPN Prefix ORF.

* The AFI MUST be set to IPv4, IPv6, or Layer 2 VPN (L2VPN).

* If the AFI is set to IPv4 or IPv6, the SAFI MUST be set to MPLS-
labeled VPN address.

* If the AFI is set to L2VPN, the SAFI MUST be set to BGP EVPN.

* The Match field should be set to PERMIT when VRF Prefix Limit =
0xFFFF and RD=0; otherwise, the Match field should be set to DENY.

6.1. Source PE TLV

Source PE TLV is defined to identify the source of the VPN routes.
For the sender of VPN Prefix ORF, it will check the existence of SPE
EC. If it exists, the sender will put it into Source PE TLV.
Otherwise, the value of Source PE TLV should be set to local AS
number and NEXT_HOP.

The source PE TLV contains the following types:

* Type = 1(suggested), Length = 8 octets, value = local AS number +
NEXT_HOP.

* Type = 2(suggested), Length = 20 octets, value = local AS number +
NEXT_HOP.

* Type = 3(suggested), 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:

Wang, et al. Expires 20 September 2024 [Page 16]

Internet-Draft RD-ORF March 2024

Type = 4(suggested), Length = 8*n (n is the number of RTs that the
offending VPN routes attached) octets, value = the RT of the
offending VPN routes. If multiple RTs are included, there must be
an exact match.

7. Operation process of VPN Prefix ORF mechanism on receiver

The receiver of VPN Prefix ORF entries may be a RR or PE. As it
receives the VPN Prefix ORF entries from the sender, 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.

The RR or PE need to implement a control method for virtual private
network routing.

#Keyur: What does this mean? Consider removing it.
The RR or PE should determine the sending device
and next hop address of the stored VPN Prefix ORF entry corresponding
to the source PE in the filtering condition by looking up in the FIB,
including: 1) determining the port field corresponding to the stored
VPN Prefix ORF entry in the export routing filter strategy table; 2)
Determine the sending device of the stored VPN Prefix ORF entry based
on the value of the port field corresponding to the stored VPN Prefix
ORF entry.

#Keyur: Can you explain the motivation?

The filtering conditions for the stored VPN Prefix ORF entries
contain the RD and RT of the source PE.

If the sending device of the VPN Prefix ORF entry stored under the
same filtering condition includes all IBGP neighbors of the RR or PE
other than the device with the next hop address, the VPN Prefix ORF
entry is generated, where the next hop address is the next hop
address sent to the network device in the direction of the source PE
in the same filtering condition. The filtering condition in the
generated VPN Prefix ORF entry contain the address, RD and RT of the
source PE; Then, the RR or PE should send the generated VPN Prefix
ORF entry to the device at the next hop address via BGP ROUTE-REFRESH
message, so that the device at the next hop address filters the VPN
route sent by the source PE.

#Keyur: Apologies. I don’t get the purpose of this paragraph.

Before the receiver send a VPN route, it should check its ORF-Policy
table with <RD, Source PE> tuple of the VPN route.

#Keyur: s/Before the receiver send a/Before the route update is announced…...
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.

Wang, et al. Expires 20 September 2024 [Page 17]

Internet-Draft RD-ORF March 2024

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:

* If the "Offending VPN routes process method" bit is 0, the
receiver should withdraw all the VPN routes identified by RD, RT
and information in optional TLVs in the entry, and stop sending
the corresponding VPN routes to the sender.

* If the "Offending VPN routes process method" bit is 1, the
receiver 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.

#Keyur: See my above comment with bit value of 1 please.

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:

* AFI is equal to IPv4

* SAFI is equal to MPLS-labeled VPN address

* When-to-refresh is equal to IMMEDIATE

* ORF Type is equal to VPN Prefix ORF

* Length of ORF entries is equal to 26

* Action is equal to ADD

* Match is equal to PERMIT

Wang, et al. Expires 20 September 2024 [Page 18]

Internet-Draft RD-ORF March 2024

* Offending VPN routes process method is equal to 0

* Sequence is equal to 0xFFFFFFFF

* Length is equal to 12

* VRF Prefix Limit is equal to 0xFFFF

* Route Distinguisher is equal to 0

When the VPN Prefix ORF mechanism is triggered on PE1, PE1 will
generate a VPN Prefix ORF 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 44

* Action is equal to ADD

* Match is equal to DENY

* Offending VPN routes process method is equal to 0

* Sequence is equal to 1

* Length is equal to 30

* VRF Prefix Limit is equal to the prefix limit of VPN1 VRF

* Route Distinguisher is equal to RD31

* Optional TLV:

- Type is equal to 1 (Source PE TLV)

- Length is equal to 8

- value is equal to PE3's IPv4 address

- Type is equal to 4 (Route Target TLV)

- Length is equal to 8

Wang, et al. Expires 20 September 2024 [Page 19]

Internet-Draft RD-ORF March 2024

- value is equal to RT1

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

#Keyur: arise/cause?

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

#Keyur s/an VPN/a VPN..

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. Implementation status

Currently, H3C has implemented some VPN Prefix ORF mechanism related
functions as follows:

#Keyur: consider removing “some”.

* By configuring VRF Prefix limit and quota, achieve the use of RD
and Source PE to control VPN routing.

* Generating, transmitting and processing Type 1 and Type 2 Source
PE TLV.

* Using the Offending VPN routes process method to revoke all
routes.

Wang, et al. Expires 20 September 2024 [Page 20]

Internet-Draft RD-ORF March 2024

Besides, we also implemented the following functions based on the
open-source BGP implementation (FRR):

* VPN Prefix ORF mechanism triggered based on VRF limit in intra-
domain and inter-domain scenarios.

* RD based VPN routing filtering in intra-domain and inter-domain
scenarios.

10.3. Experimental topology

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

* Intra-domain as a standalone mechanism,

* Inter-domain as a standalone mechanisms,

* Adding the VPN Prefix ORF to existing mechanisms for intra-domain
VPNs,

* Adding the VPN Prefix ORF to existing mechanisms for intra-domain
VPNs.

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

#Keyur: You may benefit from saying “this draft does build upon RFC 5291."

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:

Wang, et al. Expires 20 September 2024 [Page 21]

Internet-Draft RD-ORF March 2024

This document also requests a new Transitive Extended Community Type.
The new Transitive Extended Community Type name shall be "Source PE
Extended Community".

Under "BGP Transitive Extended Community Types:"
Registry: "Source PE Extended Community" type
0x0d(suggested) Source PE Extended Community

13. 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, 26 July 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-
evpn-inter-subnet-forwarding-15>.

Wang, et al. Expires 20 September 2024 [Page 22]

Internet-Draft RD-ORF March 2024

[I-D.wang<http://i-d.wang/>-idr-vpn-routes-control-analysis]
Wang, A., Wang, W., Mishra, G. S., Wang, H., Zhuang, S.,
and J. Dong, "Analysis of VPN Routes Control in Shared BGP
Session", Work in Progress, Internet-Draft, draft-wang-
idr-vpn-routes-control-analysis-04, 6 September 2021,
<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, March 1997,
<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,
February 2006, <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, February
2006, <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,
November 2006, <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, January 2007,
<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,
August 2008, <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,
August 2008, <https://www.rfc-editor.org/info/rfc5292>.

[RFC7024] Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter,
Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS
VPNs", RFC 7024, DOI 10.17487/RFC7024, October 2013,
<https://www.rfc-editor.org/info/rfc7024>.

Wang, et al. Expires 20 September 2024 [Page 23]

Internet-Draft RD-ORF March 2024

[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <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, May 2015,
<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:

* whether the VPN Prefix ORF mechanism could block the offending
routes in intra-domain scenario.

* whether the VPN Prefix ORF mechanism could block the offending
routes in inter-domain scenario.

* whether the VPN Prefix ORF mechanism conflicts with the existing
mechanism and cause failure.

* whether the quota value leads to flapping.

Wang, et al. Expires 20 September 2024 [Page 24]

Internet-Draft RD-ORF March 2024

* TBD

Authors' Addresses

Wei Wang
China Telecom
Beiqijia Town, Changping District
Beijing
Beijing, 102209
China
Email: weiwang94@foxmail.com<mailto:weiwang94@foxmail.com>

Aijun Wang
China Telecom
Beiqijia Town, Changping District
Beijing
Beijing, 102209
China
Email: wangaj3@chinatelecom.cn<mailto:wangaj3@chinatelecom.cn>

Haibo Wang
Huawei Technologies
Huawei Building, No.156 Beiqing Rd.
Beijing
Beijing, 100095
China
Email: rainsword.wang@huawei.com<mailto:rainsword.wang@huawei.com>

Gyan S. Mishra
Verizon Inc.
13101 Columbia Pike
Silver Spring, MD 20904
United States of America
Phone: 301 502-1347
Email: gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>

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

Wang, et al. Expires 20 September 2024 [Page 25]

Internet-Draft RD-ORF March 2024

Email: zhuangshunwan@huawei.com<mailto:zhuangshunwan@huawei.com>

Jie Dong
Huawei Technologies
Huawei Building, No.156 Beiqing Rd.
Beijing
Beijing, 100095
China
Email: jie.dong@huawei.com<mailto:jie.dong@huawei.com>

[Idr] Re: Shepherd Review of draft-ietf-idr-vpn-p… Wei Wang
[Idr] Shepherd Review of draft-ietf-idr-vpn-prefi… Keyur Patel