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

[Robert Raszuk <[e-mail]>]

Dear Sue & Jeff,

I completely agree with you on the point below.

Furthermore I would like to suggest the following text to be added to the
shepherd's review:

"The proposed functionality creates a set of filters
after receiving and parsing BGP UPDATE messages. The document suggests that
pushing such list of filters to upstream IBGP peer is a helpful and sound
operation.

However in practice BGP UPDATES to construct the filter have already been
received, parsed, best path run and even import action (or its simulation)
executed. Therefore such excessive routes can be dropped on the impacted PE
locally without any need for upstream signalling. BGP does not resend full
table periodically so only upon session reset or route refresh triggered
dump the same NLRIs (with the same or possibly different paths) may arrive
at the affected PEs. If paths are different then it is likely that
previously sent filters in the form of <RD, RT list, NH> will not be
effective.

The VPN route local drops due to non-intersecting RTs is a very low cost
operation and has been an integral part of BGP VPN deployments in all
Provider Edge nodes since day one. Orders of magnitude more routes are
being dropped on the receiving PEs then those which will be subject to
action described as the hypothetical problem.  Such drop does not require
running local best path nor import and can be highly optimised by local
implementation.

While dropping such excessive routes an alarm MUST be triggered to the
operator to take action.

Another advantage for local drops is that such a solution does not impact
existing VPN connectivity. While the subject document does. Imagine the
situation presented by one of the WG members where an existing VPN with
1000 routes works correctly on the receiving PE. For simplicity assume that
those 1000 routes come from single hub src PE's VRF with one RT.

So what the draft proposed when receiving even 10 excessive routes is to
construct the filter <RD, RT, NH of src PE> and send it to Route Reflector.
The effect of such action would be the withdrawal of all 1010 routes !
That's a harmful and not helpful model. Instead, locally receiving PE
can drop those 10 routes and notify NOC."

Kind regards,
Robert Raszuk




On Thu, Sep 1, 2022 at 2:44 AM Jeffrey Haas <[e-mail]> wrote:

>
>
> On Aug 30, 2022, at 10:12 AM, John E Drake <
> jdrake=[e-mail]> wrote:
> I think Robert’s approach is a much better solution to the problem and it
> obviates the need for the subject draft.
>
>
> The approach of running the procedures on the route reflector are
> problematic for the original scenario in multiple respects:
> - The point of measurement for the quota is the receiving VRF.
> - The reflector would have to proxy all VRF receive policies to see if the
> route should be applied vs. the quota.
>
> Never mind that many providers prefer to avoid any specific provisioning
> of VPN behaviors on route reflectors.
>
> -- Jeff
>
>
>