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 18:19, Robert Raszuk <[e-mail]> wrote:
> 
> 
> Hi,
>  
>> [WAJ] As Jim also mentioned, the redistribution between different VRFs is poor design and we should avoid it in first place.
> 
> What Jim pointed out is the scenario where your proposal misses to address. I do not see there claim that vrf to vrf route propagation is a poor design. 
> 
> But this is just to prove your proposal is incomplete to protect PE from being overwhelmed with VPN routes. Even basic import to more then one VRF every operator (example mgmt VRF) is using can not be addressed by your proposal. 
[WAJ] As mentioned in https://mailarchive.ietf.org/arch/msg/idr/_1vhNMPlyA7CHrdau15PjMAeDPM/, we have described the solution that you concerned. 
Why you trimmed the already mentioned solutions?

> 
>> Or, is the responses for Jakob addressing your concern?
> 
> No. Mechanism is defined if you want to break the VPN service use it. 

[WAJ] Would you like to keep the context of the responses? My above question is just for your mentioned prefix-based ORF.

> 
> > The problem with maximum prefix is it is hard to set a limit on the maximum due to resources statistical multiplexing that all PE-CE links  of VPNs won’t flood simultaneously thus maximum prefix is either set very high or not set at all.
> 
> This point one needs to put things in perspective. If your capacity of PE is 10 M VPN routes and your VPN is giving you 10 routes per site then even if you set 100 max prefix to 100 no harm will happen. That is how max prefix is deployed with proper warning threshold and then session drop as last resort. The point is to protect from accidental mistakes - that's all.  
[WAJ] RD-ORF has also the same aim. It is used when the session be multiplexed by several VPN and can’t be dropped scenarios.
> 
> > So if a PE VRF is overflowing we cannot filter prefixes based on RT for the overflowing VRF as that would filter all routes.
> 
> If VRF is "overflowing" you apply vrf-limit feature which is completely different then max-prefix on BGP sessions. You may even shut down such VRF completely which would be way better then partially drop the routes in it. See in IP networks partially broken reachability is much worse to troubleshoot then completely broken. Just imagine hours of troubleshooting when customer calling your NOC complains his app is not working when ping and trace are perfectly fine. In most cases NOC will say it is application issue Mr customer pls go home. 
[[WAJ] When the VRF-limit is exceeded, it will trigger of RD-ORF message in the discussed scenarios. It adds another tool to control the  propagation of overwhelmed VPN routes.

> 
> We really here in IETF should not be endorsing such completely broken operational models. 

[WAJ] Only the communications between overwhelmed PE and other PEs will be influenced, there will be log/alarm sent to NMS when the RD-ORF message is sent, which is similar with other existing mechanisms.
What will you do in the scenarios that described in this draft? Break the shared BGP session completely? That’s definitely unacceptable. Sending warning messages but can’t give the clues which VPN or RD arises this issue? It’s still useless.
The potential problem is existing, we should find one proper solution. Wish to hear more constructive proposal from you for this.

> 
> Kind regards,
> Robert.
>