Why does SSLO not support ACTIVE-ACTIVE mode deployments？

Hello!

SSLO typically doesn't support true Active-Active deployments due to the complexity of synchronizing stateful SSL/TLS sessions across multiple active instances, the challenges of consistent traffic steering and failover without session interruption or data loss, the need to prevent asymmetric traffic, and the overall increased complexity and resource demands. Consequently, most SSLO solutions favor an Active-Standby model for more reliable high availability. 

I think it is because iApps LX generates the configurations and iApps LX synchronizes them from Active to Standby via REST API.
I am guessing that this behavior is the reason why Active-Active is not supported.
Starting with v16.1.0-9.0, the configuration synchronization behavior has been changed to use the TMOS native MCP/CMI HA sync method.

F5 SSL Orchestrator Release Notes version 16.1.0-9.0
https://techdocs.f5.com/kb/en-us/products/ssl-orchestrator/releasenotes/product/relnote-ssl-orchestrator-16-1-0-iapp-9-0.html
> SSO Control Plane re-architecture
> SSL Orchestrator 9.0 includes the following significant improvements to the control plane:
> The source-of-truth for the SSL Orchestrator configuration is now stored in the iFile objects. This allows the SSL Orchestrator to utilize native MCP/CMI HA sync functions and support automatic and incremental sync.
> The iApp strictness lock icon has been removed from several objects, excluding network and access objects allowing you to make out-of-band changes freely.
> The SSLO architecture now no longer uses the Gossip sync function to sync SSLO REST configuration.

Maybe F5 Next can have this for the SSLO as it is more native module than iAppLX (nodejs) plugin on the clasical BIG-IP. 

There are a few official and technical answers to this question:

• Officially, SSLO policy on (classic) BIG-IP is a function of the Access per-request-policy engine, and APM itself does not support active-active in this way.
• Technically, it does not make sense to do active-active for outbound traffic, since an active-active configuration assumes multiple listener configurations (src:dest:port:proto:vlan) is alive on one of the BIG-IPs, and an outbound SSLO will typically only have one listener configuration (0.0.0.0/0:0 for transparent proxy, x.x.x.x:3128 for explicit proxy).

But the point is valid about splitting ipv4 and ipv6, and BIG-IP Next will indeed support active-active configurations, as SSLO is becoming a native module (no iAppLX on Next).