The short answer is yes.
The longer answer is that for every 4KB WAFL block that has not been updated in the active filesystem since the snapshot was taken, you will be reading from the exact same block as one would in the active fielsystem. What I can also tell you is that the native ONTAP dump command (which would also be used for an NDMP-based backup) gets a lower priority than protocol ops, but they will most likely be contending for the same blocks, and more importantly, the same disks. If they were contending to read the same blocks at the same time, then read cache kicks in and tries to avoid making subsequent pulls from disk so you'd be less affected in that scenario. It's when they want vastly different blocks that you end up contending for disk I/Os would probably be a bigger potential performance issue. But there are stratgegies to help that as well, especially in sequential reads like backup (think aggressive read-aheads when one side does get the disks)
The best paper I know of is still the old tried and true TR3002: which is probably 15+ years old, but still has meaning. I would be wary of any limitation #s in there as things have obviously changed in the last d...
The important thing that WAFL does that most other snapshot technologies to not do is it keeps existing blocks IN PLACE, rather than copying them out to a separate area. When a block is slated to be over-written, rather than copying it out, then over-writing the block, WAFL allocates a new block and adjusts the pointers. It's really efficient in that respect and you don't pay the signficant penalty the the other designs get when you deploy snapshots (I've seen some systems crumble at 5 or 10 snapshots, where WAFL keeps on rolling at 200+).
Hope this is at least a good start to answering your question.
