Hello Carl,
the more scalable way to perform this is to use BGP communities to tag BGP routes sent by HQ.
On remote sites you will have a route-map matching on BGP community value(s) using a community-list.
Instead of specifying what IP prefixes you want to learn on the remote site with an IP ACL or a prefix-list, you configure the router to accept all the routes that have a BGP community value as expected.
In this way, in the future you will need to make changes only on the HQ to add a new route to those that should be learned by remote sites, by simply adding a specific BGP community value to the BGP advertisement.
Multiple BGP communities values can be associated with a single BGP advertisement making the mechanism very flexible.
You can divide the routes in multiple groups and you can associate each of them with a BGP community value.
In this way you can also configure different remote sites to accept/import more then one group of routes as needed.
To be noted in order to propagate the BGP community attribute you will need the command
neighbor x.x.x.x send-community
if it is not present.
This approach should work also if your sites are interconnected with an MPLS L3VPN if the PE routers are configured for BGP community propagation ( and they should ).
The HQ router(s) need a route-map with the set community action in the route-map blocks.
To preserve the current set of BGP communities on the route you can use set community value additive.
Hope to help
Giuseppe
