Preferred name for policy that contains Session Persistence

[robscott]

In GEP-1619, we introduced a new policy for extending Service and other backends with Session Persistence configuration, with the goal of expanding that to include other concepts such as LB algorithm, weak session affinity, locality, etc. In today's review session with SIG-Network TLs, @thockin raised the question of if the "LB" in the current "BackendLBPolicy" name was consistent with other terminology in Gateway API, or if it should be BackendLoadBalancerPolicy or BackendLoadBalancingPolicy. That led to this discussion to explore this question a bit further.

Rationale for BackendLBPolicy:

• Concise
• Consistent with TLS abbreviation in BackendTLSPolicy
• Could be interpreted as "Load Balancer" or "Load Balancing"

Rationale for BackendLoadBalancerPolicy:

• Consistent with upstream Kubernetes types
  • Service spec.type: LoadBalancer
  • Service spec.loadBalancerSourceRanges
  • Service spec.loadBalancerIP
  • Ingress status.LoadBalancer

Rationale for BackendLoadBalancingPolicy:

• Mostly consistent with upstream Kubernetes types (see above)
• Potentially more generic for implementations that don't consider themselves load balancers

Note: In the poll below, I'm going to include both BackendLoadBalancingPolicy and BackendLoadBalancerPolicy, but will consider the sum of those results when comparing with BackendLBPolicy.

[robscott]

This hasn't gotten much attention, we've already released RC1 with BackendLBPolicy as the name and the results here are not providing any reason to change this name. Closing this out.