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