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 <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 > Maria > > On April 1, 2019 6:30:45 PM GMT+02:00, Robert Raszuk <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 <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 >>> >> > -- > 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
