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

[Igor Malyushkin <[e-mail]>]

>  Not sure what you mean.
I just meant that the authors probably are afraid to link to RTs because
several VRFs on the same PE can share some RTs. But...

>  Allocating one more to determine the src VRF is trivial. If at all
needed :)
... indeed, it is much better than a new special community!

ср, 24 авг. 2022 г. в 21:23, Robert Raszuk <[e-mail]>:

> 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 <[e-mail]>
> 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 <[e-mail]>:
>>
>>> 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 <[e-mail]>
>>> 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=
>>>> [e-mail]>:
>>>>
>>>>> 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:[e-mail] <[e-mail]>] *On
>>>>> Behalf Of *Susan Hares
>>>>> *Sent:* Tuesday, August 16, 2022 11:56 PM
>>>>> *To:* [e-mail]
>>>>> *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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/idr
>>>>>
>>>> _______________________________________________
>>>> Idr mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/idr
>>>>
>>>