[PATCH] Filter: picking community elements and finding min/max element
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.
Of course I forgot to attach the patches. :) On Thu, Dec 16, 2021 at 2:41 PM Alexander Zubkov <green@qrator.net> 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.
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@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."
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@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@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."
I can adapt the patch if you wish, just write which variant you want to use. On Thu, Dec 16, 2021 at 7:12 PM Alexander Zubkov <green@qrator.net> wrote:
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@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@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."
On Fri, Dec 17, 2021 at 04:38:11PM +0100, Alexander Zubkov wrote:
I can adapt the patch if you wish, just write which variant you want to use.
I am thinking about two variants: global / local (for standard community), global / local1 / local2 (for large one). asn / data (for standard community), asn / data1 / data2 (for large one). Just pick one, this can be easily changed during merging. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
I like the second variant a bit more. On Fri, Dec 17, 2021, 18:13 Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Fri, Dec 17, 2021 at 04:38:11PM +0100, Alexander Zubkov wrote:
I can adapt the patch if you wish, just write which variant you want to use.
I am thinking about two variants:
global / local (for standard community), global / local1 / local2 (for large one).
asn / data (for standard community), asn / data1 / data2 (for large one).
Just pick one, this can be easily changed during merging.
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@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."
Updated both patches. The first one now adds/modifies operators .asn/.data/.data1/.data2 instead of '@'. And the second one is only changed because of patch conflicts. On Fri, Dec 17, 2021 at 8:38 PM Alexander Zubkov <green@qrator.net> wrote:
I like the second variant a bit more.
On Fri, Dec 17, 2021, 18:13 Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Fri, Dec 17, 2021 at 04:38:11PM +0100, Alexander Zubkov wrote:
I can adapt the patch if you wish, just write which variant you want to use.
I am thinking about two variants:
global / local (for standard community), global / local1 / local2 (for large one).
asn / data (for standard community), asn / data1 / data2 (for large one).
Just pick one, this can be easily changed during merging.
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@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."
And some docs for it. On Tue, Dec 28, 2021 at 12:12 AM Alexander Zubkov <green@qrator.net> wrote:
Updated both patches. The first one now adds/modifies operators .asn/.data/.data1/.data2 instead of '@'. And the second one is only changed because of patch conflicts.
On Fri, Dec 17, 2021 at 8:38 PM Alexander Zubkov <green@qrator.net> wrote:
I like the second variant a bit more.
On Fri, Dec 17, 2021, 18:13 Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Fri, Dec 17, 2021 at 04:38:11PM +0100, Alexander Zubkov wrote:
I can adapt the patch if you wish, just write which variant you want to use.
I am thinking about two variants:
global / local (for standard community), global / local1 / local2 (for large one).
asn / data (for standard community), asn / data1 / data2 (for large one).
Just pick one, this can be easily changed during merging.
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@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."
On Tue, Dec 28, 2021 at 02:11:12AM +0100, Alexander Zubkov wrote:
And some docs for it.
Thanks, merged. Also thanks for the docs! -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
participants (2)
-
Alexander Zubkov -
Ondrej Zajicek