Re: [Idr] draft-wang-idr-vpn-routes-control-analysis (was Re: rd-orf problem clarification at the local level)

[Aijun Wang <[e-mail]>]

Hi, Robert:

Your proposal just let RTC act as the behavior of RD-ORF. 
I think no one will agree with you.

I think what Jeff’s proposal is to utilize the information from RTC to let the RR decide when to send out the RD-ORF message on behalf of its peers, not to change the behavior of RTC.


Aijun Wang
China Telecom

> On Feb 26, 2021, at 18:48, Robert Raszuk <[e-mail]> wrote:
> 
> Gyan,
> 
> What you said is pretty obvious I think to everyone here.
> 
> But I think the point of bringing RTC into this picture was a bit
> different.
> 
> Just imagine RTC is running between PE and RR and signals interest in set
> of RTs to the RR. Let's say those RTs are RT100, RT200, RT300, RT400, RT500
> 
> Further imagine one VRF importing RT200 overflows on said PE with incoming
> (pre-import routes of RD_FOO and RT100, RT200 and RT 300).
> 
> So what if now PE via RTC will simply readvertise interest to get RT200
> with new BGP attribute say called BLOCK_RD and lists in such attribute body
> Route Distinguisher of RD_FOO ?

[WAJ] The action on RR then will be advertised VPN routes that with RT200, but the RD part is not RD_FOO?


> 
> The overall mission accomplished. No need for any new ORF type. It can be
> even transitive if we apply a little hack and adjust the way RR will select
> the best path for RTC (meaning include this attribute in advertisements
> only if all peers sending RT200 attached it with such RD_FOO).

[WAJ] Normally RTC message will be flooded within the network immediately . Your proposal here just let it wait responses from all its peers. If so, why using BGP UPDATE message?

> 
> To me this is very simply RTC extension and it seems solves this entire
> "problem".
> 
> And no - by proposing the above I am not changing my mind that it is simply
> wrong network operation to even allow such problem to happen in the first
> place.
> 
> Best,
> R.
> 
> 
>> On Fri, Feb 26, 2021 at 4:52 AM Gyan Mishra <[e-mail]> wrote:
>> 
>> 
>> Hi Jeff
>> 
>> Keep in mind that RTC is an optimization that does not apply to every
>> scenario especially in cases where all PEs have all the same VPNs defined
>> with explicit RT import.  The special cases were RTC does apply is for
>> incongruent VRFs in cases of a sparse RT distribution graph where PEs don’t
>> all import the same RTs.  By default all PE have RT filtering enabled by
>> default meaning if their is not an explicit VRF definition to match and
>> import the RT, the RT is dropped.  With RTC the distribution graph of what
>> RTs are advertised RR-PE is now optimized with RT membership, and now  only
>> RTs explicitly imported by the PEs are now advertised by the RR to PE for
>> processing.  In the case of RD-ORF, it provides a layer of needed
>> granularity as the RD PE originator of the flood is a subset of all the VPN
>> prefixes represented by the RT permitted by RTC to be advertised to the
>> PE.  The RD-ORF now dynamically blocks the offending PE prefixes that would
>> otherwise have been advertised by RTC RR to PE and accepted by the PE for
>> processing and added to the VRF RIB being overloaded.
>> 
>> 
>> Kind Regards
>> 
>> Gyan
>> 
>> On Thu, Feb 25, 2021 at 6:21 PM Aijun Wang <[e-mail]>
>> wrote:
>> 
>>> Hi, Jeff:
>>> Thanks for your suggestions!
>>> I think combine RTC and RD-ORF information can accomplish the fine
>>> control for the upstream propagation of unwanted VPN routes.
>>> We will also try to find other ways to achieve the same effect.
>>> 
>>> Aijun Wang
>>> China Telecom
>>> 
>>>> On Feb 25, 2021, at 22:01, Jeffrey Haas <[e-mail]> wrote:
>>>> 
>>>> Aijun,
>>>> 
>>>> On Thu, Feb 25, 2021 at 12:07:49PM +0800, Aijun Wang wrote:
>>>>>> In the prior discussions, it was clear that remediation was trying to
>>> be
>>>>>> done on a per-RD basis.  The text in this draft seems to be a larger
>>> scope
>>>>>> than that; perhaps per VPN (and thus route-target?).  Is that your
>>>>>> intention?
>>>>> [WAJ] Yes. We are considering to add RT information to the current
>>> RD-ORF
>>>>> semantic, to identify/control the "excessive routes" in more granular