I'm not a big user of pix-based VPN because it's not included in the common criteria target of evaluation (TOE) for Pix, but then neither is failover, NAT, remote management and a few other things. I can, however, throw a little light on the subject of crypto-tunnels and access-lists based on my experience with routers.
The IPSec RFC refers only to contiguous addresses, whereas Cisco access-lists can cover discontiguous addresses. In addition, a Cisco access-list used in crypto may contain multiple permit statements. The upshot of all this is that in many cases, a Cisco device may form multiple tunnels to the same endpoint. (and PPTP/GRE is a good example of this, where there are two tunnels created, one specific to the GRE traffic, and one relating to the source/destination IP addresses in general)
What all this means is that often when crafting your crypto access-list, if you want to limit the number of tunnels created, you may wish to design the access-list to use as few permit statements as possible. So, for example, the following crypto access-list
permit ip host 202.12.119.4 any
permit ip host 202.12.119.7 any
might be better written as
deny ip host 202.12.119.5 any
deny ip host 202.12.119.6 any
permit ip 202.12.119.4 0.0.0.3 any
because the second access-list will result in only half as many tunnels being created in the normal course of operation.
Sooner or later I expect someone will extend the concept of tags to crypto so that traffic may be tagged with a tunnel equivalency even though it is discontiguous.
