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

Hi Robert

On Wed, Aug 24, 2022 at 4:12 AM Robert Raszuk <robert@raszuk.net> wrote:

> All,
>
> "RTC can only filter the VPN routes from the uninterested VRFs, if the
> "offending routes" come from the interested VRF, RFC mechanism can't filter
> them."
>
> That is not correct.
>
> Kindly observe that indeed RTC signals interested RTs. However when some
> of the routes from those interested VRFs are no longer needed (or undesired
> from the perspective of route overflow this entire discussion is all about)
> RTC can incrementally withdraw one or more interested RTs hence effectively
> apply required filtering.
>

    Gyan> RTC tracks the RT membership on the PE to RR peering so as long
as the PE is importing the RT all prefixes with the RT membership are
imported.  That’s it.  So now if the PE RIB overflows and starts dropping
prefixes out of the local VRF RIB on the PE, RFC 4684 does not provide any
signaling back to the RR to stop advertising prefixes that are part of the
RT membership explicitly imported into the VRF.  The only way to signal the
RR to stop sending prefixes related from an offending source PE is with
this draft.

>
> It is only a matter of how RTs are allocated to allow fine granularity of
> needed control using RTC.
>
> It is also incremental both in filter propagation and in fact in actual
> update or withdraws of SAFI 128 propagation which is a huge advantage over
> ORF like brute force method.
>
> So bottom line - what this draft is all about and what three adoption
> calls are all about can be easily achieved in multi vendor running code
> today. it is just a matter of correct device/network configuration + local
> behaviour to auto detect which routes should be yanked.
>
> Many thx,
> Robert
>
>
>
> On Wed, Aug 24, 2022 at 5:32 AM 王巍 <weiwang94@foxmail.com> wrote:
>
>> Hi Linda,
>>    Thanks for your comments, and please see my reply inline.
>>
>> Best Regards,
>> Wei
>> ------------------ Original ------------------
>> *From:* "Linda Dunbar" <linda.dunbar@futurewei.com>;
>> *Date:* Wed, Aug 24, 2022 02:26 AM
>> *To:* "Susan Hares"<shares@ndzh.com>;"idr@ietf.org"<idr@ietf.org>;
>> *Subject:* Re: [Idr] Adoption and IPR call for
>> draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)
>>
>> Wei, Aijun, et al,
>>
>>
>>
>> I forget to include the questions about draft at my last support message:
>>
>>    1. Page 3 says:
>>
>>  if the "trashing routes" come from the interested VRF, filter on RTs
>> will erase all prefixes from this VRF.
>>
>>
>>
>> why erase all prefixes even if the “trashing routes” only contain a
>> subset of prefixes for the VRF?
>>
>>  [WW] RTC aims to tell the peer "I want to receive VPN routes with RTx",
>> if the offending routes carry RTx, RTC can't tell the peer to stop sending
>> these routes unless withdraw the entry with RTx.
>>
>> How about the following updated sentence?
>>
>> "RTC can only filter the VPN routes from the uninterested VRFs, if the
>> "offending routes" come from the interested VRF, RFC mechanism can't filter
>> them."
>>
>>    1. Is the ORF message sent to all peers? Or just a selective peers?
>>
>> “each of them makes a local judgement to determine whether it needs to
>> send VPN Prefix ORF to its peers.”
>>
>> [WW] Thanks for pointing out this typo, it should be changed to "each of
>> them makes a local judgement to determine whether it needs to send VPN
>> Prefix ORF to its *upstream peer*."
>>
>> NITs:
>>
>> Past 6: (you need to do a global change.)
>>
>> past à passed:
>>
>> When routes associated with <RD31, PE3> tuple past the quota but the
>> prefix limit of VPN1 VRF is not exceeded,
>>
>> [WW] Thanks, will correct this typo in next update.
>>
>>
>>
>> Linda Dunbar
>>
>>
>>
>> *From:* Linda Dunbar
>> *Sent:* Tuesday, August 23, 2022 11:03 AM
>> *To:* Susan Hares <shares@ndzh.com>; idr@ietf.org
>> *Subject:* RE: Adoption and IPR call for
>> draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)
>>
>>
>>
>>
>> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*