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

Hey Igor,

> But I think if we have a mechanism that allows us to attach several RTs
to a route we are in a trouble.

Not sure what you mean.

In almost all large scale VPN deployments I have seen VPN routes carry lots
of RTs for various reasons. Allocating one more to determine the src VRF is
trivial. If at all needed :)

> I also don't understand the benefits behind quotas per VRF-PE pair,

It is a very bad idea from multiple perspectives. We already have a VRF
limit and PE-CE prefix limit. If both are set wisely VPNs are sufficiently
protected today. And large carriers do confirm this.

IMO resource starvation of any PE is a local matter and should not be
propagated anywhere. In fact various factors determine the run
time capacity of any PE. So any limits (if at all) should be just global
and expressed in percentage of overall PE capacity. That way even software
bugs like memory leaks could be factored in.

But the real problem those folks are trying to patch are wrong provisioning
practices and no merci for some VPNs due to that.

Rgs,
R.

On Wed, Aug 24, 2022 at 9:14 PM Igor Malyushkin <gmalyushkin@gmail.com>
wrote:

> For sure it is design-depended. If every VRF has its own RT it will work.
> But I think if we have a mechanism that allows us to attach several RTs to
> a route we are in a trouble. Guys are just typing to cover this case.
>
> If we talk in general about a whole solution I also think that the way
> with the new AFI/SAFI is much better. I also don't understand the benefits
> behind quotas per VRF-PE pair, but if it is really worth the time I expect
> to see the propagation of these quotas from source PEs instead of a manual
> configuration. I think it can be easily introduced into a solution with the
> new AFI/SAFI.
>
> ср, 24 авг. 2022 г. в 21:05, Robert Raszuk <robert@raszuk.net>:
>
>> Igor,
>>
>> RT can uniquely distinguish src vrf. It is simply a matter of
>> proper configuration. No ned protocol extension is required.
>>
>> Thx,
>> R.
>>
>> On Wed, Aug 24, 2022 at 9:03 PM Igor Malyushkin <gmalyushkin@gmail.com>
>> wrote:
>>
>>> Hi Haibo,
>>>
>>> 2) It is unpractical to set the quota value for <RT>, or <RT, PE> under
>>> VRF, because RT can't uniquely distinguish one VRF on one PE.
>>> What if a VRF has several RDs for its routes? RFC4364 and RFC4659 don't
>>> restrict this behavior and even more, it explicitly describes it. So, RD
>>> also can't uniquely distinguish one VRF. Looks like we need a different
>>> marker for all routes belonging to the same source VRF. Say, VPN ID
>>> community or something like that.
>>>
>>>
>>> ср, 24 авг. 2022 г. в 18:26, Wanghaibo (Rainsword) <rainsword.wang=
>>> 40huawei.com@dmarc.ietf.org>:
>>>
>>>> Hi Sue and WG,
>>>>
>>>>
>>>>
>>>> I support this adoption.
>>>>
>>>> This draft proposes the mechanism to control the overflow of VPN routes
>>>> within one VRF from influencing other VPNs on the same device
>>>> automatically.
>>>>
>>>>
>>>>
>>>> The updated contents have accommodated the suggestions and addressed
>>>> the comments raised within the WG discussions. Some additional concerns can
>>>> be addressed after the adoption.
>>>>
>>>>
>>>>
>>>> I am not aware of any undisclosed IPR to this draft.
>>>>
>>>>
>>>>
>>>> To make the actual progress of this draft, we should avoid to discuss
>>>> the solved points back and forth. For example, RTC mechanism is not
>>>> suitable for the scenarios that described in this adoption draft, because:
>>>>
>>>> 1) RTC has no any automatic detection mechanism to determine which RT
>>>> should be withdrawn now.
>>>>
>>>> 2) It is unpractical to set the quota value for <RT>, or <RT, PE> under
>>>> VRF, because RT can't uniquely distinguish one VRF on one PE.
>>>>
>>>> 3) It is dangerous to propagate the RT based filter rule
>>>> unconditionally in the intra-domain or inter-domain wide, as that done in
>>>> current RTC mechanism.
>>>>
>>>>
>>>>
>>>> The conclusion, RTC is not the right direction to accomplish the goal.
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Haibo
>>>>
>>>>
>>>>
>>>> *From:* Idr [mailto:idr-bounces@ietf.org <idr-bounces@ietf.org>] *On
>>>> Behalf Of *Susan Hares
>>>> *Sent:* Tuesday, August 16, 2022 11:56 PM
>>>> *To:* idr@ietf.org
>>>> *Subject:* [Idr] Adoption and IPR call for
>>>> draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)
>>>>
>>>>
>>>>
>>>> This begins a 2 week WG Adoption call for
>>>> draft-wang-idr-vpn-prefix-orf-03.txt
>>>>
>>>> https://datatracker.ietf.org/doc/draft-wang-idr-vpn-prefix-orf/
>>>>
>>>>
>>>>
>>>> The authors believe that they have addressed the concerns raised in
>>>>
>>>> the previous 2 WG adoption calls.
>>>>
>>>>
>>>>
>>>> The WG should consider if:
>>>>
>>>>
>>>>
>>>> 1) The revised text answers the previous concerns regarding
>>>>
>>>> the scope of this draft?
>>>>
>>>>
>>>>
>>>> 2) Does the revised text provide a useful function for
>>>>
>>>> networks?
>>>>
>>>>
>>>>
>>>> 3) Are there any additional concerns regarding the new text?
>>>>
>>>>
>>>>
>>>> Each of the authors should send an IPR statement for
>>>>
>>>> this version of the draft.
>>>>
>>>>
>>>>
>>>> The adoption call was moved to 8/29 to 8/30 to allow questions
>>>>
>>>> to be asked at the IDR interim meeting on 8/29/2022 (10am – 12pm EDT).
>>>>
>>>>
>>>>
>>>> Cheers, Sue Hares
>>>> _______________________________________________
>>>> Idr mailing list
>>>> Idr@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/idr
>>>>
>>> _______________________________________________
>>> Idr mailing list
>>> Idr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/idr
>>>
>>