On Mon, Feb 14, 2022 at 9:47 PM Ondrej Zajicek <santi...@crfreenet.org> wrote: > > On Thu, Feb 10, 2022 at 02:09:59PM +0100, Alexander Zubkov wrote: > > Hi, > > > > Let me remind about this once again. > > Hi > > Sorry for ignoring your previous mail, i needed to focus on finishing > things for 2.0.9, now i can continue with your patches.
Thank you, looking forward to it! > > 1) UDP logging - I have no principal issue with this, will review and merge. > > 2) Keeping proto state during reconfiguration - I am ok with 'configure keep' > patch, will preview and merge. I do not want 'keep state' per-protocol > option. Perhaps also some 'configure xyz' for regular configure and some > global option how 'configure' without arguments should behave for people > who would like 'configure keep' to be the default behavior. > > 3) prepend_times() - I am a bit ambivalent about that. I see usefulness > of that. I do not like the name. It can be implemented as optional > argument to prepend(), but not sure if that is better. Will think about > that. Also, considering user mistakes like [*], we perhaps should > limit multiplier by say 16. I do not insist on the name of course, or implementation. :) > > [*] https://bgpmon.net/long-as-paths-causing-commotion/ > > 4) Empty prefix set - Too hacky and inconsistent syntax. Note that there > are also non-prefix sets. We already have ugly hacks for empty community > lists, we want to avoid yet another way to define empty structures. Yes, I know about other sets, that is why I choose how to name this set. But probably not completely the same: /empty/ vs [ /empty/ ] I did not know there was an intention to get rid of those hacky names, but on the other hand they need to be defined somehow and just using "[]" does not work because it is ambiguous for the parser. I do not insist on the name here, of course, just on the idea itself. Possibility to define an empty prefix set is indeed useful. If I match network against some named set, than I have no variants now how to define such set to be empty (or I do not know about such variant). If such set is defined separately, for example dynamically, sometimes I want it to be empty, so nothing would match it. > > Unfortunately there is no easy way to define literals that could be used > for multiple data types. We already have A.B.C.D, that could be both IP > address and router ID, and it is super annoying in the code. We would > like to have some more generic solution, we will think about that. Yes, I understand. Generic solution of course makes things clearer. But in this case even if we have some means to specify that ip-like literal is actually of type ip or quad, anyway it would be not so good to force everybody to specify types for all ip-like literals in their configs. As for generic way to define empty sets/list, I can imagine now these variants for consideration: function-like: emtpy_list(<type>), empty_set(<type>) - example: empty_set(ip), empty_list(lc), ... empty(<type>) - example: empty(ip set), empty(lclist) type-conversion-like: (<type>) [] - example: (ip set) [], (lclist) [] OO-like: type.<type>.empty - type.ip_set.empty, type.lclist.empty > > 5) Reduce/reduce fix - Will look at this. > > > > On Tue, Jan 11, 2022 at 1:10 PM Alexander Zubkov <gr...@qrator.net> wrote: > > > > > > Hi, > > > > > > Let me ping this. I would like to receive a feedback on this (and some > > > other my recent) messages. > > > > > > On Sat, Jan 1, 2022 at 9:45 PM Alexander Zubkov <gr...@qrator.net> wrote: > > > > > > > > Hi, > > > > > > > > I propose to add some constant for empty prefix set, for example (as > > > > in the patch): > > > > define pfx_empty = [ /empty/ ]; > > > > > > > > It is useful when we define a named prefix list, which we can use > > > > somewhere in filters, but this prefix list is generated, for example, > > > > and we may need to make it empty. But there is no currently means to > > > > create an empty prefix set, as I understand. > > -- > Elen sila lumenn' omentielvo > > Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) > OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) > "To err is human -- to blame it on a computer is even more so."
