constant for empty prefix set

[Alexander Zubkov]

On Mon, Feb 14, 2022 at 9:47 PM Ondrej Zajicek <santiago at 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 <green at 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 <green at 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: santiago at 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."