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

[Aijun Wang <[e-mail]>]

Hi, Robert:

Aijun Wang
China Telecom

> On Feb 11, 2021, at 20:29, Robert Raszuk <[e-mail]> 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 https://tools.ietf.org/html/rfc5291#section-1, 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
> 
> 
> 
> 
>