Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)

[Aijun Wang <[e-mail]>]

Hi, Jakob:

Aijun Wang
China Telecom

> On Feb 12, 2021, at 10:56, Jakob Heitz (jheitz) <[e-mail]> wrote:
> 
> 
> The maximum-prefix configured on a BGP session is not designed to protect the router from too many routes.
> When you add up all the maximum-prefix amounts for each session, the total is much higher than the router can tolerate.
> There are other configuration knobs to protect the router from too many routes.
> The purpose of maximum-prefix is to guard against route leaks and other configuration errors from customer networks.
> It is not the only tool for that and it's not very good. But it does tell the customer in no uncertain terms that something went wrong. It's like a large hammer for a small screw. Or 杀鸡用牛刀.
> Now, you said before that you don't want to tell the source, so there's little point.

[WAJ] In some situations, the message can back to the source, although it is not always. This is also the gradual feature of RD-ORF mechanism 

Happy New Year to you or “新春快乐！”

Aijun Wang
China Telecom

>  
> Regards,
> Jakob.
>  
> From: Aijun Wang <[e-mail]> 
> Sent: Thursday, February 11, 2021 6:03 PM
> To: Jakob Heitz (jheitz) <[e-mail]>
> Cc: Robert Raszuk <[e-mail]>; Susan Hares <[e-mail]>; [e-mail]; Acee Lindem (acee) <[e-mail]>
> Subject: Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)
>  
> Hi, Jakob:
>  
> I think we can evaluate this mechanism frim other viewpoints: 
> We will definitely deploy BGP maximum-prefixes feature between two BGP peer, and will break the session if the receiver can’t tolerate. Right?
> The RD-ORF mechanism just wants to cope with such scenarios in more graceful/gradual way. 
>  
> 
> Aijun Wang
> China Telecom
> 
> 
> On Feb 12, 2021, at 09:23, Jakob Heitz (jheitz) <[e-mail]> wrote:
> 
>  "can" is not good enough. "can certainly" is not much better. "did" with backup is good.
>  
> Regards,
> Jakob.
>  
> 
> 
> On Feb 11, 2021, at 4:31 PM, Aijun Wang <[e-mail]> wrote:
> 
>  Hi, Jakob:
>  
> This is the start point of ORF mechanism, not only for RD-ORF. I think we can refer the description in https://tools.ietf.org/html/rfc5291#section-1.
> Locally discard is not enough. The excessive junk BGP Updates can certainly lead the high CPU usages of the affected PE, and let them react slowly to process the other normal BGP Updates, and then the communications of the other normal VPNs that on the shared BGP connection.
>  
> Aijun Wang
> China Telecom
> 
> 
> On Feb 12, 2021, at 08:16, Jakob Heitz (jheitz) <[e-mail]> wrote:
> 
> 
> Ajun,
>  
> Well, if that's all it is, then you should just drop the routes at the weak PE.
> You say that receiving and dropping is burdensome on the receiving router.
> Frankly, I don't believe you.
> Can you back that statement up and demonstrate how it has actually caused outages?
>  
> Regards,
> Jakob.
>  
> From: Aijun Wang <[e-mail]> 
> Sent: Thursday, February 11, 2021 4:01 PM
> To: Robert Raszuk <[e-mail]>
> Cc: Jakob Heitz (jheitz) <[e-mail]>; Susan Hares <[e-mail]>; [e-mail]; Acee Lindem (acee) <[e-mail]>
> Subject: Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)
>  
> Hi, Robert and Jakob:
> I think you all misunderstood the procedures of RD-ORF mechanism.
> The RD-ORF message doesn’t need to find its way back to the source to control the excessive VPN routes, the intermediate nodes, for example, the RR, or the ASBR can accomplish this work instead. 
> That is to say, if one PE can’t receive more routes from the RR, it just send the RD-ORF message to the RR. If RR has the capability to process the upcoming BGP UPDATES, it will not send another RD-ORF message to the source.
> Only the specified VPN communications between the weak PE and other health PEs will be influenced. The communications among the health PEs will be kept in good state.
>  
> Whether and when to send the RD-ORF message is determined independently by each involved nodes.
>  
> Let me also explain such behavior to you based your statements inline below.[WAJ]
>  
> Wish these explains can correct your understanding of RD-ORF mechanism.
> 
> Aijun Wang
> China Telecom
> 
> 
> 
> On Feb 12, 2021, at 04:39, Robert Raszuk <[e-mail]> wrote:
> 
> 
>  
> > You are trying to have a VRF that is receiving routes to notify a VRF that is sending routes that it is sending too many routes.
>  
> Well if that was true maybe we could try to make it work. But they are not doing this. 
>  
> See receiving VRF of RD:X can import routes from many other PEs/VRFs with zoo of RDs. So what they say is to be selective and say Oh this RD:FAT is sending way too many routes so we want to get rid of those routes. Moreover some PEs may be just weak and can trigger such dislike msg and some may be taking the routes with no problem. 
> 
> [WAJ] If the weak PE trigger RD-ORF message to RR, but other health PEs under this RR can process it, then when RR receives such message, it just filter the RD-specified VPN BGP updates to the weak PE, other health  PEs can still receive the specified VPN BGP updates and then got the RD-specified VPN routes(VPN:FAT in your example)
> 
> 
> 
>  
> What is being cooked here to me looks like a complete mess - that's all. 
>  
> [WAJ] Wish the above explanations can help you reorganize the imaginal but unreal mess.
> 
> 
> 
> Cheers,
> Robert
>  
>  
>  
>  
>  
>  
> On Thu, Feb 11, 2021 at 9:19 PM Jakob Heitz (jheitz) <[e-mail]> wrote:
> You are trying to have a VRF that is receiving routes to notify a VRF that is sending routes that it is sending too many routes.
> The receiving VRF and the sending VRF are separated by several or many intermediate BGP speakers.
> [WAJ] Yes, but controlling the VPN routes needn’t relay the RD-ORF messages back until to the source. There are many valves between them.
> 
> 
> Bouncing ORFs back through these intermediate speakers is not a reliable way to achieve this notification.
> [WAJ] Yes, we have avoided this approach.
> 
> 
> This is because each intermediate speaker has multiple downstream speakers.
> One speaker needs to receive the ORF from all of its downstream speakers before it can bounce the ORF upstream.
> [WAJ] Each intermediate speaker can control the valves to each RD-ORF message initiator.
> Whether and when send out its own RD-ORF message is determined by itself process capability, not related to the portion of downstream speakers emitted RD-ORF message. This is more flexible and deployable. 
> 
> 
> Thus, it's unlikely that the ORF will make it all the way to the source of the routes.
> [WAJ] Yes, we have abandoned this approach.
> 
> 
> You are asking for something like a reverse BGP.
> That can't scale.
> The way that we find out whether a far away speaker got our route correctly is with looking glasses.
> Looking glasses aren't implemented by BGP, because BGP operators don't want to store that kind of information.
> [WAJ] RD-ORF needs also not store that kind of information.
> 
> 
>  
> Regards,
> Jakob.
>  
> From: Aijun Wang <[e-mail]> 
> Sent: Thursday, February 11, 2021 8:12 AM
> To: Robert Raszuk <[e-mail]>
> Cc: Jakob Heitz (jheitz) <[e-mail]>; Susan Hares <[e-mail]>; [e-mail]; Acee Lindem (acee) <[e-mail]>
> Subject: Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)
>  
> Hi, Robert:
> 
> Aijun Wang
> China Telecom
>  
> 
> On Feb 11, 2021, at 23:40, Robert Raszuk <[e-mail]> wrote:
> 
> 
>  
> Now if all of the above is not done or done with mistakes and you indeed experience to many routes to be handled by data plane you stop locally importing those routes to local VRFs by VRF shutdown. The good thing here is that this will be noticed by all attached customers as their dynamic routing will propagate withdraws. 
> [WAJ] The BGP session is shared by several VPNs and cannot be shutdown in such situations. Procedures that you expect would not happen.
>  
>  
> Where did I say to shutdown BGP session ? 
>  
> I said VRF shutdown ... nothing to do with BGP sessions shutdown. 
>  
> [WAJ] Don’t you think VRF shutdown has the more broader influences? RD-ORF influences only the newly advertised VPN routes. VRF shutdown will influence the existing VPN routes and its existing forwarding traffic.
>  
> 
> - - - 
>  
> Let me provide the analogy here ... 
>  
> You are presenting a solution on what to do when we fly low and start hitting the top of the trees. 
>  
> WG tells you that flying low is bad practice and should not take place providing what to do to mitigate it well - in the analogy train your ground crew not to overload the plane. 
>  
> You say - Oh well we have different idea instead - when we throw away during the flight some passengers we can keep flying (on the edge of safety). 
> [WAJ] Just deny the onboard of new passengers, not throwing the existing passengers.
> 
>  
> That's here we are with this. 
>  
> - - - 
>  
> Quite honestly when we started to deploy 2547 back in nearly 2000s we were preparing much more user friendly solution (a flavor of CSC - not CSC as defined in the RFC) where SP network would only deal with next hops and never with customer routes ... yet customer would have the same type of service. Quite honestly we have had even OSPF reflector ready for it. Problem was that at that time SPs said oh we want to take millions of customer routes - no problem. We just buy bigger RRs and bigger routers. So you can guess what happened with such idea - got shelved as if deployed would result in revenue loss :). 
>  
> [WAJ] RD-ORF mechanism can encourage the provider to deploy inter-as VPN solutions because it gives them the granular control over the VPN routes propagation between ASBRs or RRs, which can certainly broader the VPN service coverage and the revenue.
>  
> 
> Best,
> R.
>