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 <[email protected] > <mailto:[email protected]>> 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 > <[email protected] <mailto:[email protected]>> 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 protected] > <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/grow > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
