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

[Robert Raszuk <[e-mail]>]

Hi Jeff.

> Or even don't do rt-constrain.

No that is bad interpretation of my text. RTC is a useful optimisation, but
many years before it got implemented and deployed (many networks still do
not use it) local drop of uninterested routes is still in place and works
without any issues. Please do not extend my text to more then what was
intended to be stated.

My text said UPDATES have been sent. They are not coming again unless
session resets or refresh is sent. They were full processed at the
receiving PE. Then filter got created. If PE is still alive
nothing prevents to install such filters locally and notify NOC.

No need to send it anywhere.

With regard to negative operational impact, there already exist vendor
> features that deal with dropping excess routes in a VRF and thus have all
> of the "woe is me" problems you are wringing your hands over:
>
> https://supportportal.juniper.net/s/article/How-to-individually-limit-IPv4-and-IPv6-routes-in-a-VPN-scenario?language=en_US
>
>
> https://www.cisco.com/c/en/us/td/docs/ios/mtr/command/reference/mtr_book/mtr_01.html -
> see "maximum routes"
>
>
> https://infocenter.nokia.com/public/7750SR140R4/index.jsp?topic=%2Fcom.sr.l3%2Fhtml%2Fvprn.html&anchor=i8701838
> <https://infocenter.nokia.com/public/7750SR140R4/index.jsp?topic=/com.sr.l3/html/vprn.html&anchor=i8701838>
>
> It is already operational practice to generate an alarm when the soft and
> hard limits have been exceeded.  See documentation for each of the above.
>

And that is actually sufficient.

The operational consequences of the proposal in the VRF are NO DIFFERENT
> than an upstream CE connection prefix limit dropping a session.
>

I do not agree with this statement.

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.

Regards,
R.





>
> -- Jeff
>
>
> On Sep 1, 2022, at 4:33 AM, Robert Raszuk <[e-mail]> 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 <[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
>>
>>
>>
>