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: [email protected]) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
signature.asc
Description: Digital signature
