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

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