constant for empty prefix set

[Alexander Zubkov]

Made some example changes to allow the use of an empty set, which
works with all types and prefixes too. Its value has type T_SET with
NULL pointer to the tree. Looks goot at the first sight. The only
issue I know about now is with function as_path_filter(...) in
nest/a-path.c. It has both pointer to struct f_tree and integer number
(to compare ASes with) in its arguments. And it uses pointer if it is
not null and the number otherwise. So it cannot distinguish if it was
provided with an empty set, and uses the number in such cases. It will
still match 0 in the path, when it should match nothing. So further
intervention to this function is required. I have added two commented
tests into test.conf which are passing now, but should not:

#bt_assert(delete(prepend(prepend(+empty+, 0), 1), []) = prepend(+empty+, 1));
#bt_assert(filter(prepend(prepend(+empty+, 0), 1), []) = prepend(+empty+, 0));

On Tue, Feb 15, 2022 at 12:09 PM Alexander Zubkov <green at qrator.net> wrote:
>
> I also think now - why at all do we need a typed empty set? I think it
> is possible to add an untyped empty set, that will act as a "joker"
> with any types. It should fit better to the current syntax now without
> introducing a lot of new constructions.
> It could be a separate type (for example T_EMPTY_SET) or a set (T_SET)
> with an empty tree. I can try to prepare patches for that if you want.
>
> On Mon, Feb 14, 2022 at 11:46 PM Alexander Zubkov <green at qrator.net> wrote:
> >
> > 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."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bird-empty-set.patch-v1
Type: application/octet-stream
Size: 9402 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20220221/6dd1986f/attachment.obj>