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

[Gyan Mishra <[e-mail]>]

Jacob

As Aijun me mentioned this draft falls along the same premises as RFC 4684
RTC RT membership to create a distribution flood graph or RFC 5291 ORF
filter as Aijun mentioned to control flooding based on distribution graph
as the goal is to avoid unnecessary sending and processing of routing
updates and as well as receiving and processing of routing updates that end
up being dropped in the case of RTC RT membership flood graph.

RTC limits flooding via RT membership from RR to PE to only send to the PE
only interesting RTs being explicitly imported, in comparison to RD-ORF it
provides the same RTC style optimization to avoid flood of routes where the
overloaded PE can now signal via ORF in the same direction of RTC flood
scope from RR to PE adj-rib-out filter, but now at the RD level instead of
RTC RT level adj-rib-out based on the offending RD origin PE flooding the
prefixes using existing BGP route refresh RFC 5291 machinery for the RD-ORF.

As to why RTC does not work for this problem statement of an offending PE
or multiple PEs is that the membership is based on RT layer interesting RT
so the adj-rib-out would match the interesting RT imported by the PE only
so all prefixes for the VPN would be imported it the PEs VRF.  Thus the
offending PE or PEs flooding the VPN issue cannot be mitigated with RTC
since the RDs for the offending PEs would still be imported.

Just as well as you mentioned BGP peer maximum prefix is set to a high
water mark value as is the VPN maximum prefix knob, to prevent a customer
typo or errored configuration causing a flood of routes, but does not
protect the PE resources as if all peers were flooding and hit the high
water mark peer maximum prefix or if all VPNs hit the VPN maximum prefix
simultaneously the PE would be choked out of resources including the newly
upgraded FAT PE with plenty of horse power.

Unfortunately their is no solution that exists today that can circumvent
such issue with an offending PE or PEs plural flooding prefixes impacting
an operators core.

RT has been historically been used as the method of filtering as that is
the match method to import prefixes into a VRF, however the granularity has
never been used to filter based on RD which now I think with this draft and
future drafts and development in this arena, RD based filtering will become
more common as it allows for per PE originator granularity for filtering as
opposed to RT based filtering which represents all VPN prefixes to be
imported, which from a filtering perspective ends be being a sledge hammer
filter approach as opposed to a tiny screw driver RD based filtering
approach.

Kind Regards

Gyan

On Thu, Feb 11, 2021 at 10:49 PM Aijun Wang <[e-mail]>
wrote:

> 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.
>
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD