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

Gyan,

I am describing capabilities of the protocol. You are just describing some
current implementations. There is significant difference between both of
those paradigms.

Thx,
R.

On Wed, Aug 24, 2022 at 7:20 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:

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