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

Please see inline.

> On Sep 1, 2022, at 20:50, Robert 
> 
>> Such strategies work great if the network is under single administrative control.  In the absence of such single administrative control, local mitigation becomes something that requires consideration.
> 
> On that one I think if there is a missing feature across all major vendors is per RD prefix limnit on eBGP VPNv4/v6 sessions. 

[WAJ] Current VPN Prefixes VRF is the base to achieve this goal. I think you should remember the initial aims in the earlier version are exactly the inter-AS option B/C scenarios.

> 
> Regards,
> R.
> 
> 
> 
>  
>> 
>> -- Jeff
>> 
>> 
>>> On Sep 1, 2022, at 4:33 AM, Robert Raszuk <robert@raszuk.net> wrote:
>>> 
>>> 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 <jhaas@pfrc.org> wrote:
>>>> 
>>>> 
>>>>> On Aug 30, 2022, at 10:12 AM, John E Drake <jdrake=40juniper.net@dmarc.ietf.org> 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
>>>> 
>>>> 
>> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr