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

[Robert Raszuk <[e-mail]>]

> 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.

What is being cooked here to me looks like a complete mess - that's all.

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.
>
> Bouncing ORFs back through these intermediate speakers is not a reliable
> way to achieve this notification.
>
> 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.
>
> Thus, it's unlikely that the ORF will make it all the way to the source of
> the routes.
>
> 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.
>
>
>
> 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.
>
>
>
>