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

[Robert Raszuk <[e-mail]>]

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.

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 王巍 <[e-mail]> wrote:

> Hi Linda,
>    Thanks for your comments, and please see my reply inline.
>
> Best Regards,
> Wei
> ------------------ Original ------------------
> *From:* "Linda Dunbar" <[e-mail]>;
> *Date:* Wed, Aug 24, 2022 02:26 AM
> *To:* "Susan Hares"<[e-mail]>;"[e-mail]"<[e-mail]>;
> *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 <[e-mail]>; [e-mail]
> *Subject:* RE: Adoption and IPR call for
> draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)
>
>
>
>
>