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

[Keyur Patel]

Hi Maria,

One comment inlined #Keyur

From: GROW  on behalf of Robert Raszuk 

Date: Monday, April 1, 2019 at 9:31 AM
To: Maria Matějka 
Cc: "grow@ietf.org" 
Subject: Re: [GROW] Prefix limit ORF: add grace time
Resent-From: 

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 
mailto:jan.mate...@nic.cz>> wrote:
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

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

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

[UTTARO, JAMES]

+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  On Behalf Of Robert Raszuk
Sent: Tuesday, April 02, 2019 5:35 AM
To: Maria Matějka 
Cc: grow@ietf.org
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.

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.

On Tue, Apr 2, 2019 at 11:21 AM Maria Matějka 
mailto:jan.mate...@nic.cz>> wrote:
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.
>
> 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 
> mailto:jan.mate...@nic.cz>
> >> 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.
>
> I think this would be much simpler for the users than fiddling with
> the limit more times.
>
> Thx
> Mariais
>
> On April 1, 2019 6:30:45 PM GMT+02:00, Robert Raszuk
> mailto:rob...@raszuk.net> 
> >> 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 
> mailto:jan.mate...@nic.cz>
> >> wrote:
>
> 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
>   

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

[Robert Raszuk]

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.

On Tue, Apr 2, 2019 at 11:21 AM Maria Matějka  wrote:

> 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.
> >
> > 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  > > 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.
> >
> > I think this would be much simpler for the users than fiddling with
> > the limit more times.
> >
> > Thx
> > Mariais
> >
> > On April 1, 2019 6:30:45 PM GMT+02:00, Robert Raszuk
> > mailto:rob...@raszuk.net>> 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  > > wrote:
> >
> > 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
> >
> > ___
> > GROW mailing list
> > GROW@ietf.org 

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

[Maria Matějka]

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.
> 
> 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  > 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.
> 
> I think this would be much simpler for the users than fiddling with
> the limit more times.
> 
> Thx
> Mariais 
> 
> On April 1, 2019 6:30:45 PM GMT+02:00, Robert Raszuk
> mailto:rob...@raszuk.net>> 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  > wrote:
> 
> 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
> 
> ___
> GROW mailing list
> GROW@ietf.org 
> https://www.ietf.org/mailman/listinfo/grow
> 
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> 

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow