Filing task as didn't find the reason in a search.

I notice we have configuration on our core routers to generate aggregate routes for our LVS service IP ranges based on the presence of host-routes annoucned by PyBal, for instance in esams:

set routing-options aggregate route 10.2.3.0/24
set routing-options aggregate route 185.15.59.224/27

I'm not 100% sure on the logic here? All the PyBal host routes are announced in BGP between core routers anyway, so these aggregates never get used. I can kind of see if a brand new LVS SVC IP is announced a remote router will already have the aggregate, and this may mean the service is reachable from the remote site a second or so earlier than if it had to wait to learn the specific host route, but overall I'm not sure it helps much.

Aside from these our aggregate routes are all public prefixes we wish to announce to peers, which seems to me to be the proper use of the aggregate config.

That said it causes zero problems having this in place, just something I happened to notice so thought I'd flag to be discussed.