[PATCH] Filter: picking community elements and finding min/max element

[Alexander Zubkov]

I suspected, that the syntax may raise questions, but some syntax
should have been chosen to make a working patch. :) It does not matter
much to me, of course it could be changed in the way you prefer to see
it your product.
Yes, communities are not arrays, but on the other hand positional
addressing of fields is also intuitive and understandable, so I do not
see it as a big problem. For dot-notation is better to stick with
official names, like you suggest. I, personally, would prefer
something without subscription signs as they take more time to type
:), for example: global, data1, data2. And do you know something
suitable for standard communities? The best I can think of is "high"
and "low". As for EC communities, I did not even touched them, I do
not have experience with them and they look overcomplicated :), but
dot-notation I think should be better for them, as it will allow to
choose different representations.

On Thu, Dec 16, 2021 at 6:34 PM Ondrej Zajicek <santiago at crfreenet.org> wrote:
>
> On Thu, Dec 16, 2021 at 02:41:28PM +0100, Alexander Zubkov wrote:
> > Hi everyone!
> >
> > I made a couple of patches to do some interesting stuff with communities.
> > The first patch allows to pick a component from a standard or a large community:
> >
> > (10, 20, 30) @ 2 --> 20
> >
> > And the second patch allows to search for minimum or maximum element
> > in a community list. This combined allows to do some cool stuff with
> > communities like this:
> >
> > bgp_local_pref = filter(bgp_large_community, [(<as>, <localpref_val>,
> > *)]).min @ 3
> >
> > This will find us the minimum from our "localpref" communities and get
> > that number as integer, ready to assign it where we need. Now we use a
> > series of if's to check all the possible variants and that is not very
> > convenient. I think this features will greatly boost the possibilities
> > of working with communities in bird.
>
> Hi
>
> Nice patches, thanks! I agree that these features are pretty useful.
> Will merge the second one with no comments.
>
> With the first one, i do not really like the syntax. (Large) communities
> are not arrays to access them with indexing operator, and also using '@'
> as indexing operator is pretty unortodox. These are regular structures,
> so it is natural to use structure field accessors. Question is how these
> fields should be named, perhaps: global_id, data_1, data_2?
>
> That would make:
>
> (10, 20, 30) . global_id --> 10
> (10, 20, 30) . data_1 --> 20
>
> --
> 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."