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

[王巍 <[e-mail]>]

Hi Robert,


The offending VPN routes are dropped because they pass the predefined quota threshold, it’s the similar behavior for “BGP maximum prefixes” mechanism.
Before dropping, the device can also send the alarm signal to operator.


Dropping them can assure the offending VPN routes does not affect the receiving and parsing of routes belong to other VPNs.
The updated VPN Prefixes ORF mechanism filter the routes not solely based on RD or prefix.



Best Regards,
Wei
------------------ Original ------------------
From:                                                                                                                        "Robert Raszuk"                                                                                    <[e-mail]&gt;;
Date:&nbsp;Tue, Aug 23, 2022 04:46 PM
To:&nbsp;"Aijun Wang"<[e-mail]&gt;;
Cc:&nbsp;"Susan Hares"<[e-mail]&gt;;"idr@ietf. org"<[e-mail]&gt;;"Zhuangshunwan"<zhuangshunwan=[e-mail]&gt;;
Subject:&nbsp;Re: [Idr] Adoption and IPR call for draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)



Aijun,

&gt; Wish it can help for you to flip the page.



I recall this thread, but it did not "flip the page".&nbsp;


See dropping VPN routes when CE points default to a PE (very common case) will just result in less specific forwarding (potential loops as IBGP becomes inconsistent now) or at best silent drops at the PEs. Authors somehow forgot that it is a really bad idea and very unsafe to drop valid routes on IBGP.&nbsp;


Note that non intersecting RT based drop is safe. But not per prefix or per RD&nbsp;drops !&nbsp;


Besides if we are talking at scale to do what you are describing requires lots of real time per path per vrf stats. That's a CPU burden which is completely unnecessary.&nbsp;


&gt; And, the deny-focusing mechanism (VPN Prefixes ORF) acts differently from the allow-focus mechanism (RTC).



You missed my point.&nbsp;


While RTC today indeed expresses the list of required RTs nothing stops you to define RTC-like AF based propagation with deny semantics.&nbsp;


Thx,
Robert.




On Tue, Aug 23, 2022 at 3:56 AM Aijun Wang <[e-mail]&gt; wrote:


Hi, Robert:

&nbsp;

For your concerned points regarding to the ordering of path, I recommend that you review again our discussion with Jeffrey Haas on various scenarios at https://mailarchive.ietf.org/arch/msg/idr/uoQO8vqSA82UCrfXppFjwNbMg1A/. Wish it can help for you to flip the page.

&nbsp;

And, the deny-focusing mechanism (VPN Prefixes ORF) acts differently from the allow-focus mechanism (RTC). The former should be decided based on each hop itself, and should not be propagated further unconditionally, as that done in RTC mechanism. We don’t want to repeat the discussed points again.

&nbsp;

Best Regards

&nbsp;

Aijun Wang

China Telecom

&nbsp;

From: Robert Raszuk <[e-mail]&gt; 
Sent: Sunday, August 21, 2022 8:00 PM
To: Aijun Wang <[e-mail]&gt;
Cc: Susan Hares <[e-mail]&gt;; idr@ietf. org <[e-mail]&gt;; Zhuangshunwan <zhuangshunwan=[e-mail]&gt;
Subject: Re: [Idr] Adoption and IPR call for draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)

&nbsp;

Aijun,

&nbsp;


Actually I did read the -03 version of the draft and changes made actually make it even less attractive.&nbsp;


&nbsp;


Let's first establish what is the format of the ORF message you are proposing to advertise and when those&nbsp;optional TLVs are added ?&nbsp;


&nbsp;


Quote 1 - PE2 triggers the VPN&nbsp; Prefix ORF message (RD1, RT1, comes from PE3).


&nbsp;


Quote 2 -&nbsp;VPN Prefix ORF entry&nbsp;(RD31, RT1, RT2, comes from PE3)


&nbsp;


Your email suggest that "and global allocation(in this case, the source PE will be attached)"


&nbsp;


There is no clear and exhaustive definition when each defined TLV (Source PE or RT) needs to be added&nbsp;by the node generating this new ORF message.&nbsp;


&nbsp;


It is fascinating that you have now added a list of RTs to the spec. We argued from the beginning that a list of RTs offers a good solution for such filtering and&nbsp;RTC RFC4684 can be used instead.&nbsp;


&nbsp;


More inline ...&nbsp;


&nbsp;



#1 - RD allocation can be per VRF or Global in a given VPN. This scheme works only in the case of per VRF allocation.&nbsp;




[WAJ]The proposed mechanism works both in per VRF allocation and global allocation(in this case, the source PE will be attached)



&nbsp;


&nbsp;


How do you handle multipaths ? How do you handle anycast ? How do you determine the src PE ?&nbsp;


&nbsp;


Please observe that during import there is no ordering of paths. So when you are just about to reach the vrf prefix limit and 95% of imported routes come from PE1 suddenly the vrf prefix limit is exceeded when just a few paths arrive from PE2. Are you now going to suppress those few routes as they were unlucky and happened to exceed the prefix limit ?&nbsp;


&nbsp;


&nbsp;


#3 - Use of prefix ORF can be applied where prefix is just /64 RD without any new draft. The draft says:&nbsp;


&nbsp;


&nbsp; &nbsp;Using Address Prefix ORF to filter VPN routes need to pre-
&nbsp; &nbsp;configuration, but it is impossible to know which prefix may cause
&nbsp; &nbsp;overflow in advance.


&nbsp;


&nbsp; &nbsp; .. which clearly is not correct as irrespective on the encoding you need to know what RD to push.&nbsp;


&nbsp; &nbsp; Here in this context&nbsp;of RFC5292 PREFIX == RD == /64 PREFIX





[WAJ] This point has been discussed throughly in the first round discussions. The key answer is that you cannot know in advance which RD will cause the overflow VPN routes. And one more point again, current VPN ORF prefixes doesn’t depend only the automatic extracted RD information.&nbsp;




&nbsp;


No one is saying you need to know this in advance. Sure questionable source PE and RTC like list of RTs will not fit RFC5292.&nbsp;


&nbsp;


While we are at this, asking anyone to configure a list of <src RDs+src PEs&gt; limits on each PE is beyond even commenting on.&nbsp;


&nbsp;


#4 - Change of ORF list results in advertisement of ALL routes of a a given AFI/SAFI to the peer.&nbsp;


&nbsp; &nbsp; &nbsp; &nbsp; That is the same irrespective if IMMEDIATE or DEFER flags are set. That puts burden on the peer especially in&nbsp;


&nbsp; &nbsp; &nbsp; &nbsp; VPN cases when the number of routes may be high.&nbsp;





[WAJ] What you described is the current ORF mechanism. There are some spaces to optimize it.




&nbsp;


&nbsp;


Yes this is how ORF works.&nbsp;


&nbsp;


And I don't think there is any consensus&nbsp;to break it.&nbsp;


&nbsp;


Actually looking at your -03 version I have a suggestion.&nbsp;


&nbsp;


Forget about hacking ORF. Just use new SAFI and push those policies in the new address family. Just like we did with RTC. And please do not try to fix RTC :) Leave it alone and transfer your policy to new AFI/SAFI advertisements.&nbsp;


&nbsp;


It will also be automatically transitive so you should have much better coverage with that.&nbsp;


&nbsp;


Alternatively you may find some traction to add this into Flowspec v2 work.&nbsp;


&nbsp;


Kind regards,


Robert


&nbsp;