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

Aijun Wang <> Thu, 11 February 2021 15:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB4333A1696 for <>; Thu, 11 Feb 2021 07:22:52 -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_MESSAGE=0.001, MIME_QP_LONG_LINE=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=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YnnarDBclD2E for <>; Thu, 11 Feb 2021 07:22:50 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 16A3C3A0BDB for <>; Thu, 11 Feb 2021 07:22:50 -0800 (PST)
Received: from [] (unknown []) by (Hmail) with ESMTPA id 87EF71C0180; Thu, 11 Feb 2021 23:22:37 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-76B39D1C-405B-4164-9D03-FB238CF3BA36"
Content-Transfer-Encoding: 7bit
From: Aijun Wang <>
Mime-Version: 1.0 (1.0)
Date: Thu, 11 Feb 2021 23:22:36 +0800
Message-Id: <>
References: <>
Cc: "Jakob Heitz (jheitz)" <>, Susan Hares <>,, "Acee Lindem (acee)" <>
In-Reply-To: <>
To: Robert Raszuk <>
X-Mailer: iPhone Mail (18D52)
X-HM-Tid: 0a7791afdc77d993kuws87ef71c0180
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: Thu, 11 Feb 2021 15:22:53 -0000

Hi, Robert:

Aijun Wang
China Telecom

> On Feb 11, 2021, at 20:29, Robert Raszuk <> wrote:
> > What will you do in the scenarios that described in this draft ?
> As already stated the solution which is deployed in production networks to prevent scenario described in the draft is not to allow "overwhelming" amount of routes to enter your network from any VPN. 
> When you sell VPN service you agree with customers how many routes they will be injecting into your network. In many cases you even ask for specific routes which you apply ingress policy to make sure only those prefixes as expected enter your network. 
> Same on PE-CE some on Inter-AS option A, B or C or mix of any of the above.
> Now if all of the above is not done or done with mistakes and you indeed experience to many routes to be handled by data plane you stop locally importing those routes to local VRFs by VRF shutdown. The good thing here is that this will be noticed by all attached customers as their dynamic routing will propagate withdraws. 
[WAJ] The BGP session is shared by several VPNs and cannot be shutdown in such situations. Procedures that you expect would not happen.
> If you are concern that the control plane is not going to keep up you apply locally inbound drop based on whatever criteria you like (RT, RD etc ...) and raise alarms and again propagate withdraws to locally attached CEs or peer's ASBR. 
[WAJ] Locally drop is not enough, as that described in, as the following:

“Currently, it is not uncommon for a BGP speaker [BGP-4] to receive, and then filter out some unwanted routes from its peers based on its local routing policy.  Since the generation and transmission of routing updates by the sender, as well as the processing of routing updates by the receiver consume resources, it may be beneficial if the generation of such unwanted routing updates can be avoided in the first place.”

> So I am pretty sure none of the suggested by WG tools which have been in place are going to be sufficient for you. So at this point I will let IDR chairs and AD to decide on the next steps fwd. 

[WAJ] Let’s discuss first on the mail list. We just want the network can respond quickly and automatically for some abnormal situations. RD-ORF is one feedback mechanism that can be utilized. 

> Many thx,
> Robert