Consensus on TLSRoute - can we Graduate to Standard?

[candita]

The purpose of this discussion is to try to get consensus on 1) keeping TLSRoute and then 2) graduating TLSRoute to standard.

TLSRoute has a well-documented need in Gateway API.

@hbagdi’s comprehensive document on [SIG-NETWORK] TLS config in service-apis provides some background discussion of TLS concerns for service APIs and what it might look like to combine TLS config with HTTPRoute or TCPRoute. Service API: TLS related issues lists some Issues that were related back then. We’ve relied on @youngnick's encyclopedic Gateway API TLS Use Cases to answer many questions, including the need for TLSRoute when Passthrough routing is required.

The current list of TLS related issues that are waiting to be addressed includes:

• Support for TLS Certificate Management in Gateway API TLSRoute · Issue #3249
• TLSRoute promotion to standard #3165 (includes some of the issues below this)
• GEP: TLSRoute #2643
• Support TLS Termination mode for TLSRoutes · Issue #2111
• conformance: Coverage for request routing to TLSRoute with no valid BackendRefs · Issue #2153
• Conformance Tests: TLSRoute Passthrough #1579
• TLS support docs inconsistencies #1474
• Conflicting SNI's between HTTPRoute & TLSRoute · Issue #623

The current list of TLS related discussions expressing interest in TLSRoute includes:

• TLSRoute match ALPN · Discussion #1683
• What listeners should be considered when filtering hostnames in routes? · Discussion #1563
• GatewayTLSConfig: Well known options - Discussion #896

Over time several implementations have added TLSRoute based only the experimental API:
Cilium, Contour, Envoy Gateway, Istio, and nginx-gateway-fabric. I should add that Red Hat needs the TLSRoute (for passthrough) in its Gateway API integrations.

Despite the history, interest expressed via issues and discussions, and several implementations, we find ourselves in a position of questioning the role and necessity of a separate TLSRoute, see Ideas for TCP, TLS, and UDP Routing · kubernetes-sigs gateway-api · Discussion #2618 and Would Gateway Merging make TLSRoute Unnecessary? · kubernetes-sigs gateway-api · Discussion #3177 . [SIG-NETWORK] Gateway Hierarchy Brainstorming came about to address a new mechanism for gateway merging and mentions TLSRoute, but without resuming the decision-making on this, it’s not clear that it makes all TLSRoute concerns obsolete. I would like to request that we try to make a decision on TLSRoute that is not dependent on solving the Gateway Merging issues. If the community agrees that cannot happen, it would be good to focus energy back on the Gateway Merging solution as soon as possible.

Having said that, here is a summary of reasons to keep TLSRoute:

• How would we otherwise provide that second layer of SNI matching (intersecting with Gateway Listeners when attaching to Gateways).
• How would we otherwise provide a Passthrough solution.
• How would we otherwise provide ALPN routing, mentioned in GEP: TLS ALPN Routing · Issue #1958 (unless via GRPCRoute)
• We’d like to keep the persona/roles well-defined. Gateway management should be for cluster admins, but TLSRoute management should be accessible to app developers.

cc @robscott @shaneutt @youngnick @mlavacca

[shaneutt]

In addition to the above, I hope we can get representatives from the implementations listed (+Kong, which is not listed but I know to have an implementation) to help us by providing an up-to-date answer to these specific questions:

1. Do you still have need of this API? Do you have active users?
2. Are there any particular difficulties you've found with using (or implementing) this API?
3. Are there things you need from this API that it currently doesn't provide? Are you doing any annotations or custom extensions?