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 Wei,

Thanks for explaining. All these statements were repeatedly posted on the
list before. To prevent this discussion for infinity looping I will stop. I
believe WG has an excessive amount of information to think about.
Thank you and the rest participants for an interesting discussion.

ср, 31 авг. 2022 г. в 15:02, Wei Wang <[e-mail]>:

> Hi All,
>
>
>     The updated draft is the fruit of previous intense discussions, we
> have analyzed various possible situations. Let me explain some major
> concerns again:
>
>
> 1) About the quota:
>    Actually, the quota is not exist in the original version, but we found
> there are some problems during the discussions in the mailing list. So, we
> add the quota to improve the drop strategies after the VPN Prefix ORF
> mechanism is triggered. We can't drop all the routes(from all sources)
> belong to the VPNs when the VRF limit is exceed because one of the rogue PE.
>     The reason that quota is set for every PE is that in real network the
> number of customer routes in each VPN under different PEs may be different.
> So, the quota value should be set depend on the customer scale.
>    For more information about quota, I think you can refer the discussion:
> https://mailarchive.ietf.org/arch/msg/idr/uoQO8vqSA82UCrfXppFjwNbMg1A/
>
>
> 2) About the proposal for sending the ORF message directly to the source:
>    I think scenario-1 and scenario-2 in the updated draft (
> https://datatracker.ietf.org/doc/html/draft-wang-idr-vpn-prefix-orf#section-4.1)
> have described the cases that it is not approciated to stop the source
> advertisement directly based on the VPN Prefixes ORF message from only one
> PE. There may be other complex scenarios.
>    And on the other hand, the VPN Prefixes ORF message is triggered when
> the Quota and VRF limit threshold are both exceeded. It is possible that
> the Quota on all PEs is same, but the VRF limits are different. Then the
> weak PE may first trigger the VPN Prefixes ORF message, but the other PE
> can still receive some amounts of excessive routes. In such case, VPN
> Prefixes ORF message should not be sent directly to the source.
>
>
>
> And please also see my reply to Igor's concern inline with [WW].
>
>
>
> Best Regards
> Wei
>
> ------------------ Original ------------------
> *From:* "Igor Malyushkin" <[e-mail]>;
> *Date:* Wed, Aug 31, 2022 05:49 PM
> *To:* "Robert Raszuk"<[e-mail]>;
> *Cc:* "idr"<[e-mail]>;"John E Drake"<jdrake=
> [e-mail]>;"Sue Hares"<[e-mail]>;
> *Subject:* Re: [Idr] Adoption and IPR call for
> draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)
>
> 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.
> [WW] Theoretically, B can keep A’s routes that pass the quota(99 in your
> example) for a short time even it exceeds the VRF limit(200), until there
> are other routes coming from other source. But such design will make the
> implementation more complex: B needs to calculate whether the excessive
> routes from the original source or new source.
> Actually, A has occupied the extra resources(99 routes)for some time, it
> is time to release the source they occupied when the VRF limit is exceeded,
> to leave space for routes from other sources.
> The overall principle is that the system has some tolerances until they
> cross the predefined criteria.
>
> 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
>>
>