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

[Jeffrey Haas <[e-mail]>]

Igor,

I think the response below covers the followup question you had to me as well.  If it hasn't, please let me know and I'll respond to that one separately.

> On Aug 29, 2022, at 2:37 PM, Igor Malyushkin <[e-mail]> wrote:
> A destination PE starts receiving VPN routes from the first (a faster) PE via a session to the RR, these routes exhaust a quota and a VRF prefix limit. The destination PE sends an ORF message to the RR and starts discarding excessive routes that it already received, but it is still receiving new routes from the RR (RR hasn`t received and processed the ORF message). At this time the RR starts sending also VPN routes from the second multihoming PE. It also eventually receives the ORF message and stops sending routes from the first PE. RR starts sending withdrawals for the routes of the first PE and continues sending routes of the second PE. Let`s imagine, that the destination PE considers the routes of the second multihoming PE and always compares them with the quota (I`m still not sure about it, the draft is uncertain here). Due to the VRF prefix limit being passed a long time ago, the PE sends the second ORF message (although we could stop all this nightmare with the first message if it weresource-less). All this time the destination PE is dropping the same amount of routes but from the second multihoming PE. The RR received the second ORF, stops sending updates, and start sending withdrawals. 
> Consider that some routes would be deleted from the VRF (I`m still not sure about it) when the destination PE sends the first ORF message. In this case, we also need to update FIB, delete the routes from the first multihoming PE, then install routes for the same destinations from the second. After the second ORF message, we again delete these routes.

You're covering several points here:
1. When an ORF has been sent to an upstream peer, it may not take immediate effect.  This is a correct observation.  Matter of fact, once it takes effect, it will start sending BGP Withdraw messages for things it has already sent and cause some amount of CPU and message impact.  This was commented upon in the first round adoption discussion.

2. What do you do about the counters while you're waiting on cleanup for the first ORF to be processed?  I think there's a few additional points here:
2a. While there's no requirement for the ORF sender to also have local policy that covers the ORF's behavior, it's a reasonable thing to have.  (And covers the original ORF use cases where local policy is configured, but requested to be enforced remotely.)  This means that while waiting for BGP messages from the ORF receiver to try to delete the routes at the sender, the sender is also likely re-running its policy on its rib-in and locally deleting things.  That said, this is probably not instantaneous.
2b. Since cleanup is not instantaneous, but end intent is understood that cleanup will happen, the implementation could attempt to judge its quota with the realization that some routes that aren't yet gone will be gone.  However, if the mechanism is invoked to try to limit memory impact rather than CPU impact, it may not happen fast enough and may trigger an additional cycle of cleanup.

2b is a churn behavior that ideally could use further discussion in the vpn-orf Internet-Draft.

It's also important to note that deployments may not fully deploy the ORF, so some cleanup procedures would still need to be local.

-- Jeff