IPSec standards are all based around contiguous ranges of addresses etc. What that means is that when devices are to protect non-contiguous ranges, they must form a separate security association for each.
That means if you have set up crypto acl's similar to the following:
permit ip 172.16.1.0 0.0.0.255 10.1.1.0 0.0.0.255
permit ip 172.16.20.0 0.0.0.255 10.1.1.0 0.0.0.255
and you are peering with only one other encrypter, 2 security associations will be formed.
The same concept applies to ports/protocols, so depending on how you phrase your access-list, you may have many tunnels between the same pair of devices.
In large scale VPN implementations, the phrasing of access-lists is critical, as the access-list does not only determine what traffic is encrypted, it is used as a template in negotiating the masks that will be applied to security associations, and hence determines the number of security associations that will be required.
In general, phrase your crypto access-list with as few permit statements as possible, (even if that means adding in a few deny statements before the permits)
When it comes to protocols/ports, current limitations in some of the cisco kit means you are usually better off using just permit statements and wearing the pain of the extra SA's. Again, the rule is avoid port/protocol based crypto acl's when possible.
One of the reasons IPSec/GRE is popular is that this whole issue is bypassed once your GRE tunnel is working.
