NimbostratusSo, this is a very deep topic and there are lots of articles around the web and books that discuss it. A quick google will provide you with a number of resources on the topic. To paraphrase Segal's Law: 1 NTP server is better than 2, but 3 or more are better again. If you have other NTP servers available, it's recommended to use them also.
For an active/standby BIG-IP deployment, I think that I would ensure that the NTP service was listening on the non-floating self-IP of each unit in the pair, and use that address on my endpoints.
If you use systems that are separate from the BIG-IP to provide NTP services, then I would load balance those. I've set up a VS for each node, with one node configured as the "primary" for each pool, and the other nodes as secondaries using Priority Group Activation. This will ensure that if you have maintenance on a node, that clients connecting to the VIP will still get a response. An NTP implementation I built years ago uses this architecture in multiple datacenters, and services 10,000+ client systems.
NTPVS1, Pool 1, Node 1 (priority 10), Node 2, Node 3
NTPVS2, Pool 2, Node 2 (priority 10), Node 1, Node 3
NTPVS3, Pool 3, Node 3 (priority 10), Node 1, Node 2
My thought here with multiple VSes is that using typical load balancing for NTP where a client may get a response from a different server frequently, may cause little jumps in time on downstream systems, depending on how closely each NTP server is in sync with one another. You could use persistence to help with this. It will also let the client system make a decision about which server it sees as the "best".