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

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