On Mon, Nov 11, 2013 at 10:08:30AM +0200, Sergey Popovich wrote:
And yes, really according to documentation we could match only on set with elements of same tyme.
That is true, IPs are matched against IP sets, while prefixes are matched against prefix sets. The main problem is that syntactic expression '[ 192.168.1.0/24 ]' could be interpreted either as prefix set containing one element, or as an shorthand for ip set containing 256 such addresses. There is a way (although less convenient) how to write such ip sets even in the current code: [ 192.168.1.0 .. 192.168.1.255 ].
On the other hand, an ip type may be easily represented as prefix with length of max AFI prefix length (32 - IPv4, 128 - IPv6, so I see no problem using this conversion of ip to prefix type.
There is one major problem related to such change. The intuitive way to write such expression is: 192.168.1.1 ~ [ 192.168.0.0/16 ] In current code, user gets an error and notices that. After your patch, user wouldn't get error, but the expression wouldn't work as expected (because it has to be '[ 192.168.0.0/16+ ]', which makes less sense). I don't see a good solution for this problem, just several bad ones. Perhaps to write a specialised match function for ip ~ pxset, which walks the trie and returns true if any prefix matches.
Moreover on IPv4 BIRD build there is implicit conversion of ip type to quad as on IPv4 they basically represent value with same format.
Which is a major PITA in the filter code. -- 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."