Subject: [GROW] Prefix limit ORF: add grace time

From: Maria Matějka <[email-masked]>
Date: Mon, 1 Apr 2019 17:29:41 +0200

Hello!

I'd like to suggest adding a grace time to the Prefix Limit ORF-Type.
Its purpose is to allow temporary overrun of the limit while reloading
the routes after a policy is changed.

Why: If the peer exports e.g. 2001:db8:0/48 through 2001:db8:7/48 and
it wants to substitute them for 2001:db8:0/45, it first has to add the
less specific prefix and then drop the more specific prefixes. Doing this
on large scale may override the limits temporarily which would lead to
unneeded BGP session drop.

Here are the changes to be done to the RFC text:

* append to section 3:
	The "Grace-Time" is a two-byte unsigned integer. It indicates
	the number of seconds for which the Prefix-Limit can be exceeded.

* append to section 4 the Grace-Time directly after the Prefix-Limit

* insert to section 6.1.1 after 2nd paragraph:
	The sending speaker MUST wait for the Grace-Time period before
	taking corrective action. If the peer gets from the Prefix-Limit
	violation during the Grace-Time period, no corrective action is taken.
	The Grace-Time period is reset every time the violation is gone.

Thank you for cnnsidering my suggestion
Maria

---

From: Maria Matějka <[email-masked]>
Date: Mon, 1 Apr 2019 17:31:41 +0200

> the routes after a policy is changed.

Sorry for double-posting. The related document is draft-keyur-idr-bgp-prefix-limit-orf-03

Maria

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 1 Apr 2019 18:30:45 +0200

Hi Maria,

So your suggestion is not to apply this limit at all (ie. have unlimited
transient) - don't you think that in such a case your weakest network
elements may just crash if say they expect 10 and will get 700K prefixes ?

I think what you are asking for can be easily achieved today during
described migration if you adjust the prefix limit to some controlled
higher value before your planned policy change then simply revert it back.
Seems like very safe and problem free operation.

Many thx,
R.

On Mon, Apr 1, 2019 at 5:29 PM Maria Matějka <[email-masked]> wrote:

> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>

---

From: Maria Matějka <[email-masked]>
Date: Mon, 01 Apr 2019 19:50:02 +0200

Oops, I forgot to write there that during the grace period the limit should be only temporarily raised by a factor of 2 to allow complete route exchange, not lifted at all.

I think this would be much simpler for the users than fiddling with the limit more times.

Thx
Maria

On April 1, 2019 6:30:45 PM GMT+02:00, Robert Raszuk <[email-masked]> wrote:
>>         violation during the Grace-Time period, no corrective action
>is
>> taken.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 1 Apr 2019 19:54:25 +0200

Well you still need to indicate to prefix limit check when it should start
x2 multiplication and when the specific upgrade which requires it is over.

Note that vast majority of customers use prefix limit as a safety fuse
normally allowing x2 or even x5 under normal operation.

Best,
R.

On Mon, Apr 1, 2019, 19:50 Maria Matějka <[email-masked]> wrote:

> Oops, I forgot to write there that during the grace period the limit
> should be only temporarily raised by a factor of 2 to allow complete route
> exchange, not lifted at all.
>

---

From: Maria Matějka <[email-masked]>
Date: Tue, 2 Apr 2019 11:21:16 +0200

Thank you for clarifying this. Therefore it has no sense to make it more
complicated in this way.

Anyway, I'd like to have there at least a note saying that if the prefix
limit is too tight, you may get an unwanted bgp session drop simply due
to temporary conditions. Is this reasonable?

Thanks
Maria

On 4/1/19 7:54 PM, Robert Raszuk wrote:
> Well you still need to indicate to prefix limit check when it should
> start x2 multiplication and when the specific upgrade which requires it
> is over.
> 
> On Mon, Apr 1, 2019, 19:50 Maria Matějka <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     should be only temporarily raised by a factor of 2 to allow complete
>     route exchange, not lifted at all.
> 
>     Mariais 
>     On April 1, 2019 6:30:45 PM GMT+02:00, Robert Raszuk
>     <[email-masked] <mailto:[email-masked]>> wrote:
> 
>         Hi Maria,
> 
>         So your suggestion is not to apply this limit at all (ie. have
>         unlimited transient) - don't you think that in such a case your
>         weakest network elements may just crash if say they expect 10
>         and will get 700K prefixes ? 
> 
>         I think what you are asking for can be easily achieved today
>         during described migration if you adjust the prefix limit to
>         some controlled higher value before your planned policy change
>         then simply revert it back. Seems like very safe and problem
>         free operation. 
> 
>         Many thx,
>         R.
> 
>         On Mon, Apr 1, 2019 at 5:29 PM Maria Matějka <[email-masked]
>         <mailto:[email-masked]>> wrote:
> 
>             Hello!
> 
>             [email-masked] <mailto:[email-masked]>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 2 Apr 2019 11:34:46 +0200

Hi,

Prefix-limit is a feature which was originally invented to save BGP table
size in the cases of L3VPN such that any VPN site with dynamic routing
protocol could not overflow control plane capacity of PE it is attached to.

A bit later it has been extended to cover also BGP sessions not related to
VPNs/VRFs.

As such the prefix limit behavior is an independent vendor choice on how to
implement it. For example there can be a knob not to reset the session at
all but just log warning. There can be a knob to auto restart the session
etc .... To the best of my knowledge there is no spec defining what prefix
limit inbound or outbound (if we ever get there) should do.

Job had a presentation during last GROW meeting on that.

Here the draft from Keyur only defines the ORF mechanism on how to
communicate such limit between peers. It really does not define how the
prefix limit should be handled by either side.

Maybe we need new document to specify it provided vendor would agree to
adjust their current zoo of implementations ....

Kind regards,
R.

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Tue, 2 Apr 2019 10:30:43 +0000

+1..

VRF-Limit and Session Limit used together to protect a router.. VRF Limit is imposed such that multiple sessions for a given VPN customers cannot overflow due to the aggregate number of routes coming over all sessions for said VPN.

Jim Uttaro

From: GROW <[email-masked]> On Behalf Of Robert Raszuk
Sent: Tuesday, April 02, 2019 5:35 AM
To: Maria Matějka <[email-masked]>
Cc: [email-masked]
Subject: Re: [GROW] Prefix limit ORF: add grace time

Hi,

Prefix-limit is a feature which was originally invented to save BGP table size in the cases of L3VPN such that any VPN site with dynamic routing protocol could not overflow control plane capacity of PE it is attached to.

A bit later it has been extended to cover also BGP sessions not related to VPNs/VRFs.

As such the prefix limit behavior is an independent vendor choice on how to implement it. For example there can be a knob not to reset the session at all but just log warning. There can be a knob to auto restart the session etc .... To the best of my knowledge there is no spec defining what prefix limit inbound or outbound (if we ever get there) should do.

Here the draft from Keyur only defines the ORF mechanism on how to communicate such limit between peers. It really does not define how the prefix limit should be handled by either side.

Maybe we need new document to specify it provided vendor would agree to adjust their current zoo of implementations ....

Kind regards,
R.

On Tue, Apr 2, 2019 at 11:21 AM Maria Matějka <[email-masked]<mailto:[email-masked]>> wrote:
Thank you for clarifying this. Therefore it has no sense to make it more
complicated in this way.

Thanks
Maria

On 4/1/19 7:54 PM, Robert Raszuk wrote:
> On Mon, Apr 1, 2019, 19:50 Maria Matějka <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>         Hi Maria,
>
>         On Mon, Apr 1, 2019 at 5:29 PM Maria Matějka <[email-masked]<mailto:[email-masked]>
>         <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>             Hello!
>
>             * insert to section 6.1..1 after 2nd paragraph:
>             [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>             https://www.ietf.org/mailman/listinfo/grow<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_grow&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=5WcR1j0acF0LWb-5Sc6FnFy-2Sg2jT8Jk6lB6cygvqk&s=fkdvmoz_Wc3EHA9Bbs5VY4gp1RtHsB0nCOWZQBlJCc4&e=>
>
>
>     --

---

From: Keyur Patel <[email-masked]>
Date: Tue, 2 Apr 2019 18:06:13 +0000

Hi Maria,

One comment inlined #Keyur

From: GROW <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Monday, April 1, 2019 at 9:31 AM
To: Maria Matějka <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [GROW] Prefix limit ORF: add grace time
Resent-From: <[email-masked]>

Hi Maria,

So your suggestion is not to apply this limit at all (ie. have unlimited transient) - don't you think that in such a case your weakest network elements may just crash if say they expect 10 and will get 700K prefixes ?

I think what you are asking for can be easily achieved today during described migration if you adjust the prefix limit to some controlled higher value before your planned policy change then simply revert it back. Seems like very safe and problem free operation.

#Keyur: I agree with Robert. Wouldn’t it be simpler to simply have a higher prefix limit value that can accommodate the changes you describe?

Regards,
Keyur

Many thx,
R.

On Mon, Apr 1, 2019 at 5:29 PM Maria Matějka <[email-masked]<mailto:[email-masked]>> wrote:
Hello!

* append to section 3:

_______________________________________________
GROW mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/grow