Re: [Idr] Adoption and IPR call for draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)

[Igor Malyushkin <[e-mail]>]

Hi all,

I agree with Robert and John, I`ve expressed concerns about quotas several
times on this list. This construction is overcomplicated and unnecessary,
IMO. I know the authors` intention is to make things better in a case of a
VRF overflowing, but I want to point them to the fact that this case is
exceptional by the definition. We don`t face this problem on a daily basis.
When it happens human intervention is still required in any case. Thus, I
think we should concentrate our attention on the crux of the problem.

As I also said, I agree that we don`t need to receive routes in the case a
VRF is overflowed. We cannot exclude from the consideration the claims when
several PEs are "rogue" at the same time, so a destination PE needs to
process several groups of UPDATEs, then send ORF for every source, then
process UPDATEs with withdrawals. Multihoming is just one case from this
class. I believe it`s possible just to stop all UPDATEs for a VPN at the
same time (which the authors partially approved for the multihoming case).
Thus, we enhance a local VRF prefix limit feature without needing quotas,
source identification, and the rest of the complexity. I suggested the
authors include this option in the draft so implementors can decide which
approach is appropriate. Their favorite vendor can implement the draft with
quotas, others can do it too or not. This is not prone to interop problems
if it is inscribed well in the document.

Quotas are not only complex from the operational point of view. Although,
this is also important and frustrating. I still don`t agree that we need to
delete some routes from a VRF. Let`s imagine we have a quota for router A
on router B`s VRF of 100 routes, also there is a VRF prefix limit of 200
routes. At T1 we receive 100 routes from A, all of them are under the quota
and are valid. At T2, we receive extra routes from the A, say, 99 routes.
Router B warns ops via a logging system, but are these routes excessive?
Router B doesn`t send an ORF message because the VRF prefix limit is not
reached. At T3 we have 199 routes from the A in the VRF and receive another
group of 2 routes from the A. Now we`ve reached the limit. Router B sends
the ORF message and asks RR to withdraw of 101 route. But why? Why do these
2 routes make the previous 99 excessive? This logic is not straightforward
to me. Either don`t install routes over a quota or don`t delete them after
it. Even if we stay it in the draft future implementations won`t be easy to
understand by people.

My 2 cents.

ср, 31 авг. 2022 г. в 08:46, Robert Raszuk <[e-mail]>:

> Dear Aijun,
>
> Sorry but I simply can't resist it ...
>
> On Wed, Aug 31, 2022 at 1:54 AM Aijun Wang <[e-mail]>
> wrote:
>
>> Hi, John:
>>
>> Glad to hear your concerns. Let me explain them to you:
>> 1) There are various reasons that the receiving PE is overflowed by the
>> excessive VPN routes. For example, the capabilities of PEs within the
>> network are different, we can’t block the source directly just solely based
>> on the request from one PE.
>>
>
>
> What you just stated above is simply the wrong thing to do in fact
> irrespective where the drop of the routes would take place in the network.
>
> If capacity of any PE does not permit serving given VPN such VPN should
> not be provisioned on such PE.
>
> Adding protocol extensions to address provisioning mistakes (not
> accidental as stated above but well thought onboarding of a VPN to a
> network) and in the same time partially breaking connectivity within
> subject VPNs should not be endorsed by any IETF WG.
>
> In fact what you have stated above is a clear proof that we do not even
> have a well defined problem statement. All we have is a solution which here
> and there in the network breaks VPN connectivity.
>
>
> > 2) For the quota setting, actually, the operator need only the per PE
> resource allocation under one VRF, and in most of
> > the situations, such per PE allocation will be same for one VPN in every
> PE
>
> You mean under each VRF on each PE.
>
> And please explain how that new number should be different from today's
> VRF prefix limit ? Why there is need to introduce new limit?
>
> Thx,
> R.
>
>> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>