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

[Robert Raszuk <[e-mail]>]

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.

Or, is the responses for Jakob addressing your concern?
>

No. Mechanism is defined if you want to break the VPN service use it.

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

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

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

Kind regards,
Robert.