Re: [Idr] New Version Notification for draft-wang-idr-rd-orf-03.txt

[Aijun Wang <[e-mail]>]

Hi，Robert:

Aijun Wang
China Telecom

> On Aug 28, 2020, at 15:19, Robert Raszuk <[e-mail]> wrote:
> 
> 
>> By day one design L3VPNs or L2VPNs are overloading all PEs to parse and drop all BGP updates which do not carry routes containing at least one intersecting RT.
>> 
>> [WAJ]  But until now, various filter policies for the unnecessary BGP updates has been added, do you agree?
>> 
> 
> There is a difference between "unnecessary" and those which are caused by wrong service deployment. 


[WAJ] Isn’t it better to release you from such risk?

> 
>> [WAJ] Yes, RD-ORF can also be used within the device, but push the policy to its upstream peer or final to the overwhelming source is better.
>> 
> 
> This is one of the biggest issue I have with this draft. ORF is not transitive and you are making it transitive (even if you pretend it is not). 

[WAJ]: As mentioned earlier, we have updated the draft to state clearly the RD-ORF is non-transitive. Such message will only be received by the overwhelming source when all the nodes along path decide to do such actions. These devices make their decision independently.

> 
> I am not against automated filtering (where it make sense), but if so pls do it correctly. Define a new SAFI just like we did with RTC, call it RDC (RD Constrained) and use it at your own risk to break VPNs in your network. 

[WAJ] Please consider also the inter-as scenarios together.
> 
> While there custom update generation especially based on more then one constraint has a high cost. You need to generate update per each such peer individually walking full vpnv4 table. Dropping is cheap. Replication is cheap. Keep this in mind pls so your vendor's implementation engineers have easy life :). 

[WAJ] There are works needs to be done before dropping the VPN routes. Isn’t such back pressure better than the devices do useless work?

> 
> Cheers,
> R.