Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)

"Wanghaibo (Rainsword)" <> Fri, 12 February 2021 15:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A5BA03A1719 for <>; Fri, 12 Feb 2021 07:04:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_RATIO_04=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aqjoUrxoeSnM for <>; Fri, 12 Feb 2021 07:04:27 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8A6043A1689 for <>; Fri, 12 Feb 2021 07:04:25 -0800 (PST)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4Dcc6r0GS2z67VVD for <>; Fri, 12 Feb 2021 22:57:40 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Fri, 12 Feb 2021 16:04:20 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Fri, 12 Feb 2021 23:04:18 +0800
Received: from ([]) by ([]) with mapi id 15.01.2106.006; Fri, 12 Feb 2021 23:04:18 +0800
From: "Wanghaibo (Rainsword)" <>
To: Robert Raszuk <>
CC: "idr@ietf. org" <>, Susan Hares <>
Thread-Topic: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)
Date: Fri, 12 Feb 2021 15:04:18 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/related; boundary="_005_283a4847d02a444c9cfdbd31cf313485huaweicom_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Feb 2021 15:04:30 -0000

Hi Robert,

ORF is used for reduce the pressure on the receiver.
The receiver device, such as the access router, may have weak performance, while the sender device, such as the RR, may have strong performance.
Therefore, it is sometimes not enough to filter packets at the receiver.

The ORF is a tool and does not exist independently. The deployment problem described here occurs only when the RD-ORF mode is used.
Actually, the ORF can be used together with other ORFs, such as Prefixed ORF.
RD-ORF provides a more efficient filtering method, making solution deployment more flexible.

In fact, most vendors' devices support rd-filter, but only support the configuration.

In addition, if the RR decides to push the RD-ORF to its route source only when PE1 and PE3 do not want that RD.


From: Idr [] On Behalf Of Robert Raszuk
Sent: Friday, February 12, 2021 7:30 PM
To: Gyan Mishra <>
Cc: idr@ietf. org <>; Susan Hares <>
Subject: Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)

Aijun & Gyan,

Let me try one more (hopefully last time) to explain to both of you - and for that matter to anyone how supported this adoption.

Let's consider very typical Hub and Spoke scenario as illustrated below:


HQ1 is advertising two routes:

- one default with RDX1 with RT TO_SPOKE
- one or more specifics with RDX1 to the other HUBs

Now imagine HQ1 bought a new BGP "Optimizer" and suddenly is starting to advertise 100000 /32 routes just to the other HUB with RT: TO_HUB.


So PE2 detects this as VRF with RDX2 on it got overwhelmed during import with RT TO_HUB and starts pushing RDX1 (original RD) to RR to stop getting those routes.

Well all great except now you are throwing baby with the water as all spokes attached to PE2 which just import default route to HUB HQ1 also can no longer reach their hub site as their default route will be removed. Therefor they will have nothing to import with RT:TO_SPOKE

Further if RR "independently" decided ... oh let's push this ORF to PE1 then all of the spokes attached to perhaps even much more powerful PE3 can also no longer reach their headquarters.

- - -


The above clearly illustrates why the proposed solution to use RD for filtering is in fact harmful.

See when you design new protocol extensions the difficulty is to not break any existing protocols and deployments.

Hope this puts this long thread to rest now.